Re: CIE color definitions in CSS3 color module

Alexis Shaw wrote:
> On 11 September 2010 21:49, Christoph Päper <>wrote:
>> Alexis Shaw:
>>> A CIE XYZ color definition.
>> This will certainly not make it into level 3 of the Color module, but I
>> guess you would be fine with level 4, too.
>> We only have HSL, not HSB/HSV or HSI and neither chroma-based HLC or HVC,
>> so why should there be more than one kind of CIE color definitions?
>> (Actually, I think CSS Color should define a syntax for every common system
>> there is, but make only certain ones mandatory.)
>>  hsi(<hue>, <saturation>, <intensity>)
>>  hsv(<hue>, <saturation>, <brightness>)
>>  hlc(<hue>, <lightness>, <chroma>)
>>  hvc(<hue>, <brightness>, <chroma>)
>> As far as I understand color spaces and definitions,
>> - RGB is how screens build up colors (or close to it),
>> - CMYK is how printers build up colors (or close to it),
>> - HS* are compromises between how screens and people handle colors,
>> - CIE *** describe what colors people can see.
> Please note that they define ALL the colors that people see.

This is true but it does not define the colors that people can
perceive. If such a limited gamut of sRGB color-space can produce
16,777,216 values or 16,777,215 colors (minus black), this far
exceeds the the average 10 million that a person can observe in
theorized xyz color space.

>> Is there a point to be made in favor of luma (or luminance) based YUV/YIQ
>> or xvYCC/YCbCr …?
>>  ycc(<luma>, <blue chroma>, <red chroma>)
>>> xyz(x, y, z)
>>> where x, y and z are the floating point values of the CIE 1931 XYZ color
>> space
>> Are x, y, z normalized to a certain interval, like [0, 1], [0, 100] or [0,
>> 255]?
>> If this was not done usually, would it be okay for CSS to do so?
> X, Y and Z colours are normalised as values so that Y is between 0 and 1 in
> the ICC profile standard, and between 0 and 100 in the CIE standard. this
> means that X and Z can be reasonably be in [0,2) and [0, 200) respectively.

So you are proposing where we should set the endpoint? There may be a 
CIE standard or ICC profile standard but none of these even suggest 
that the floating point y is really a point between the floating 
points x and z.

The theory of dispersion of light [1] is wrong. The premise is this.

   | In a prism, material dispersion (a wavelength-dependent
   | refractive index) causes different colors to refract at
   | different angles, splitting white light into a rainbow.

A misconception is that that pure light is white. If light is 
polarized (linear polarization) and aimed at a prism, then no 
dispersion happens until it exits the prism. When is does, it 
disperses into a spectrum from red to violet (midpoint white). At a 
point, the red disperses into a band of red~yellow and violet 
disperses into a band of blue~violet. At some point further along the 
dispersion, the luminance of midpoint decreases until green emerges as 
a distinct color.

This is seen in this image,


on this page [2] (under the heading dispersion) and this image,


on this page [3].

So how can X, Y and Z colors be normalized when one classical theory 
of light is wrong?

I do suggest that we use nanometers [4].

   Red = 700nm
   Green = 546.1nm
   Blue = 435.8nm

And hopefully those from CIE, ICC or other scientist can work out 
where the start and end of an octave of color is in the spectral (or 
monochromatic) locus. An octave of color operates like an octave in 
music. In music, each successive point in an octave range (ei. from C 
to C) has a wavelength that has doubled in length. So somewhere in the 
CIE 1931 chromaticity diagram [5] is an octave of color, where the 
wavelength doubles in length.

If we know this octave, which is between 380nm to 810nm, then we can 
map such an octave to [0,1], [0, 100] or  [0,2], [0, 200] and use what 
Christoph has said (below) as a method to clamp color (monochromatic) 
to a display type.

   | For example, “rgb(80%, 48.5%, 12.5787587%)” works just fine
   | today, even if it results in exactly the same color value as
   | “rgb(204, 124, 32)”.

>>> xyy(x, y, Y)
>>> where x, y, and Y are the floating point values of the CIE 1931 xyY color
>> space.

No, x, y and z are floating points in CIE 1931 xyz color space.

With x, y and Y, we have.

x = x / x + y + z
y = y / x + y + z
z = z / x + y + z = 1 - x - y

which is CIE xyY color space. Alexis has similar below.

>> How does Y differ from z? If it’s a simple transformation, why would you
>> need two separate ways?
>> Are x, y, Y normalized to a certain interval, like [0, 1], [0, 100] or [0,
>> 255]?
>> If this was not done usually, would it be okay for CSS to do so?
> xyY derived from XYZ by the following.
> x = X/(X+Y+Z)
> y = Y/(X+Y+Z)
> Y = Y and Y is relative luminance. as above
> x-[0,1]
> y-[0,1]
> Y-[0,1] / [0,100] as above.
> this is useful as Y is a lumanance value, and the xy chromacity diagram is
> well known

So at the very least, CIE xyY color space is possible but CIE 1931 xyz 
color space can only be achieved when we (not necessary someone on 
this list) can map the monochromatic colors of the spectral locus to a 
3D space which is outside RGB color space but where black is the same 
point in both models. This is something that this video shows.


The 3D space (and the x, y and z floating points) can only perceived 
when it is rotated.

1. <>
2. <>
4. <>
5. <>


Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo

Received on Friday, 17 September 2010 11:23:55 UTC