Re: [csswg-drafts] [css-color-4] Move gamut mapping to a future spec (#8444)

> [Section 13.2 of CSS Color 4](https://www.w3.org/TR/css-color-4/#css-gamut-mapping) contains a non-normative section describing a binary search gamut-mapping algorithm. 

[Section 13.1. An Introduction to Gamut Mapping](https://w3c.github.io/csswg-drafts/css-color-4/#gamut-mapping-intro) 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](https://w3c.github.io/csswg-drafts/css-color-4/#css-gamut-mapping) 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](https://w3c.github.io/csswg-drafts/css-color-4/#color-conversion) 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](https://w3c.github.io/csswg-drafts/css-color-4/#interpolation-space) If the colors to be interpolated are outside the gamut of the [interpolation color space](https://w3c.github.io/csswg-drafts/css-color-4/#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. ](https://w3c.github.io/csswg-drafts/css-color-4/#convert-display) If dest is a physical output color space, such as a display, then col2 must be [css gamut mapped](https://w3c.github.io/csswg-drafts/css-color-4/#css-gamut-mapped) so that it [can be displayed](https://w3c.github.io/csswg-drafts/css-color-4/#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.](https://w3c.github.io/csswg-drafts/css-color-4/#convert-hslhwb) If dest cannot represent [out of gamut](https://w3c.github.io/csswg-drafts/css-color-4/#out-of-gamut) colors, for example [hsl](https://w3c.github.io/csswg-drafts/css-color-4/#valdef-hsl-hsl) or [hwb](https://w3c.github.io/csswg-drafts/css-color-4/#valdef-hwb-hwb), then col2 must be [css gamut mapped](https://w3c.github.io/csswg-drafts/css-color-4/#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



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


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

Received on Monday, 13 February 2023 20:57:44 UTC