Re: [csswg-drafts] [css-color-4] Channel clipping breaks author expectations, especially when using 'perceptually uniform' spaces (#9449)

(Apologies, this was meant to be posted a month ago. I was delaying while I got feedback from Apple/Moz folks, and then after I got that feedback, I forgot to actually *post* the message.)

Resetting the conversation a bit, we've put our heads together in
Chrome to try and find a satisfactory path forward. We have a new
proposal, along with the constraints that led to it, that we think
satisfies a lot of the competing interests here.


Constraints
-----------


1. *Regardless* of the gamut mapping method used, if an author uses a color that is far outside their monitor's gamut, they will have no idea what that color *actually is*. In the future (or even today), better monitors will result in that specified color mapping to a different color than what they designed their page against - potentially, even likely, a *substantially* different color - which is future-hostile.

    * We should ensure that authors can write pages today which, *by default*, will display at least *roughly* as intended in the future.

2. CSS and images/videos have had color-matching in sRGB and P3 for many years. (This wasn't always true, but we were able to pull it off in CSS2.) This is still a common, important use-case for authors, and\ as images are now being deployed in the wild using P3-compatible gamuts or wider, we want to preserve it.

    * We should ensure that, *by default*, CSS colors and image/video colors map in the same way so color-matching works when both are using the same gamut, at least within realistic image/video gamuts.

3. Particularly within those "realistic" image/video gamuts, performance/energy/etc is a significant concern, so UAs should be allowed to continue using fast, hardware-accelerated mapping methods. While it can have noticeably bad results in larger spaces, we think that naive clipping gives satisfactory results when reducing from Rec2020 to sRGB, and any space in-between.

    * To be consistent with (2), then, we should allow UAs to use naive clipping if reducing a color that is already within the Rec2020 gamut. If the color is outside Rec2020, better mapping methods can be used.

4. All of the above are *defaults*, designed to handle common cases, and help authors who do not have high levels of color knowledge still design predictable, safe pages while benefiting from the new color spaces. Advanced use-cases do exist, however.

    * The automatic gamut-reduction should be opt-out, to allow advanced users to get exactly what they're intending.


Proposal
--------

(1) We propose that, by default, uses of the oklab() and oklch() syntaxes get reduced to the Rec2020 gamut (precisely when the reduction occurs needs further discussion; what the best behavior is with gradients is non-obvious and should be thought about more). We're not picky about the algorithm used to do this mapping; we’re OK with what the WG consensus ends up at.

Colors specified using other syntaxes that, today, would be equivalent to those oklab() or oklch() syntaxes would not be mapped in the same way; we presume that these other syntaxes are likely used either to match with an image gamut (where you'd want the CSS color to be treated identically to the image) or are otherwise something that would only really be reached for by advanced users. (We can accept having the other color functions mapped to Rec2020 by default, with consistent opt-outs, but are moderately opposed to it. As far as we can tell it's not necessary or wanted.)

The author should also be able to specify that they want an oklab/oklch color *without* this automatic reduction. We're similarly not picky about the syntax for this: perhaps an `oklch(extended 60% .2 0deg)` keyword, or an `oklch-extended(60% .2 0deg)` function. Whatever the WG decides on is fine.


(2) We propose that, when mapping a *used* color into the monitor gamut, by default it is done by naive r/g/b channel clipping, to match existing image/video gamut reduction behavior.

We expect there will be ways added to override this behavior for particular colors. For example, we could borrow an idea from the HDR world and allow authors to specify both a target color and a reduced-gamut (maybe specifically sRGB?) version of it, and require implementations to gamut-map along the line connecting them. Or we could allow authors to specify that a particular color must be mapped to preserve a certain level of contrast with a particular other color.

(3) We propose that interpolation should continue to happen the way it does today, in an unguarded oklch/oklab space. Authors should be able to use the opt-out syntax, if needed, to fix any existing pages that are no longer working as intended.


Some downsides of the above (that we’re ok with):

* oklch() and oklab() currently in the wild can change their displayed color for some argument combinations.  (But should better match what the spec intended. And the opt-out should allow recovering the previous behavior when needed.)

* The other ways of specifying colors, besides oklab/oklch, don't get the gamut reduction. (We don't see anyone saying authors have an expectation when writing something like color(rec2020 200% -50% 30%).)


----------

Some paraphrased/quoted feedback I got from Apple/Moz folks:

* Simon Fraser finds the overall proposal reasonable, but wonders if Rec2020 is sufficiently future-proof as the "base" gamut we map down into.
* Simon says that CoreGraphics defaults to the kCGRenderingIntentPerceptual (the "shift all the colors" one) for images, but as far as ccameron can tell that's not the case.
    * "Even when an image's ICC profile specifies a perceptual mapping (which is rare), that mapping is a deterministic mapping to XYZD50, and so the image can still be color matched with CSS colors." ~ccameron
* Simon is pretty sure we will need to give authors a gamut-mapping choice in the future.
* Tiann Louw (Moz) says "The default in 1) of rec2020 and having the opt in/out syntax seems to complicate things a little bit for authors, but don't think it's a blocker at this point.  The rest seems quite reasonable to me."

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


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

Received on Wednesday, 12 June 2024 07:19:32 UTC