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

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](https://github.com/wicg/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](https://www.w3.org/TR/css-color-4/#convert-hslhwb) in converting colors could be removed. And since colors are now possibly out-of-gamut [Converting sRGB Colors to HSL](https://www.w3.org/TR/css-color-4/#rgb-to-hsl) would need to deal with rgb channels outside of the [0,1] range:
> 
> ```js
> /**
>  * @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](https://drafts.csswg.org/css-color-4/#GM-clip). 

> 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.


-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8444#issuecomment-1428334158 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 17:15:20 UTC