[css-color-4] Parse-time clip of HSL negative saturation for modern syntax?

[romainmenke]

csswg-drafts/css-color-4/rgbToHsl.js

Line 16 in 61da22e

: (max - light) / Math.min(light, 1 - light);

rgbToHsl(1.5, 1, 1)
// (3) [0, -100, 125]

This only happens when the sum of all channels exceeds 3.

• rgbToHsl(1.5, 1, 0.5) -> negative saturation
• rgbToHsl(1.499999, 1, 0.5) -> very high, but positive saturation of 99999900

I get better results when I clamp saturation to 0.

---

I don't know if clamping to 0 had unintended side effects here.

[facelessuser]

I will note that not every algorithm for a color space is limitless, sometimes there are simply inherent limits to a color space
algorithm, and what you've stumbled on is simply the limit of HSL. HSL cannot properly handle such a color. It simply cannot round trip it.

>>> Color('srgb', [1.5, 1, 0.5]).convert('hsl').convert('srgb')
color(srgb 1 1 1 / 1)
>>> Color('srgb', [1.49, 1, 0.5]).convert('hsl').convert('srgb')
color(srgb 1.49 1 0.5 / 1)

Negative saturation is how HSL deals with colors with a lightness that exceeds 100%. Large saturation is how it generally deals with colors saturated beyond its gamut. Now, none of this is by a design as it is only designed for in gamut colors, but more incidentally.

The example you've given is actually outside the visible gamut. I don't think such a value is a real world concern. If you are talking about a gamut such as Rec. 2020, I believe it should handle all colors in the gamut fine, but the shape will be far from a cylinder 🙂.

[romainmenke]

Yes, 1.5 is a more extreme example :)

It was this test that triggered a failure on my end : https://github.com/web-platform-tests/wpt/blob/00e27884bfe6426de9c3e7c33e32db76bc1faed8/css/css-color/parsing/relative-color-out-of-gamut.html#L52

hsl(from lab(100 104.3 -50.9) h s l)

This eventually becomes rgb(255, 246, 244) and to me this seemed to be caused by the negative saturation returned by the sample algorithm for hsl.

When clamping the saturation to 0, I get the correct result (rgb(255, 255, 255))

[facelessuser]

Ah, I haven't looked as closely at the sequencing of steps for relative color syntax, so I can't speak to whether the tests accurately represent the spec. I'm not sure exactly when things get clamped and/or gamut mapped during the process.

[romainmenke]

Previously we did a gamut mapping step when converting lab(100 104.3 -50.9) to hsl.
But after #8444 we removed this step.

(maybe my understanding of that resolution was wrong :) )

Gamut mapping helped here because it ensured that any input color would have sane value ranges for a given color model/space.

[facelessuser]

Gamut mapping helped here because it ensured that any input color would have sane value ranges for a given color model/space.

Well, define sane. They were restrained to sRGB. I don't know if the tests are doing what they should or not, but I know that lab(100 104.3 -50.9) perfectly round trips through HSL. It doesn't appear that the negative saturation is having an adverse effect and altering the color incorrectly.

>>> hsl = Color('lab(100 104.3 -50.9)').convert('hsl')
>>> hsl
color(--hsl 311.21 -5.5486 1.0906 / 1)
>>> hsl.convert('lab')
color(--lab 100 104.3 -50.9 / 1)

I also know if you gamut map in OkLCh referencing the color as HSL vs sRGB that you get different results. I'm not exactly sure what CSS does here. Does it use sRGB when gamut mapping HSL or does it gamut map HSL colors keeping them as HSL? I assume HSL.

>>> hsl = Color('lab(100 104.3 -50.9)').convert('hsl')
>>> hsl.clone().fit('hsl', fit='oklch-chroma').convert('srgb').to_string()
'rgb(255 255 255)'
>>> hsl.clone().fit('srgb', fit='oklch-chroma').convert('srgb').to_string()
'rgb(255 253.18 255)'

In neither case did I get rgb(255, 246, 244), but Colorjs.io matches mine as well for what it's worth.

> new Color('lab(100 104.3 -50.9)').to('srgb').toGamut({method: 'oklch.chroma'})
Color { coords: [ 1, 1, 1 ], alpha: 1 }
> new Color('lab(100 104.3 -50.9)').to('srgb').toGamut('srgb', {method: 'oklch.chroma'})
Color { coords: [ 1, 0.9951746276359744, 1 ], alpha: 1 }

It is possible there is something about RCS that I don't understand, some step(s) that I'm not executing. I haven't really given CSS color level 5 the same critical eye that I've given level 4.

[romainmenke]

🤔 After a bit of poking I think it's something completely different.
@facelessuser thank you for those results 🙇

---

Most color functions describe clipping of values outside certain ranges.

https://www.w3.org/TR/css-color-3/#hsl-color

If saturation is less than 0%, implementations must clip it to 0%. If the resulting value is outside the device gamut, implementations must clip it to the device gamut. This clipping should preserve the hue when possible, but is otherwise undefined. (In other words, the clipping is different from applying the rules for clipping of RGB colors after applying the algorithm below for converting HSL to RGB.)

But this should be done only during parsing.

In our implementation we always do this step, but after #8444 I think it becomes clear that we must only do it when parsing, and not when computing.

---

Are these the same or different colors?

hsl(from lab(100 104.3 -50.9) h s l)
hsl(from lab(100 104.3 -50.9) 311.21deg -5.5486% 1.0906%)
hsl(from white 311.21deg -5.5486% 1.0906%)
hsl(311.21deg -5.5486% 1.0906%)

---

Closing and filing a new issue to avoid confusion :)

[romainmenke]

see : #9259

[svgeesus]

Re-opening because clipping on parsing negative saturation in hsl() is:

• mandated by CSS Color 3
• not mentioned in CSS Color 4
• tested in WPT (and all browsers pass)

[facelessuser]

It may be possible that the HSL conversion algorithm can be altered to ensure that negative saturation is never returned and still have completely accurate results. Then negative saturation can be clamped at zero with no ceiling. When negative saturation occurs, it just rotates the hue by 180. So if you rotate the hue by 180, you can set the saturation to a positive value during conversion. Then there is no need to allow parsing negative saturation.

Going with this earlier example, we can correct the saturation and hue. Then when we convert back, we get the same value we had before.

>>> c1 = Color('lab(100 104.3 -50.9)').convert('hsl')
>>> c1
color(--hsl 311.21 -5.5486 1.0906 / 1)
>>> c1.set('s', lambda x: abs(x)).set('h', lambda x: x + 180).convert('lab')
color(--lab 100 104.3 -50.9 / 1)

I suspect this is generally true, but more experiments would need to be performed to ensure this is the case. I assume if there are outliers, the reasons would need to be explored as HSL has hard limits. Once the limits are exceeded, the results will never round trip back. But if you are using such extreme values, which are well outside the visible spectrum, with HSL, you get what you get 🙂.

>>> Color('color(srgb 1.5 1 0.5)').convert('hsl').convert('srgb')
color(srgb 1 1 1 / 1)
>>> Color('color(srgb 1.5 1 0.5)').convert('xyz-d65')
color(xyz-d65 1.4425 1.2701 0.37169 / 1)

[facelessuser]

As a note, I used the rec2100-pq HDR color space to generate 1,030,301 colors which I then converted to HSL. 363,630 returned negative saturation, every single one was able to successfully round trip to the original color after correcting the negative saturation and adjusting the hue.

So it seems HSL algorithm can be altered successfully to correct the negative saturation without introducing issues if negative saturation is a problem.