W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: [css3-color] New last call for comments on CSS Color

From: Chris Lilley <chris@w3.org>
Date: Wed, 29 Sep 2010 20:26:52 +0200
Message-ID: <277457754.20100929202652@w3.org>
To: Alan Gresley <alan@css-class.com>
CC: www-style@w3.org, Dave Singer <singer@apple.com>
On Wednesday, September 29, 2010, 6:27:03 PM, Alan wrote:

AG> Chris Lilley wrote:
>> Hello www-style,

>> Dave Singer wrote:
>>> Is the HSL full-range (0-255 luminance) or video-range (16-235 
>>> luminance)?  This makes a BIG difference.
>> http://lists.w3.org/Archives/Public/www-style/2008Jul/0467.html

>> I notice that there was no response to this part of your comments. The answer is that the HSL values are full range not video range, as the algorithm 'to translate HSL to RGB' and examples given in section 4.2.4 makes clear.

>> http://dev.w3.org/csswg/css3-color/Overview.html#hsl-color

>> Therefore, no specification change was necessary. Dave, please respond to say that you agree with this conclusion.


AG> Upon researching color, OS and display devices I see that since about 
AG> 2006 there have been display devices that extends outside the sRGB 
AG> gamut. 

There have, yes, but that is not what this comment is about.

Analog broadcast video historically allocated some headroom and footroom, so that 'black' did not correspond to zero volts but to a value above zero; similarly white was not the maximum voltage but a lesser value. With the change to digital broadcast video this was retained, giving the 16/255 to 235/255 luminance range to which Dave refers.

However, the L in HSL stands for lightness, not luminance or 'video luminance' (gamma corrected luminance). So the L value in an HSL colour can indeed use a value from 0 to 255, it does not need to leave headroom and footroom values reserved.


AG> These display devices use scRGB color space [1]. One example is
AG> HDMI [2] with output as xvYCC [3] [4]. With the launch of Windows 7 
AG> with 64-bit (use 48-bit color depth) OS, an OS can now generate colors
AG> in scRGB color space. I do not know quite how the technology works 
AG> (like device pixels) but it allows negative values and very high values.

Your general comment about wide gamut screens is correct. There are wide gamut displays, some of them use rgb values in a 0..255 range but get the wider gamut by referring directly to more saturated primaries. Some of them on the other hand refer to the sRGB primaries (which are the same as the rec.709 digital broadcast TV primaries) but get a wider gamut by using values less than zero, or more than 255. This allows an easier fallback for such signals, wide gamut screens use the full range and sRGB screens simply clip to 0..222 rather than performing gamut mapping.

AG> Via Wikipedia:

AG>    | scRGB is a wide color gamut RGB (Red Green Blue) color space
AG>    | created by Microsoft and HP that uses the same color primaries
AG>    | and white/black points as the sRGB color space but allows
AG>    | coordinates below zero and greater than one, the full range is
AG>    | -0.5 through just less than +7.5.

Yes.


AG> The reason for the last call comment is to suggest some prose in the 
AG> spec in CSS3 color that says both HSL and RGB can have values outside 
AG> the known 0 to 255 range.

The spec already allows values outside the 0...255 range for RGB values, using the rgb() notation. The #rrggbb syntactic form is however limited to strictly 8-bit quantities in the range 0..255.

Unfortunately the 1978 definition of HSL, which was deliberately simplified compared to other polar forms like Munsell space, OSA space  or the the 1976 LCHab color space, does not take into account wide gamut values. So, like the #rrggbb form, the hsl() form can't express this type of wide gamut colour range.




-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Wednesday, 29 September 2010 18:28:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:31 GMT