- From: Isaac Muse via GitHub <sysbot+gh@w3.org>
- Date: Sat, 18 Mar 2023 18:26:47 +0000
- To: public-css-archive@w3.org
This is because the OkLCh algorithm does not resolve to a perfect zero (except maybe for black) when a color is achromatic. There are some color spaces that do even worse, but OkLCh is the worse offender in CSS, and it really isn't that bad.
Compared to LCh though, OkLCh does a worse job and is actually more sensitive to the hue because chroma doesn't get as low as it does with LCh. The ideal hue for OkLCh is somewhere around 90˚ based on the CSS matrices, but using zero ends up being "close enough" and introduces only minimal error, but may slightly impact the round trip.
```py
>>> Color('white').convert('oklch').set('hue', 0).convert('srgb')[:]
[1.000000056645113, 0.9999999632010229, 1.0000001023697391, 1.0]
>>> Color('white').convert('oklch', undef=False).convert('srgb')[:]
[1.0000000000000049, 0.9999999999999981, 0.9999999999999999, 1.0]
>>> Color('white').convert('oklch', undef=False)[:]
[0.9999999935000001, 3.729999997759137e-08, 90.00000025580869, 1.0]
>>> Color('white').convert('oklch')[:]
[0.9999999935000001, 3.729999997759137e-08, nan, 1.0]
```
The CSS spec does mention the powerless when "close to zero" for things like LCh and OkLCh, but yes, it gives no specific directions beyond that. It also doesn't mention this for HSL, so conversions from OkLCh to HSL, could leave you with a color close to achromatic, but not quite in HSL.
> For extremely small values of a and b (near-zero Chroma), although the visual color does not change from being on the neutral axis, small changes to the values can result in the reported hue angle swinging about wildly and being essentially random. In CSS, this means the hue is [powerless](https://www.w3.org/TR/css-color-4/#powerless-color-component), and treated as [missing](https://www.w3.org/TR/css-color-4/#missing-color-component) when converted into LCH or Oklch; in non-CSS contexts, this might be reflected as a missing value, such as NaN.
Calculating some perfect threshold for each cylindrical space that resolves to identify achromatic exactly the same in all spaces when you convert to them may prove difficult as each color space has different levels of accuracy for chroma/saturation equaling zero, and the scaling is a bit different. I'm not sure how much CSS cares about this, at least with the current included color spaces, if most achromatic colors are firmly in the achromatic pocket, it is likely you could pick a threshold tailored to each space that is close enough.
You could eliminate a lot of these achromatic detection differences between spaces by identifying achromatic colors in a common space, like maybe taking the cross product of the color vector against the white point vector in the XYZ D65 color spaces (with some threshold for deviation away from zero). Then "closeness" for achromatic colors would be the same for each space. This would require an XYZ conversion when checking achromatic colors though.
--
GitHub Notification of comment by facelessuser
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8609#issuecomment-1474938840 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 18 March 2023 18:26:48 UTC