- From: Alan Gresley <alan@css-class.com>
- Date: Fri, 17 Sep 2010 21:23:22 +1000
- To: Alexis Shaw <alexis.shaw@gmail.com>
- CC: Christoph Päper <christoph.paeper@crissov.de>, "www-style@w3.org list" <www-style@w3.org>
Alexis Shaw wrote: > On 11 September 2010 21:49, Christoph Päper <christoph.paeper@crissov.de>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, <http://electron9.phys.utk.edu/phys135d/modules/m10/images/prism.jpg> on this page [2] (under the heading dispersion) and this image, <http://exoplanet.as.arizona.edu/~lclose/a302/lecture14/prism-and-refraction-of-light-into-rainbow-2-AJHD.jpg> 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 [snip] 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. <http://www.youtube.com/watch?v=x0-qoXOCOow> The 3D space (and the x, y and z floating points) can only perceived when it is rotated. 1. <http://en.wikipedia.org/wiki/Dispersion_(optics)> 2. <http://electron9.phys.utk.edu/phys136d/modules/m10/geometrical.htm> 3. <http://exoplanet.as.arizona.edu/~lclose/a302/lecture14/lecture_14.html> 4. <http://en.wikipedia.org/wiki/Nanometers> 5. <http://en.wikipedia.org/wiki/File:CIE1931_rgxy.png> -- Alan http://css-class.com/ Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
Received on Friday, 17 September 2010 11:23:55 UTC