Re: CSS3 Color Comments: Clarification of hsl() hue parsing

On Wednesday, March 12, 2003, 10:36:33 PM, David wrote:


DW> Chris Lilley wrote:
>> 
>> On Wednesday, March 12, 2003, 8:22:26 AM, Boris wrote:
 
>> mod 360, so 370=10 and so on

DW> The algorithm provided needs to be modified,

clearly.
>> 
>> BZ>  Further, how are saturation and lightness
>> BZ> values outside the 0% to 100% range treated?
>> 
>> clipped

DW> Do you really mean this?

Yes.

DW>  This seems to give HSL a smaller gamut than
DW> sRGB.

It has the exact same gamut as sRGB.

DW>  There are real life colours (e.g. the extreme violet end of the
DW> spectrum) that require more than 100% saturation (they have a negative
DW> sRGB green component, because the normal red and blue phosphors++ cross-talk
DW> onto the eye's green receptors).

Thats inaccurate on detail but corect on generalities - ther eare
plenty of real-world colors outside the gamut of sRGB and these have
one or more components greaster than 100%, less than zero %, or both.

However, when HSL was being invented as a cheap, cut-down copy of LCH
around 1976, this sort of issue was not thought about much so that
algorithm assumes a cubical RGB gamut and does not deal sensibly with
R, G or B values outside to 0 to 100% range.

DW> Also looking through it, I noted these points:

DW> - it's inaccurate to say that the angles represent the rainbow colours;
DW>   there are hues (reddish purples) that it can represent, but which are
DW>   not rainbow colours;

I agree this is shoddy wording. Clearly, *none* of the rainbow (pure
spectral) colors are in the HSL or (any) RGB gamut.

DW> - when one looks further, the whole concept of a circle  is somewhat 
DW>   misleading, as what is actually represented (at l=0.5 and s=1.0) is
DW>   a constant speed walk (in sRGB gamma) along all six edges of the colour
DW>   cube in turn  (the walk has to be rather lumpy in subjective hue);

Yes, exactly. It is very uneven.

DW> - I think there should be a prominent warning that subjective brightness
DW>   depends on both hue and saturation (local peaks, as a function of hue,
DW>   at 60, 180, and 240, with an envelope peaking around 120, and with 
DW>   l=0.5 s=0.0 a lot darker than l=0.5 s=1.0, even for the hue minima, 
DW>   because of gamma issues) - this might confuse people trying to obtain
DW>   good contrasts without relying on hue;

I agree. Its a well known usability flaw of HSL that the three axes
are not at all orthogonal; lightness is not constant and depends
greatly on hue.

DW> - I've not convinced myself why gamma issues don't make subjective hue
DW>   a function of saturation,

They do.

DW> but, assuming that there were no spurious
DW>   gamma adjustments in the illustrations, I guess its OK;

DW> - I think that the description of opacity may have been lifted from SVG,

yes

DW>   losing the context which included the algorithm, and not gaining a 
DW>   hyperlink on the reference to masks - I am sure that transparency 
DW>   requires forward and inverse gamma to be applied, around the actual
DW>   merging.

You are absolutely correct that compositing requires the actual
colorspace used and the algorithm applied to be specidfied, otherwise
interoperability is out the window. You are also correct that SVG
specifies all this in detail.

DW> ++ any attempt to linearly combine three components in a physical system
DW>    that doesn't directly stimulate the optic nerve is going to suffer
DW>    from this sort of problem, even in a light source.

All light sources stimulate the optic nerve. Not sure what you are
trying to say here. Are you referring to additivity?

-- 
 Chris                            mailto:chris@w3.org

Received on Wednesday, 12 March 2003 19:31:01 UTC