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

[mysteryDate]

Section 13.2 of CSS Color 4 contains a non-normative section describing a binary search gamut-mapping algorithm. Though user agents are beginning to ship CSS Color 4, there is still a lot of ongoing debate over the appropriateness of this algorithm (#7610). Proposed alternatives can be found here: #7653.

Some UA developers met recently to discuss the issue. A consensus was reached that it would be better to allow out-of-gamut color conversions to remain out-of-gamut (as opposed to clipping) while the working group continues to develop a gamut mapping algorithm. To that end, we could move the entire section 13 to a CSS Color 5 or 6 while this work is being done.

For CSS Color 4, step 8 in converting colors could be removed. And since colors are now possibly out-of-gamut Converting sRGB Colors to HSL would need to deal with rgb channels outside of the [0,1] range:

/**
 * @param {number} red - Red component
 * @param {number} green - Green component
 * @param {number} blue - Blue component
 * @return {number[]} Array of HSL values: [snip]
 */
function rgbToHsl (red, green, blue) {
   red =   Math.min(Math.max(red,   0), 1); 
   green = Math.min(Math.max(green, 0), 1);
   blue =  Math.min(Math.max(blue,  0), 1);
   let max = Math.max(red, green, blue);

Since color-mix() from CSS Color 5 is the only feature for color 4 or 5 that can result in intermediate out-of-gamut results, our exposure to out-of-gamut colors would remain relatively minimal and we can preserve interoperability. Leaving out-of-gamut results and not clipping avoids the worst results, like saturation at the boundaries and different results for canvases. It has the added bonus of color conversions round tripping.

[LeaVerou]

I think there are some misunderstandings here.

• The primary place that gamut mapping happens, is to display a color on the user's actual screen, and that's the kind of gamut mapping you cannot avoid. When it gets down to hardware, you cannot output 120% of a component, you need to map, and simply clipping tends to produce unacceptable results, unless you're close to the gamut boundary.
• I think (@svgeesus please confirm) that we (editors of CSS Color) are happy to have intermediate calculations not be gamut mapped, since most of them should happen within infinite gamut spaces anyway. What matters is gamut mapping for display.
• If intermediate calculations are not gamut mapped, this would affect what authors read back as used values through the CSSOM; so there needs an alternate way for them to figure out what color is actually displayed, though that could be a Color API method.

Some UA developers met recently to discuss the issue.

Do you mean that you met with your team, or was this a more diverse group of UA developers, including developers from other UAs? If it's the latter, I don't understand why the discussion did not happen in the CSS WG; that's what it's for. If the former, it would be helpful to phrase it that way to prevent misunderstandings.

To that end, we could move the entire section 13 to a CSS Color 5 or 6 while this work is being done.

Please note that CSS Color 5 is pretty mature, with all of its current features cleared for shipping.

For CSS Color 4, step 8 in converting colors could be removed. And since colors are now possibly out-of-gamut Converting sRGB Colors to HSL would need to deal with rgb channels outside of the [0,1] range:

/**
 * @param {number} red - Red component
 * @param {number} green - Green component
 * @param {number} blue - Blue component
 * @return {number[]} Array of HSL values: [snip]
 */
function rgbToHsl (red, green, blue) {
   red =   Math.min(Math.max(red,   0), 1); 
   green = Math.min(Math.max(green, 0), 1);
   blue =  Math.min(Math.max(blue,  0), 1);
   let max = Math.max(red, green, blue);

This is still a form of gamut mapping, just not a very good one; you’re basically doing clipping.

Since color-mix() from CSS Color 5 is the only feature for color 4 or 5 that can result in intermediate out-of-gamut results

This is incorrect. Relative Color Syntax can also produce out of gamut results, as well as directly specifying values in LCH, Lab, OKLab, OKLCH. I would expect these to be far more common ways of getting OOG than color-mix().

I think part of the confusion lies on the fact that there are two types of out-of-gamut:

a) Out of gamut of the specified color format (e.g. rgb(from red, calc(r * 1.05) g b) is OOG for sRGB, even though it's not OOG for a P3 display)
b) Out of gamut of the display device (e.g. even an sRGB color like red could be OOG for a 2013 MacBook Air, whose gamut is approximately 60% of sRGB).

When talking about where gamut mapping should be applied, we need to be clear about which OOG we're talking about.

[svgeesus]

Section 13.2 of CSS Color 4 contains a non-normative section describing a binary search gamut-mapping algorithm.

Section 13.1. An Introduction to Gamut Mapping is a non-normative backgrounder to explain to implementers the design decisions for section 13. In particular it explains the quality differences between a change in chroma (not very visible unless large), a change in lightness (more visible, but acceptable if small) and a change in hue (very visible unless very small).

Section 13.2. CSS Gamut Mapping to an RGB Destination is normative, and defines (to a given tolerance, which is much smaller than any visible difference) a specific location on the gamut boundary which intersects with a constant-hue, constant lightness ray from the origin color to the achromatic axis in Oklch.

There are two methods to find this point; one is iterative and one is analytical. To the tolerance specified, they give the same result. Describing the implementer choice between these two as "non-normative section" is quite incorrect. They give the same result.

Naive clipping finds an entirely different point, with very different properties: for any origin color which is visibly different to the gamut boundary point specified in 13.2, it gives a result with large difference in hue and in lightness.

Some UA developers met recently to discuss the issue.

Private and unminuted meetings are a suboptimal way to reach working group consensus. They are much more likely to come to inaccurate or erroneous conclusions, based on incorrect assumptions or misunderstandings. Such as:

A consensus was reached that it would be better to allow out-of-gamut color conversions to remain out-of-gamut (as opposed to clipping)

That isn't a change. The specification already requires that intermediate results are retained, not gamut mapped:

Colors may be converted from one color space to another and, provided that there is no gamut mapping and that each color space can represent out of gamut colors, (for RGB spaces, this means that the transfer function is defined over the extended range) then (subject to numerical precision and round-off error) the two colors will look the same and represent the same color sensation.

and again in 12.1. Color Space for Interpolation If the colors to be interpolated are outside the gamut of the interpolation color space , then once converted to that space, they will contain out of range values.

These are not clipped, but the values are interpolated as-is.

There are two places where some sort of gamut mapping is required however:

7. If dest is a physical output color space, such as a display, then col2 must be css gamut mapped so that it can be displayed.

As @LeaVerou already pointed out, no specification can require that a display emit colors that it can't display. That should be obvious.

8. If dest cannot represent out of gamut colors, for example hsl or hwb, then col2 must be css gamut mapped.

That is it. All other color space conversions can, and must, accomodate results which are out of gamut for the color space used.

So, bravo on forming a consensus that agrees with what the spec already says.

To address one additional inaccurate assumption, which @LeaVerou already mentioned:

Since color-mix() from CSS Color 5 is the only feature for color 4 or 5 that can result in intermediate out-of-gamut results

Wrong. Out of gamut results are trivially possible from:

• direct specification (color(display-p3 -0.1 1.1 0) is out of gamut for display-p3, but is a perfectly valid color
• relative color syntax (color(from color(display-p3 0.7 0.7 0.7) calc(r*2) g b) is out of gamut for display-p3, but is a perfectly valid color
• color-mix(), particularly in polar color spaces
• gradient interpolation, particularly in polar color spaces
• animation or transition, particularly in polar color spaces

[mysteryDate]

I think part of the confusion lies on the fact that there are two types of out-of-gamut:

a) Out of gamut of the specified color format (e.g. rgb(from red, calc(r * 1.05) g b) is OOG for sRGB, even though it's not OOG for a P3 display)

b) Out of gamut of the display device (e.g. even an sRGB color like red could be OOG for a 2013 MacBook Air, whose gamut is approximately 60% of sRGB).

Thanks so much Lea. This clears things up quite a bit. The crux of the confusion are these tests, which, if I understand correctly are an instance of a) and not b)?

I think (@svgeesus please confirm) that we (editors of CSS Color) are happy to have intermediate calculations not be gamut mapped, since most of them should happen within infinite gamut spaces anyway. What matters is gamut mapping for display.

If both these things are true, then the tests are invalid, no? The gamut mapping will happen later in the pipeline, or even not at all if the display device is capable of colors outside the sRGB gamut?

8. If dest cannot represent out of gamut colors, for example hsl or hwb, then col2 must be css gamut mapped.

That is it. All other color space conversions can, and must, accomodate results which are out of gamut for the color space used.

So, we should be doing something similar to the aforementioned tests, but with hsl and hwb as output color spaces since they are simply incapable of representing out-of-gamut color (as opposed to not being able to display out-of-gamut colors)? Are hwb and hsl the only colors spaces for which that is the case?

The concern raised in this issue was primarily about interoperability, since Safari and Chrome are beginning to ship color-mix(). If we can resolve the issue about the appropriateness of the above tests, we can defer larger discussions about gamut mapping to pre-existing threads (i.e. #7653 and #7610).

[svgeesus]

The crux of the confusion are these tests, which, if I understand correctly are an instance of a) and not b)?

