W3C home > Mailing lists > Public > www-svg@w3.org > July 2010

Re: SVG Color 1.2 WD: Lab colors

From: Jeremias Maerki <dev@jeremias-maerki.ch>
Date: Mon, 12 Jul 2010 16:17:06 +0200
To: www-svg@w3.org
Message-Id: <20100712160925.2181.60BA733C@jeremias-maerki.ch>
On 09.07.2010 14:39:24 Chris Lilley wrote:
> 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).

Interesting. The colors I have to support (and what triggered my diving
into this) are Lab colors specified with D50.

> 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

That's what the PDF and PostScript specs do. From the PDF 1.4 spec:

(Required) An array of three numbers [XW YW ZW] specifying the
tristimulus value, in the CIE 1931 XYZ space, of the diffuse white
point; see “CalRGB Color Spaces,” below, for further discussion. The
numbers XW and ZW must be positive, and YW must be equal to 1.0.

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

That's what I'm seeing, too.

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

I don't have an opinion here. This is still a bit beyond what I have
learned so far.

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

Jeremias Maerki
Received on Monday, 12 July 2010 14:17:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:27 UTC