- From: Isaac Muse via GitHub <sysbot+gh@w3.org>
- Date: Fri, 22 Mar 2024 14:03:34 +0000
- To: public-css-archive@w3.org
> What the CSS syntax `oklab(1 0.25 0)` should do is the very question of this issue, I'm referring to what those coordinates mean in Oklab as defined in https://bottosson.github.io/posts/oklab/. It is both a very colorful color, but also a very bright color, neither of which can be represented in the SDR gamuts we are talking about. In the SDR gamuts, it is an impossible color. Whatever it means, we can never capture it, we can only capture parts of it. You can extend the coordinates of the SDR gamut to allow round-trip calculations, but you will never be able to display it in that gamut. > The main question remains of what behavior is desirable at or close to 100%. Well, what are you doing? No matter what you do in terms of gamut mapping, you are wrong. All you can do is find the "best" possible color based on how you are working and what attributes you deem most important because you can't represent all the attributes of that color. You can accurately represent the lightness in this case and preserve the integrity of the hue, sacrificing its chroma, which is what CSS currently recommends, and it gives you white, but yes, it is still wrong. This doesn't make white a special case, the SDR gamut cannot represent any colors with that lightness level except white. It's a shortcut that skips reducing the chroma, which will give you white anyway. Now, clamping it at parse time may be a special case. You can try and show a darker color that will sacrifice hue and/or lightness to find the closest color that retains as much chroma as possible, it will also be wrong. The point is, whatever you choose, you can never capture that color, only specific attributes of that color. Depending on how you are working with the color, some attributes of that color are more important to you. For contrast with text (a big CSS use case) or trying to create tones, the lightness attribute, preserving the true hue may be the most important. In pictures, the closest color that has chroma close to the original (sacrificing both lightness and hue) may be more important as the colors need to maintain chroma relative to their neighbor pixels to be less jarring. These are two different use cases, and neither solution is always better. Consider Google's HCT color space in their Material Color Utilities. They've developed a color system to create palettes for apps and sites. For this to work, they wanted to have to have relatively predictable contrast and have decent hue preservation. They mashed together CIELab (D65) lightness, which provides good contrast between lightness levels, and used CAM16 chroma and hue, which while not the best at preserving hue, it does ok. When it is creating its tonal palettes, it is absolutely reducing chroma to gamut map those colors when you specify lightness levels for a color. That is how it builds its tonal palettes. I know this because I've been able to replicate HCT outside of their Material Color Utilities that expands its functionality to wide gamuts, while replicating its ability to return equivalent tonal palettes: https://facelessuser.github.io/coloraide/colors/hct/#tonal-palettes. It's the only way to give consistent hues and control lightness from destroying contrast. Neither approach in terms of gamut mapping is wrong, but they provide different utility. Neither will capture the "true definition" of the color. As far as an SDR spec that wants to focus on text on background colors, reducing chroma makes the most sense (at least to me). Now, how do you represent HDR colors? I feel this is getting into topics that should be in the HDR color spec. Not everyone will always want to represent HDR colors at all times. -- GitHub Notification of comment by facelessuser Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10109#issuecomment-2015177785 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 22 March 2024 14:03:35 UTC