- From: Christopher Cameron via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Mar 2024 16:23:40 +0000
- To: public-css-archive@w3.org
> The algorithms are already there, just tell us what the performance constraints are and we can get you one that maximizes quality while fitting within them. I think the biggest sticking point is not performance, but rather color matching between CSS, images, video, and canvas. This is a long-shipping feature with interoperability across all browsers, works by default (no extra syntax), for all colors, and for all inputs (including for images with color profiles and perceptual color profiles). If color matching is to be preserved, then whatever is done with extremely-out-of-gamut colors needs to be done uniformly across all content types. **Re: performance:** Performance matters less and less as you to wider and wider gamuts. I need the option to clip P3 to sRGB because that is actually a critical performance path (fortunately, clipping is good enough there). I may want to clip Rec2020 to sRGB in some extreme case (but it's less likely). No (non-HDR) image or video is going to specify `oklch(90% 90% 0deg)`, so I'm quite okay with that particular pixel requiring some nontrivial math. I'd like that the browser have some flexibility as to where it draws the line between gamut mapping and clipping. In some circumstances, we may gamut map all the way down to the display's gamut. In some cases, we gamut map to P3 and then clip to the display's gamut (e.g, to color match with something that is being color managed by hardware). Also of note is that while a GPU can do lots without breaking a sweat, there are browser implementations that render pixels on the CPU, and that comes with some severe restrictions. **Re: chroma reduction:** This was something that I wanted to get into more in the discussion (it's in the slides), but didn't. Chroma reduction isn't acceptable for images and videos and canvases (I think this is generally agreed upon), but it also severely violates the meaning of CSS colors. As an example, this is the true `L=1` plane of `oklch`, darkened so that you can see its intersection with the P3 gamut on a normal display.  It isn't white -- it's very colorful! If one wants that plane to be `white`, one wants a different space. Imposing transformations on all colors to make it so that this particular plane that isn't `white` be `white` is going to complicate things. Because `oklab` is a perceptually uniform space (so geometric distances correspond to perceptual distances), I would want to do something roughly equivalent to finding the nearest point to the gamut (in euclidean distance) that has the same hue. That's vaguely what's gone on the right (though math was done sloppily). **Re: interop:** For inputs that are nonsensical, interoperability is probably the most important priority. All browsers currently clip, and this has a fairly decent interoperability story. If all browsers were to agree to do the aforementioned hue-preserving projection to "something pretty near the display's gamut" (the lazy implementation would be to first hard-code Rec2020, and refine from there) the interop story would be strictly better than clipping. There would be a discontinuity as different browsers implement it, but if there is alignment on that, I'd be in favor of it. -- GitHub Notification of comment by ccameron-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-2025617680 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 28 March 2024 16:23:41 UTC