3 ms·

So when are web browsers going to start doing proper color management on CSS colors and untagged images? I gave up on pestering them about it 10 years ago afte

So when are web browsers going to start doing proper color management on CSS colors and untagged images? I gave up on pestering them about it 10 years ago after they were largely unreceptive about the topic for several years, but it seems like it’s still a complete shitshow. 10–14 years ago I was grumpy because my laptop display had a smaller gamut than sRGB and everything looked bad (undersaturated). Then there were a few years in between where most of the displays I used were close enough to sRGB that missing color management more-or-less worked out. Now many devices have wide-gamut displays which basically make everything on the web look like oversaturated garbage. Apple had color management more or less figured out on the Mac in the mid 1990s. It is absurd that it is still so hard for software made by gajillion-dollar companies to get the bare basics right >20 years later, especially now that we have superfast GPUs to do compositing in linear space and arbitrarily fancy gamut mapping using floating point arithmetic, brighter and wider-gamut displays, better cameras, ... To the browser vendors: all untagged content must be assumed to be sRGB. If viewers have wider-gamut displays this content must go through a CMS. If viewers want to view wider-gamut images or other content, this must be opt-in. The current behavior breaks color on the web. (Buy a new phone or computer and suddenly nearly every color relationship you see on the web will be different than the designer’s intention.)

floatingatoll 7y ago
1) Let X = The color profile assigned to CSS #rrggbb color codes. What is X? 2) Let Y = The color profile assigned to your display. When X does not equal Y, which option should the browser choose for converting colorspace X to colorspace Y for display purposes? a) Relative colormetric b) Absolute colormetric c) Untranslated integers d) Other Then, 3) Let Z = The color profile assigned to CSS HSV/LAB color codes. What is Z? Is it the same as X? I don't envy browser developers any aspect of this problem. If they do it right, no one will notice care. If they do it wrong, the Internet will burn them alive. I can't blame them all for being scared, but I hope that now that we've finally exited the "wild west" of "My display could have any ICC profile under the sun" and are instead approaching "My display is either sRGB or Display P3" that they will, at the very least, decide what to do and then do it and make us all adapt. ps. If you answer question 1 with "X has no assigned color profile", then here's two extra credit questions for you: 4) Should a CSS box with "no colorspace" #ff0000, when displayed on two calibrated displays of equal luminosity but differing (sRGB, P3) color profiles, appear visually identical to the human eye (Safari) or should it be more saturated on P3 (Firefox)? 5) What is the correct CSS declaration to specify P3(r=1.0,g=0.0,b=0.0)? pps. It looks like the CSS working groups are being pushed by both Microsoft and Apple to solve this problem, so eventually they will clearly all standardize on some way to specify colors in non-sRGB, and likely default unspecified colors to sRGB. To which I have to say, "Finally", because maybe then the one outlier will finally align with what I think is right. This is a hard problem, don't get me wrong, it's just frustrating having waited a decade for them to solve this and it's still not solved. ppps. The answer to all of the above questions can likely be found here, once they exit the draft stage someday. The above is all designed to convey the problem in a nutshell to people who aren't familiar with the core problem. If you truly understand and care about this stuff, here you go: CSS Color Module Level 4, W3C Working Draft, 5 March 2019: https://www.w3.org/TR/css-color-4/#predefined https://www.w3.org/TR/css-color-4/#predefined 11.2. Predefined colorspaces: srgb, image-p3, a98rgb, prophotorgb and rec2020.
- jacobolus 7y ago
  “Absolute colorimetric” makes no sense in this context. So the answer is always “perceptual” or “relative colorimetric”. But that alone doesn’t really tell you what to do. A rendering intent is not a gamut mapping algorithm, and there are many possible gamut mapping algorithms. Here’s a 300 page monograph discussing more or less the state of the art 10 years ago, https://amzn.co/0470030321 https://amzn.co/0470030321 But here’s the thing... it doesn’t really matter. Their current choice is to just treat everything untagged as being in the display’s profile and do no color management. This is pretty much the worst possible choice. The specification is very clear. Untagged colors in CSS/HTML are sRGB. Period. Doesn’t matter if they are specified as RGB or HSL coordinates (P.S. it was a huge mistake to add the latter to the web; HSL/HSV should never be used for any purpose). Currently most of the browsers flagrantly violate the specification. The browsers have been doing things wrong since forever. People who know anything about it have been annoyed since forever, but their feedback seems to have very little influence. Everyone else is blissfully ignorant, except for often encountering weird color bugs that they don’t understand the cause of. > Should a CSS box with "no colorspace" #ff0000, when displayed on two calibrated displays of equal luminosity but differing (sRGB, P3) color profiles, appear visually identical to the human eye (Safari) or should it be more saturated on P3 (Firefox)? It should appear more or less the same on both. The spec explicitly specifies that it is sRGB. Under no circustances should it be naively treated as P3. However some gamut mapping algorithms might make it slightly more colorful when going from sRGB -> P3 (without significantly altering lightness/hue relationships between colors). > What is the correct CSS declaration to specify P3 This is something to take up with the CSS spec authors. They can add some ability to opt-in to tagging non-sRGB colors. If the spec doesn’t support it, then there is no way. * * * Edit: Your linked draft spec clarifies that something like relative colorimetric intent must be used. “Implementations may choose to implement these steps in some other way (for example, using an ICC profile with relative colorimetric rendering intent) provided the results are the same for colors inside the source and destination gamuts.” So your answer about the untagged #ff0000 is that it should look pretty well identical on both displays. Glad they are adding some facility for non-sRGB colors to CSS. Of course it wouldn’t be the W3C if they didn’t also add some useless clutter in every new spec. The “HWB” color space? Who comes up with such nonsense? (Compare to SVG trying to add turtle graphics and Catmull–Rom splines to their path specification mini-format, for basically no reason, in the latest draft spec.)
