xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hancock <peter.hanc...@gmail.com>
Subject Re: Color design snag
Date Tue, 06 Jul 2010 08:30:02 GMT
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.



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
> * 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

View raw message