- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Thu, 16 Nov 2023 16:27:46 +0000
- To: public-css-archive@w3.org
Looking around this thread for points which have not already been addressed, or where the spec has not already been updated, I wanted to comment on > Is this to say that this powerlessness is really only an issue for conversions _into_ the color spaces with lightness as a component? It's an interesting thing to try to design around, in my opinion, because there are many different whites that a user could be trying to express: >`color(srgb 1 1 1)` = `lab(99.9988 0.0188053 -0.00110865)` or `lch(99.9988 0.0188379 356.626)` >`color(xyz-d65 1 1 1)` = `lab(100 9.06837 5.79284)` or `lch(100 10.7607 32.5703)` >`color(xyz-d50 1 1 1)` = `lab(100 6.11317 -13.2363)` or `lch(100 14.5798 294.79)` >`lab(100 0 0)` is yet a different white, quite similar to `srgb` white, but not quite. There aren't _many different whites_; sRGB white is the same as P3 white or rec2020 white, or media white in any SDR colorspace that has a D65 whitepoint. [`color(srgb 1 1 1`)](https://colorjs.io/apps/convert/?color=color(srgb%201%201%201)&precision=6) is `oklab(100% 0 0)` or `oklch(1 0 none)` or `color(xyz-d65 0.95046 1 1.08906)` - note that white in CIE XYZ is **not** "1, 1, 1". The conversions quoted above seem to have some small numerical inaccuracies which it would be worth chasing down as small errors can compount when many conversions are chained together. Problems arise when chromatic adaptation comes into play, because now we are computing corresponding colors (a color that looks the same as the original color did, after our eyes have adapted to a new white point). This affects `prophoto-rgb` which has a D50 white point, and also CIE Lab and LCH which also conventionally use a D50 white point due to their printing industry background. (This is another reason why operations like interpolation or gamut mapping are better done in Oklch rather than CIE LCH, it avoids two chromatic adaptation steps in the intermediate calculations). Note too that in a printing situation, our eyes are indeed adapted to D50 because the print to be evaluated will be in a viewing booth with lights which are exactly D50; and if there is a soft proof then the monitor displaying it will also have been adjusted to display a D50 white. On the web, the white of the page is D65 and that is what our eyes are adapted to; our eyes are _not_ adapted to D50. Given those caveats, [`color(srgb 1 1 1`)](https://colorjs.io/apps/convert/?color=color(srgb%201%201%201)&precision=6) is, to 6 significant figures, still `color(prophoto-rgb 1 1 1)` and to full precision the coordinates are `[0.9999999886663737, 1.0000000327777285, 0.9999999636791804]`. [`color(srgb 1 1 1`)](https://colorjs.io/apps/convert/?color=color(srgb%201%201%201)&precision=6) is, to 6 significant figures, `lab(100 0 0.00001)` or to full precision `[00.00000139649632, -0.000007807961277528364, 0.000006766250648659877]` and in LCH it is `lch(100 0.00001 none)` or to full precision `[0.9999999934735462, 3.727399553519285e-8, NaN]`. So the chromatic adaptation steps there have introduced a small error, but only visible in the numbers at 8 significant figures. Looking now at the `color(xyz-d65 1 1 1)` which was mentioned, it is not a white and is out of gamut for all D65-based RGB color spaces (for example, it is `rgb(108.523% 97.6912% 95.8708%)` or `color(rec2020 1.05174 0.9828 0.95795)`. Gamut mapping for display will pull that much closer to white, though. > [Looks like the language in the spec changed again](https://drafts.csswg.org/css-color-4/#specifying-lab-lch)? Yes, because there was [agreement that those colors displaying as white or black was a result of gamut mapping to the display](https://github.com/w3c/csswg-drafts/issues/8794#issuecomment-1542728452) so the spec changed to say that explicitly. > """ > If the lightness of a Lab color (after clamping) is 0%, or 100% the color will be displayed as black, or white, respectively due to gamut mapping to the display. > """ > So this would imply that the mapping should be done at used value time? Yes. See step 7 in [converting colors](https://drafts.csswg.org/css-color-4/#color-conversion). The only stage in color conversions where gamut mapping happens is now for actual display (previously it was also used for conversions into HSL or HWB); all other stages of color conversions aim to preserve lossless round-tripping. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8794#issuecomment-1814797058 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 16 November 2023 16:27:48 UTC