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 <[email protected]> > 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