vanderZwan 7y ago
You can enable it in Firefox, but it's not on by default IIRC. https://cameratico.com/guides/firefox-color-management/ https://cameratico.com/guides/firefox-color-management/ EDIT: That's the desktop - can't speak for the mobile version. I really hope they turn it on by default in the new mobile browser they're building. Also, thanks, I had enabled the color management a long time ago but it apparently was disabled again in a recent upgrade or something.
- no_identd 7y ago
  That only takes us so far. First of all: Chrome still has broken color management. DisplayCAL has a way to generate profiles that look like garbage in applications which process color profiles incorrectly, and this happens with Chrome (but not Firefox.). Besides that, even if it had feature parity with Firefox, we'd still remain stuck in the land of ICC color profiles, and those have a few issues. I'd love to see web browsers support this modified version of this: https://arxiv.org/abs/1802.06067 https://arxiv.org/abs/1802.06067 For which an implementation exists, here: https://github.com/nschloe/colorio https://github.com/nschloe/colorio …but no operating systems and hence no browsers support it. Edit: See also my comment here: https://news.ycombinator.com/item?id=19983604 https://news.ycombinator.com/item?id=19983604
  - vanderZwan 7y ago
    > I'd love to see web browsers support this modified version of this I hear you, but at the same time this relevant xkcd comes to mind: https://xkcd.com/927/ https://xkcd.com/927/ Colorio looks great, thanks for the link! Also has Jzazbz support I see, neat!

floatingatoll 7y ago

1) Let X = The color profile assigned to CSS #rrggbb color codes. What is X? 2) Let Y = The color profile assigned to your display. When X does not equal Y, which option should the browser choose for converting colorspace X to colorspace Y for display purposes? a) Relative colormetric b) Absolute colormetric c) Untranslated integers d) Other Then, 3) Let Z = The color profile assigned to CSS HSV/LAB color codes. What is Z? Is it the same as X? I don't envy browser developers any aspect of this problem. If they do it right, no one will notice care. If they do it wrong, the Internet will burn them alive. I can't blame them all for being scared, but I hope that now that we've finally exited the "wild west" of "My display could have any ICC profile under the sun" and are instead approaching "My display is either sRGB or Display P3" that they will, at the very least, decide what to do and then do it and make us all adapt. ps. If you answer question 1 with "X has no assigned color profile", then here's two extra credit questions for you: 4) Should a CSS box with "no colorspace" #ff0000, when displayed on two calibrated displays of equal luminosity but differing (sRGB, P3) color profiles, appear visually identical to the human eye (Safari) or should it be more saturated on P3 (Firefox)? 5) What is the correct CSS declaration to specify P3(r=1.0,g=0.0,b=0.0)? pps. It looks like the CSS working groups are being pushed by both Microsoft and Apple to solve this problem, so eventually they will clearly all standardize on some way to specify colors in non-sRGB, and likely default unspecified colors to sRGB. To which I have to say, "Finally", because maybe then the one outlier will finally align with what I think is right. This is a hard problem, don't get me wrong, it's just frustrating having waited a decade for them to solve this and it's still not solved. ppps. The answer to all of the above questions can likely be found here, once they exit the draft stage someday. The above is all designed to convey the problem in a nutshell to people who aren't familiar with the core problem. If you truly understand and care about this stuff, here you go: CSS Color Module Level 4, W3C Working Draft, 5 March 2019: https://www.w3.org/TR/css-color-4/#predefined https://www.w3.org/TR/css-color-4/#predefined 11.2. Predefined colorspaces: srgb, image-p3, a98rgb, prophotorgb and rec2020.

