- From: Christopher Cameron via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Mar 2024 14:19:34 +0000
- To: public-css-archive@w3.org
> "Then from getting from that "some very wide gamut" to the actual screen, I'd prefer things to be non-normative because then we can implement something which is known to give bad results and be surprising to authors, but happens to be super fast so we just pass the burden of doing a good job onto each individual web developer". I'm just not sure if this is a productive contribution. I think I've made it clear that I'm not okay with "bad results" and that I'm explicitly trying to avoid being "surprising to authors". **Re: "surprising to authors"**. I posted this image earlier, but here's an updated version.  This is the surprise that I'm trying to fix here. If an author specifies content that is far outside of what their screen can reproduce, then there is no way to avoid having them be surprised when that content is accurately rendered on a more capable screen. This is very much a "the only winning move is not to play" situation. We shouldn't be giving authors tools where it is extremely easy to unintentionally specify such colors. But we did, in the `lab`, `lch`, `oklab`, and `oklch` spaces. The `oklab` and `oklch` spaces are excellent for perceptually uniform interpolation, but they are dangerous for color manipulation, because there are no guardrails for staying in-gamut. The [relative-color syntax](https://www.w3.org/TR/css-color-5/#example-fef81186) exacerbates this. **The problem** that I want for us to focus on solving here is how to avoid having authors specify colors that are far beyond their display's capability to produce. If we don't solve that problem then authors will inevitably face the above-described surprise. If we don't solve that problem then we also have to solve the problem of assigning meaning to colors that are physically meaningless or far beyond the capabilities of any current display. **A solution** is to provide new safe color spaces This puts the responsibility on the author to not specify content far outside of their display's capabilities. The [`okhsl`](https://bottosson.github.io/posts/colorpicker/) space is awesome. It is sRGB-safe in the sense that if the S and L coordinates are between `0%` and `100%` then the color is in sRGB. Those are clear and easy-to-follow guardrails. I could imagine a few directions to go here. We could add an analogous `okhsl-p3`, where if S and L are in `[0%, 100%]` then the color is in P3. We could also consider creating a space that is a more "rounded" version of `okhsl` to avoid the problems caused by the (literal) sharp corners of the gamut. Or we could just define how `okhsl` is extended, so that, say, `[0, 120%]` is approximately P3. Or a combination of both. It does, unfortunately, become a research problem. **Another solution** is to add guardrails to the dangerous spaces (or to all spaces) This takes away the ability from the author to specify content (too) far outside of their display's capabilities. These guardrails need to be tight enough to avoid specifying colors too far away from the capabilities of monitors that authors are likely to be using today. But not so tight as to make the spaces useless. Note that "gamut map to the display's capabilities" is not a sufficient guardrail here, because of the problem in the previous picture. It also breaks down when specifying colors to a canvas, because the canvas cannot know its display (and not just for fingerprinting -- an offscreen canvas doesn't know where it's headed, and machines can have several displays). And there's also the color matching issue. I went with Rec2020 as something that "doesn't feel too arbitrary". That said, this solution involves some arbitrariness, and I'd just prefer that we require that authors stay within the capabilities of their displays. I've also provided a way to test this via `chrome://flags`, so if there's a particular codepen that looks bad with this approach, we can discuss that. **Re: "bad results"**. I've tried very hard to find an example of P3 content that looks bad when clamped to sRGB. I just can't. The difference isn't large enough. I've also tried to do this with Rec2020, using [this framework](https://ccameron-chromium.github.io/webgl-examples/tonemap.html) to synthesize Rec2020 content (by tonemapping using YRGB). The differences here are at least large enough to be noticeable, but I still can't say that the results of preserving hue and luminance look necessarily better. We only get "bad results" from clamping (or any other scheme) when we're dealing with colors outside of Rec2020, which is outside of the capabilities of any existing display. So, if we ensure that authors stay reasonably close to the capabilities of their displays, then both problems go away. **Conclusion** This got long enough that it probably needs a TLDR. The position I have arrived at is as follows. * Using `oklab`,`oklch`,`lab`,`lch`, and relative-color syntax, it is easy for authors to specify colors that are way beyond their display's capabilities, and colors that don't physically exist. * The best solution for how to handle this problem is for authors to just not specify such colors. * We can solve this by either: * Providing color spaces that make it easy to avoid this (like `okhsl`) * Updating the existing spaces to prevent this (by baking in gamut mapping to something like Rec2020) * My preference is for the first solution. * Had I it to do over again, I might have restricted the more dangerous spaces to use only for interpolation **One more thing** As we get towards thinking about HDR content, we should probably consider allowing it only when a separate "SDR grading" is provided. This is the approach used by gainmaps (which are working really well across a wide ecosystem), in contrast with HDR video (which is a mess of incompatibility). -- GitHub Notification of comment by ccameron-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1980976323 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 March 2024 14:19:35 UTC