- From: Christopher Cameron via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2024 12:00:33 +0000
- To: public-css-archive@w3.org
> I opened this issue to try and step away from the specific numerical mechanics of an algorithm > Without that, the mathematical discussions just seem to go in circles – solving different problems. Agree. > While color-matching across images and canvas elements is a real use-case that we should consider and provide tools far, it is _extremely less common_ than day-to-day backgrounds and foregrounds. Color matching has worked for sRGB content, in all browsers, effectively forever. For images with non-sRGB color profiles, I think it's several years for all browsers (and >10 for at least one). So this is a long established capability, and I would not want to be cavalier about regressing it. The breaking of color matching is also a warning sign that we're probably doing things wrong. _Recent anecdote_: Color matching for HLG/PQ HDR images is impossible, and that was always a wrinkle in the discussion. Over the last two years we've found that HLG/PQ images are "the Wrong Way To Do It", and no* phones shoot HLG/PQ HDR images. Instead, all* phones that shoot HDR shoot [gainmap images](https://helpx.adobe.com/si/camera-raw/using/gain-map.html), which are capable of color matching. Color matching isn't the only reason why gainmap images are "The Right Way To Do It", but it is an indicative one. (In my opinion, the way to enable things like HDR for CSS is a dual-grading approach similar to gainmaps). (*) I'm hesitant to say that indeed there are exactly zero phones that shoot HLG/PQ still images -- my certainty is high, but not 100%. > So when discussing the default behavior for out-of-gamut colors, I think it would be a mistake to leave out the central question: > * When the viewer is not able to see the exact foreground/background colors requested, what aspects of those colors should ideally be preserved? I'm going to go around in circles a bit here (sorry!), but I think that whether or not we need to answer that question depends on the answer to the question of "should content authors be specifying CSS colors that they themselves cannot produce the monitor they are using to author the content, or that colors that physically don't exist?" Content authors are effectively limited to seeing P3 today (for widely available hardware), and so the only problem we are then solving is the problem of "map P3 to sRGB". In terms of "what aspects of those colors should be preserved", when limited to "map P3 to sRGB", and with a focus on accessibility and legibility, the answer I've come to is "it really doesn't matter". I've been unable to create a page that is legible in P3 but is not legible in sRGB, irrespective of what gamut mapping is done. Please let me know if you're able to do so. I've really tried! I've only run that experiment with P3 displays, because I only have an Apple XDR display (ahem). I haven't seen if this generalizes to the "map Rec2020 to sRGB" problem because I've never seen Rec2020. My guess that legibility would not be affected (and if a page's accessibility is affected by sRGB-versus-Rec2020 gamut, then the page must be atrociously inaccessible for the large fraction of the population perceives a [2D or 1D gamut](https://en.wikipedia.org/wiki/Color_blindness)). With that in mind, I see CSS gamut mapping as solving the problem of: "we want to enable content authors to specify colors that no commercially available display can produce, and colors that are physically impossible". In my opinion we should instead solve the problem of "enable content authors to use perceptually uniform color schemes that stay within commonly available screen gamuts" directly, rather than introducing a harder problem in the middle. -- GitHub Notification of comment by ccameron-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1938544704 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 February 2024 12:00:35 UTC