- From: Chris Lilley <chris@w3.org>
- Date: Fri, 9 Jul 2010 14:39:24 +0200
- To: Jeremias Maerki <dev@jeremias-maerki.ch>
- CC: www-svg@w3.org
On Wednesday, June 23, 2010, 9:58:27 AM, Jeremias wrote: JM> Dear WG, JM> I'm now in the implementation phase for enhanced color support in Apache FOP JM> and Apache Batik. I'm still building the color infrastructure for the JM> PDF library, and that's where I noticed that the Lab colors in SVG Color JM> 1.2 WD may be a bit underspecified. PDF and PostScript require a white JM> point (D50, D65 etc. as XYZ coordinates) when defining a L*a*b* color JM> space. The black point is optional and defaults to [0,0,0]. The spec JM> doesn't say if a particular white point is assumed You are correct that its underspecified. I was assuming a D65 whitepoint but should have stated that. Furthermore, several widely used RGB colour spaces use a D50 whitepoint. It should therefore be possible to go from there to LAB without involving an adaptation transform. So there is a need to be able to specify the whitepoint. JM> or if it is dependent JM> on the user agent (meaning it's configured in the application). It may JM> be useful to clarify that. I suspect that we don't have to care about JM> the black point. I haven't seen any indication that this is widely used JM> (relatively speaking). I tend to agree that an implicit black point of 0,0,0 will be fine. JM> I'm not sure if it makes sense, but the spec might be changed to: JM> <fallback> cielab(<Lightness>, <a>, <b>, JM> [<IlluminantName>|<WhitePointX>, <WhitePointY>, <WhitePointZ>]) JM> | JM> <fallback> cielchab(<Lightness>, <Chroma>, <Hue>, JM> [<IlluminantName>|<WhitePointX>, <WhitePointY>, <WhitePointZ>]) JM> <IlluminantName> is the name for a standard illuminant like "D50" or JM> "D65" provided for convenience. Implementations should assume "D65" when JM> no explicit white point is given Yes. To avoid needless verbosity, an implied white point should be provided if none is specified; and the commonest whitepoints should be accessible by keyword rather than having to provide the chromaticity coordinates. JM> and should at least support the values JM> "D50" and "D65" which are the most often used. Yes, those two are the most often used, with D65 the most common. A couple of oddball older spaces use illuminant C (which is a bad idea, I think, but that can be expressed using the). JM> Alternatively, an JM> explicit white point expressed in CIE XYZ coordinates can be supplied. There are (at least) four reasonable ways to specify an illuminant; I wonder which would be more useful? Dnn (only for daylight illuminants, with a colour temperature of nn00 degrees). Absolute X, Y, Z Absolute Y and relative (chromaticity) x,y Black body colour temperature, in K. (only for neutral blackbody radiators) Lindbloom gives equasions to convert an arbitrary daylight illuminant Dnn to the chromaticity coordinates http://www.brucelindbloom.com/index.html?Eqn_XYZ_to_RGB.html of those, the Dnn notation is common and the absolute XYZ seems to be the next most common. JM> As an implementation-note: neither PDF nor PostScript directly support JM> CIE LCHab directly. Instead these colors will have to be converted to JM> L*a*b* for PDF and PS. Yes - but the conversion is trivial. C,H is the polar form of a,b. CIE LCHab is useful as an interpolation colour space, and is useful for animation (hue and chroma (~= saturation) can be separately animated. So its a good fit for SVG and easily converted to the rectilinear form of LAB if producing PDF. I am tending to believe that the spec should also specify the Bradford adaptation transform when converting colours between colourspsaces that use a different illuminant. JM> References: JM> - http://en.wikipedia.org/wiki/D65 JM> - http://en.wikipedia.org/wiki/Lab_color_space JM> I hope that's useful. It is, very much so. JM> Jeremias Maerki -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Friday, 9 July 2010 12:42:04 UTC