They are c) Not expressible in a given color format. HSL and HWB require in-gamut sRGB values as input, and give nonsense values if they get negative number or numbers grester than 100%. So, as the spec says, they need gamut mapped before the sRGB to HSL/HWB conversion step.

So (unlike gamut mapping to the used value on the display) this case is observable through script, and the tests are indeed valid. Used values are not exposed through script, the only way to see if the right color is being displayed is to physically measure it or compare it visually to a reference color patch.

[mysteryDate]

HWB require in-gamut sRGB values as input, and give nonsense values if they get negative number or numbers grester than 100%.

Do they, though? An experiment:

The srgb equivalent of display-p3 red (color(display-p3 1 0 0)) is color(srgb 1.09306 -0.226721 -0.150111). This is clearly out-of-gamut, but not nonsensical. Both UAs I've tested (safari TPM and chrome canary) treat it as valid input and wpt validates similar test cases as valid.

Using the algorithm defined in 7.2 and the srgb equivalent of display-p3 red as input [1.09306 -0.226721 -0.150111] we get the hsl equivalent of [356.51714943615644, 152.34001932269007, 43.31695]. See a demo here. This value round trips fine using the algorithm in 7.1, with some float-precision issues.

Is a hue of 356 degrees, a saturation of 152% and a lightness of 43% nonsensical if negative values and values greater than one for srgb are not?

