Color design snag

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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

Re: Color design snag

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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 <de...@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

Re: Color design snag

[Peter Hancock <pe...@gmail.com>]

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 <de...@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