xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Color design snag
Date Tue, 06 Jul 2010 08:49:15 GMT
Done. Thanks for the reminder.

On 06.07.2010 10:30:02 Peter Hancock wrote:
> Hi Jeremias,
> 
> When you update the wiki would you be able to add links to any useful
> resources you found regarding colour management. It is not easy for
> developers without practical experience in this area to appreciate the
> complications and then gain the know-how and we need all the help we
> can get!  I am sure you were going to do this any way - I just wanted
> to stress my desire for some decent resources.
> 
> Cheers,
> 
> Pete
> 
> On Mon, Jul 5, 2010 at 5:40 PM, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
> > After re-reading the specs and starting code changes in Batik, I had to
> > realize that my initial idea for the color infrastructure design is not
> > quite right. I was assuming that the explicit sRGB fallback is to be
> > used whenever the actual primary color is not supported. But it's
> > actually so that a calibrated primary color is always to be used. It is
> > converted to sRGB (via CIE XYZ) if necessary in which case the explicit
> > sRGB fallback is not used at all. Only if the associated color profile
> > is unavailable (and the color can therefore not be calibrated), the sRGB
> > fallback is used.
> >
> > I've started to implement it as such in Batik. Only one color instance
> > (without any alternatives) is really necessary. And in FOP it would be
> > the same if not for our two intermediate formats where we have to
> > serialize the color back to a textual representation. And that means we
> > have to preserve the sRGB value even though there's only a slim chance
> > that the sRGB fallback is ever needed (an unavailable color profile will
> > be a rare event in the FO context).
> >
> > The concrete problem I have with my initial design idea is that I'd have
> > to change the code for all non-color-managed output formats to use the
> > alternatives' derived sRGB colors instead of the main color's sRGB value
> > which is currently the explicit sRGB fallback. That's obviously not
> > elegant.
> >
> > Remembering Thomas' comments, it does indeed look like the simple list
> > of alternatives is not very helpful. I end up thinking about priorities
> > and roles for alternative colors to handle all sorts of combinations and
> > that is unreasonably complex. Since both SVG and FO don't offer to
> > specify more than 2 colors (optional primary + sRGB fallback), it
> > probably doesn't make much sense trying to anticipate what might (!)
> > come in a future spec. And more, when a calibrated color is available
> > (be that sRGB, ICC, ICC named (spot) or Lab), it can always be converted
> > to a close approximation for the required output device (gamut problems
> > aside). If someone has to cater for different output devices, a
> > stylesheet can always set different colors. At least for FO, that is the
> > reasonable thing to do. Maybe less so for SVG since it's more of an
> > exchange format than FO is. FO is almost always just a short-lived
> > intermediate format. But even SVG has the ability to be associated with
> > a stylesheet (CSS or XSLT).
> >
> > Somehow I end up with a simplified ColorExt without the profile name and
> > source and without the colorValues array. Just a Color subclass that
> > adds a float array (or Color instance) for the explicit sRGB fallback.
> > And that class will only be used by FOP since Batik probably doesn't
> > need it. That's for most use cases. ColorWithAlternatives with the
> > ordered list of alternatives is still useful, but only for the cases
> > where device-specific colors need to be specified. Any color
> > calculations would be made off the sRGB fallback and output formats
> > supporting device-specific colors would pick them from the alternatives
> > list.
> >
> > That would then be:
> >
> > class ColorWithAlternatives extends Color {
> >  Color[] alternativeColors; //may be null
> > } //located in XGC
> >
> > class ColorWithFallback extends ColorWithAlternatives {
> >  float[] (or Color) srgbFallback;
> > } //located in FOP
> >
> > Well, the sRGB fallback is essentially an alternative color, too, but
> > not in the original sense of ColorWithAlternatives where the alternative
> > colors take precedence over the main color. That's why I started
> > thinking about roles in the alternative list. Just too complicated.
> >
> > Just to play through all possibilities:
> >
> > Batik:
> >
> > * sRGB -> use sRGB
> > * ICC (profile available) -> use ICC color (sRGB calculated from ICC color on
demand)
> > * ICC (profile not available) -> use sRGB fallback
> > * ICC named (profile available --> use ICC color (sRGB calculated from ICC color
on demand)
> > * ICC named (profile not available) -> use sRGB fallback
> > * Lab/LCHab -> use Lab color directly (sRGB calculated from Lab color on demand)
> > * device color -> sRGB is primary color with device color attached to ColorWithAlternatives
> >
> > Except in the case of device color, ColorWithAlternatives is used with
> > null as argument for the alternative color array. It is used because of
> > its advanced equals() method only.
> >
> > FOP:
> >
> > Essentially the same as Batik except that FOP uses ColorWithFallback
> > instead of ColorWithAlternatives storing the explicit sRGB fallback
> > exclusively for serializing the color as string value. The sRGB fallback
> > is not used otherwise.
> >
> >
> > This is much harder that I thought, as if the color theory is not
> > already tricky enough by itself. Maybe this is not the most elegant
> > solution but at least it should work and match the specs. I will rework
> > the branches in that direction tomorrow. In the meantime, your thoughts
> > are certainly welcome. I will also update the Wiki in due time.
> >
> >
> > Jeremias Maerki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: general-help@xmlgraphics.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
> 




Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org


Mime
View raw message