Here's a demo for arbitrary values for display-p3 input, including HWB. All resulting values for hsl make sense if we allow saturation > 100%. The highest value I was able to see was about 300%. All values roundtrip to srgb with only rounding errors on the order of 10^-16. I see similar results with HWB, with some negative values for whiteness and blackness when out-of-gamut

Since color-mix() from CSS Color 5 is the only feature for color 4 or 5 that can result in intermediate out-of-gamut results

What I should have said here is "out-of-gamut results that are observable through script and are expected to be gamut mapped as opposed to left-as-is." Per the discussion here it would appear that we can further narrow this case to be color-mix values in the hsl and hwb colorspaces. If we allow representation of out-of-gamut hsl and hwb colors, like we already do for other colorspaces, then we can remove the need to gamut map colors in a script-visible way, which was the original intention of this issue.

[mysteryDate]

I did not intend to close the issue, apologies.

[svgeesus]

This value round trips fine using the algorithm in 7.1, with some float-precision issues.

Here's a demo for arbitrary values for display-p3 input, including HWB. All resulting values for hsl make sense if we allow saturation > 100%.

Interesting. I don't recall why I thought the values became nonsensical; I would need to look again.

If HSL and HWB were made unbounded, we would need to drop statements like this:

If the saturation or lightness are less than 0% or greater than 100%, they are clamped to those values at parsed-value time, before being converted to an sRGB color.

[facelessuser]

IIRC, HSL behaves in a fairly sane way when out of gamut within the SDR range, it mainly pushes saturation higher. I think when lightness exceeds the HDR range, either positive or negative, saturation goes into the negative which is a little weird, but it round trips fine. I don't think this is true for all HSL variants out there (OkHSL or HSLuv), but the traditional HSL does round-trip fine.

[mysteryDate]

f HSL and HWB were made unbounded, we would need to drop statements [like this](https://drafts.csswg.org/css-color- 4/#the-hsl-notation):

If the saturation or lightness are less than 0% or greater than 100%, they are clamped to those values at parsed-value time, >before being converted to an sRGB color.

I'm in favor! Would you like me to draft a PR to this repo of unbounded HSL and HWB?

If HSL and HWB are the only exceptions to the "keep out-of-gamut colors until use-time" paradigm, it would make implementations simpler and less surprising to make them behave like other colorspaces.

[svgeesus]

I don't recall why I thought the values became nonsensical; I would need to look again.

when lightness exceeds the HDR range, either positive or negative, saturation goes into the negative

Ah, right. And interpolating in HSL where one component has negative Saturation will give unexpected results.

However, I agree that it makes things more consistent if all color spaces can round trip values, and all CSS colors have a unique colorimetric value (which is also why we got rid of preserving hues outside [0..360]).

Would you like me to draft a PR to this repo of unbounded HSL and HWB?

Sure. I would also like to hear from @emilio and @weinig about this proposed change.

[facelessuser]

Ah, right. And interpolating in HSL where one component has negative Saturation will give unexpected results.

I assume, if the change to not clamp HSL saturation and/or lightness went into place, it would still be required to gamut map HSL before interpolating in that space to avoid such issues?