jacobolus 7y ago
“Absolute colorimetric” makes no sense in this context. So the answer is always “perceptual” or “relative colorimetric”. But that alone doesn’t really tell you what to do. A rendering intent is not a gamut mapping algorithm, and there are many possible gamut mapping algorithms. Here’s a 300 page monograph discussing more or less the state of the art 10 years ago, https://amzn.co/0470030321 https://amzn.co/0470030321 But here’s the thing... it doesn’t really matter. Their current choice is to just treat everything untagged as being in the display’s profile and do no color management. This is pretty much the worst possible choice. The specification is very clear. Untagged colors in CSS/HTML are sRGB. Period. Doesn’t matter if they are specified as RGB or HSL coordinates (P.S. it was a huge mistake to add the latter to the web; HSL/HSV should never be used for any purpose). Currently most of the browsers flagrantly violate the specification. The browsers have been doing things wrong since forever. People who know anything about it have been annoyed since forever, but their feedback seems to have very little influence. Everyone else is blissfully ignorant, except for often encountering weird color bugs that they don’t understand the cause of. > Should a CSS box with "no colorspace" #ff0000, when displayed on two calibrated displays of equal luminosity but differing (sRGB, P3) color profiles, appear visually identical to the human eye (Safari) or should it be more saturated on P3 (Firefox)? It should appear more or less the same on both. The spec explicitly specifies that it is sRGB. Under no circustances should it be naively treated as P3. However some gamut mapping algorithms might make it slightly more colorful when going from sRGB -> P3 (without significantly altering lightness/hue relationships between colors). > What is the correct CSS declaration to specify P3 This is something to take up with the CSS spec authors. They can add some ability to opt-in to tagging non-sRGB colors. If the spec doesn’t support it, then there is no way. * * * Edit: Your linked draft spec clarifies that something like relative colorimetric intent must be used. “Implementations may choose to implement these steps in some other way (for example, using an ICC profile with relative colorimetric rendering intent) provided the results are the same for colors inside the source and destination gamuts.” So your answer about the untagged #ff0000 is that it should look pretty well identical on both displays. Glad they are adding some facility for non-sRGB colors to CSS. Of course it wouldn’t be the W3C if they didn’t also add some useless clutter in every new spec. The “HWB” color space? Who comes up with such nonsense? (Compare to SVG trying to add turtle graphics and Catmull–Rom splines to their path specification mini-format, for basically no reason, in the latest draft spec.)

vanderZwan 7y ago

You can enable it in Firefox, but it's not on by default IIRC. https://cameratico.com/guides/firefox-color-management/ https://cameratico.com/guides/firefox-color-management/ EDIT: That's the desktop - can't speak for the mobile version. I really hope they turn it on by default in the new mobile browser they're building. Also, thanks, I had enabled the color management a long time ago but it apparently was disabled again in a recent upgrade or something.

no_identd 7y ago
That only takes us so far. First of all: Chrome still has broken color management. DisplayCAL has a way to generate profiles that look like garbage in applications which process color profiles incorrectly, and this happens with Chrome (but not Firefox.). Besides that, even if it had feature parity with Firefox, we'd still remain stuck in the land of ICC color profiles, and those have a few issues. I'd love to see web browsers support this modified version of this: https://arxiv.org/abs/1802.06067 https://arxiv.org/abs/1802.06067 For which an implementation exists, here: https://github.com/nschloe/colorio https://github.com/nschloe/colorio …but no operating systems and hence no browsers support it. Edit: See also my comment here: https://news.ycombinator.com/item?id=19983604 https://news.ycombinator.com/item?id=19983604
- vanderZwan 7y ago
  > I'd love to see web browsers support this modified version of this I hear you, but at the same time this relevant xkcd comes to mind: https://xkcd.com/927/ https://xkcd.com/927/ Colorio looks great, thanks for the link! Also has Jzazbz support I see, neat!