Re: [csswg-drafts] [css-color-4] Allow out-of-gamut HSL/HWB colors (previously "Move gamut mapping to a future spec") (#8444)

> I think if you interpolate colors in HSL where the endpoints are out of gamut, you get what you get honestly.

For those curious about "what you get": https://mysterydate.github.io/web-demos/hsl-out-of-gamut-interpolation.html

Since Chromium is currently not gamut mapping the inputs (just allowing out-of-gamut values) and Safari TP _is_ gamut mapping, it provides a good side-by-side comparison.

Even in with `xyz` inputs, which are potentially _way_ out of gamut, it's rare that saturation goes negative. When that happens (for example `color(xyz 0 1 1)`), you do certainly get some artifacts. Interestingly, pulling the endpoints into gamut produces artifacts as well. For example, here are three gradients from full red to full green in hsl. For the top bar the endpoints are srgb (so, in gamut), the middle is with display-p3 endpoints (slightly out of gamut) and the bottom is with xyz endpoints (WAY out of gamut). This is a screenshot from the demo above. Apologies that the text here is hard to read:

<img width="1688" alt="Screenshot 2023-03-08 at 5 14 22 PM" src="https://user-images.githubusercontent.com/2529989/223889732-07eb9140-291d-412c-b6a7-547efc518b2d.png">

This result is more or less aligned with expectations. Each gradient is more saturated that the previous one. Even though display-p3 is outside of the hsl gamut, the resulting gradient looks fine because my display supports p3 (look at how much more vibrant the green is, for example). For the gradient with xyz endpoints the colors so saturated that the result is out of gamut for my display and as a result we see more saturation throughout the gradient.

This is as opposed to gamut mapping the endpoints _before_ generating the gradients:

<img width="1685" alt="Screenshot 2023-03-08 at 5 14 31 PM" src="https://user-images.githubusercontent.com/2529989/223889748-7897e18e-5497-4f8b-be30-d000461a0ae7.png">

Since the display-p3 gradient's endpoints are being pulled in to srgb, the result is no-longer brighter than using srgb endpoints. The xyz endpoints are pulled so far away from their original place that the gradient now looks totally different, interpolating from a not-quite-red to a not-quite-green.

> let color = new Color("oklch", [1, 0,0]).to('hsl').coords.toString();
> "223.8135974487593,-172.5242095991637,100.00000421453782"

Is this a library you're using for the `Color` object and the `to` function? The result I get for the conversions defined in the spec for `oklch(1 0 0)` is hue: 186 saturation: 481% lightness: 100%, so it's certainly out of gamut, but the saturation is non-negative.

> If needed, this could be managed by just clamping lightness to the SDR range during the HSL conversion if it exceeds those limits. None of the current color spaces are meant for HDR use at this time anyways.

This would be minimally invasive and really quite rare, though I think it would be better if we just left values as-is. This allows everything to rountrip always and keeps the implementation as simple as possible with the only cost being some artifacts when interpolating certain _far_ out of gamut colors in HSL.



-- 
GitHub Notification of comment by mysteryDate
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8444#issuecomment-1462494396 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 9 March 2023 17:48:38 UTC