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

> Can we bring examples to a telecon

I would love to discuss this in a more interactive format!

> authors are encouraged to use the fully interop/supported wide gamut formats, and there's absolutely no safety net in place to ensure those formats work for people on the other end.

Yes, I agree that we made mistakes in the specification here, sorry. I'm trying to straighten things out to provide a user-friendly perceptually-uniform color space. I was hoping to have a fix to test in Canary ready by now, but holidays and things have slowed things down.

> > > We can't put this on authors, and expect them to just keep all their colors in the gamut.

> > I agree with this statement. It shouldn't be expected that an author ensure that all colors be in the gamut of the target device.

> In that case, a solution that is specific to (ok)l** formats is not a solution to this issue. We can't 'bake gamut mapping' into a few wide-gamut formats and be done with it.

I'll try rephrasing what I meant by this part:

> > What concerns me is something slightly different: Should an author specify a color when they do not (or physically cannot) know what that color actually looks like?

I think we need to separate two problems here that both fall under the wider umbrella of "stuff is out of gamut".

* **Problem 1**: Author specifies colors that the author intends (that is, they have observed the color they are specifying on some existing screen), but those colors are outside of the gamut of the target device.
  * There exists a whole ecosystem of solutions to this. The oldest and best known would for the screen to use an ICC profile with a perceptual rendering intent, the more modern methods would be to specify metadata such as Mastering Display Color Volume (aka MDCV [SMPTE ST 2086](https://ieeexplore.ieee.org/document/8353899)) or Content Color Volume (aka CCV [ISO/IEC 23008-2](https://www.iso.org/standard/85457.html)).
  * The user agent should act in concert with the underlying operating system and display hardware to do the best thing here. I don't think we should be prescribing behavior at level of the browser apart from the guidance to "please do a good job" -- different browsers in different circumstances on different displays in different monitors may take different approaches to solving this problem.

* **Problem 2**: Author specifies colors that do not physically exist or that they have never seen because no display hardware can produce them.
  * This is a "garbage in, garbage out" situation, and I think it's really dangerous to get into the business of trying to assign meaning to physically non-existent colors.
  * BTW, The color `oklch(90% 90% 0deg)` is a physically impossible color (I may have incorrectly stated earlier that it was physically possible -- I plugged it in to [this app](https://ccameron-chromium.github.io/webgl-examples/gamut.html) and found that it isn't within the convex hull of the spectral colors, see the attached screenshot).

<img width="1204" alt="point-not-real" src="https://github.com/w3c/csswg-drafts/assets/32557109/ae0ebf16-6284-4521-9cbe-aec5f4833b57">

> Can we narrow in on a path forward?

I think we need to separate two core features that are being discussed.

* **Feature A (the one from this issue)**: The web should have a user-friendly perceptually uniform color space
  * I want for us to find a solution to this problem.
  * `oklab` and `oklch` turned out not to be good solutions to the problem of "user-friendly space to specify color in", because it's too easy to specify nonsense colors.
      * That creates the new problem of "assign meaning to nonsense colors".
      * The spec fixed that problem by imposing a very specific gamut mapping algorithm on *all* colors.
        * This algorithm is good at solving the "assign meaning to nonsense colors in a way that comports well with `oklab` and `oklch`" problem.
        * Other gamut mapping algorithms would break the desirable properties of the `oklab` and `oklch` spaces.
      * A different fix might be to bake a specific gamut mapping into only `oklab` and `oklch`.
  * A space like `okhsv` and `okhsl` would be a better match for this problem.

* **Feature B**: The web should impose standard gamut mapping on content (solving Problem 2)
 * This problem has many existing solutions at the OS, GPU, display controller, and display hardware level. The web feels like the wrong level to impose a solution.
 * We are only trying to solve this problem because we see it as a solution to the problem of "impose meaning on physically meaningless colors values", and we're only encountering physically meaningless color values because `oklab` and `oklch` make them easy to create.

I think that we should narrow our focus to Feature A: Provide a user-friendly percetually-uniform color space. Maybe we can patch up `oklab` and `oklch` to do this, or maybe we should introduce something else that avoids producing meaningless values.

I don't think we should try to solve Feature B (general gamut mapping) as a way to fix problems in a particular solution for Feature A. I also think that Feature B should not be solved at this level of the stack.

To respond to the specific points you brought up:

* > the current spec does that decently well using oklch and ΔEOK.
  * Yes, this approach does indeed do a good job of imposing meaning on the `oklab` and `oklch` colors (with some quibbles about some of the numerical specifics, and firming up what exactly we are mapping to in all circumstances).
* > is there a solid counter-proposal for a multi-channel mapping algorithm?
  * I don't want to be in the prescribed gamut mapping business, so I haven't set out any alternatives.
* > different formats represent different authors intents in some heuristic way?
  * Yeah, that's kinda where I'm going ... "if the author is using `srgb` or `display-p3`, they probably are going to give meaningful color values, but if the author is using `oklch` or `oklab`, then they are likely to hand me something physically impossible".


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


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

Received on Thursday, 25 January 2024 11:51:08 UTC