[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?

[svgeesus]

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?

That still needs to be discussed.

[tabatkins]

The big benefit of letting HSL/etc go out of gamut is to avoid having to specify the precise gamut mapping right now; if we still have to gamut map before interpolating that defeats the point.

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

[facelessuser]

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

That's a fair statement. Currently, saturation only goes negative when lightness goes negative or when in the HDR range. The only way it could accidentally go out is if you are converting from one of the newer color spaces like Oklab, OkLCh and maybe Lab and LCh which is not always very precise at the edges.

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

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.

[mysteryDate]

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:

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:

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.

[svgeesus]

Worth noting that oklch 1 0 0) should be sRGB white and (in color.js) converts to white to 8 significant figures:

rgb = [0.9999999694343976, 1.000000008665371, 1.000000114856359]

but the HSL algorithm seems totally thrown by those fractionally higher than 1.0 numbers.

[svgeesus]

The sRGB to HSL code in color.js is the same as the sample code in CSS Color 4

[facelessuser]

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.

This is using the color library that the CSS color spec writers maintain: https://colorjs.io/. Depending on the precision of the matrices, and the precision of the values that are maintained, that value could be slightly different.

The exact value is probably not as important, but the point is simply that the algorithm was never designed to give you an exact sRGB [1, 1, 1] white. And when lightness exceeds the SDR range, that is when you can get negative saturation. If CSS doesn't care right now, that is fine, but I just want to make sure all the info is there to make an informed decision.

[svgeesus]

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.

That seems reasonable to me. If people want perceptually uniform results they should not be interpolating in HSL or HWB anyway.

[facelessuser]

That seems reasonable to me. If people want perceptually uniform results they should not be interpolating in HSL or HWB anyway.

Yeah, this is probably the most important point. If you are using OkLCh, why are you converting back to HSL to do interpolation? 🙂 It may be worth noting that you could get odd results if you do though.

[mysteryDate]

Excellent! I will begin writing a PR on this repo that allows unbounded HSL and HWB in that case.

[svgeesus]

I would like to hear from WebKit and Gecko developers about allowing out-of-sRGB-gamut HSL and HWB colors, before making the spec edits (but personally feel this is a good direction). @weinig @emilio ?

[mysteryDate]

I believe @smfr and @litherum of Apple were okay with this change as well. Seeing if I can summon them.
Presumably we'd get some feedback on the PR as well.

[svgeesus]

Note to self the Color 5 hsl color-mix() example still uses gamut mapping on conversion to hsl, and needs to be recalculated.

[svgeesus]

Closing this (and other issues where no change to the spec is expected).

[svgeesus]

I wrote:

Note to self the Color 5 hsl color-mix() example still uses gamut mapping on conversion to hsl, and needs to be recalculated.

Fixed by 9b3bff8

[danburzo]

If I’m not mistaken, the resolution to serialize the result of RCS using rgb, hsl, etc. as color(srgb …) still requires additions to [css-color-5] § 10.2. Serializing Relative Color Functions similar to color-mix()?