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.)
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.
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:
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:
“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
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.)
HWB makes a lot more sense to the average human beings than HSL/LAB. You pick a fully saturated color, and then you darken or lighten it to get the precise shade of that color that you want. It’s a huge win for UI over, say, RGB (100% red and 50% green makes no sense to anyone but designers and lighting technicians). Think of it as a magical shortcut for picking HSL, but instead of picking “orange, mostly saturated, then desaturated” you’re combining those last two into a single triangle picker whose three corners are the Hue, White, and Black.
Concepts of “whiteness” and “blackness” are fine, but this “HWB” is just a trivial rearrangement of RGB, and as such has very little to do with human perception, and much more to do with the specific implementation details of the output medium.
HWB (like RGB and HSL and HSV) does not make sense to “average human beings”. It only makes sense to people who have spent years training on the specifics of RGB displays (e.g. your proposed “lighting technicians”). For everyone else it is a confusing mess which produces bad results which differ significantly from their intentions.
This is neither magical nor a shortcut. It’s a superfluous hassle that anyone who wants to implement the spec needs to implement, debug, and maintain, and anyone reading the markup for arbitrary web pages needs to know about one more weird complication.
If individual web designers want to use this idiosyncratic tool, they are welcome to put it in their page’s javascript, or add it to their CSS pre-processor. But it should not be foisted on the rest of us.
The NCS image at the link you provide above literally shows the exact three-cornered orange-white-black triangle at position -Y10R that is shown in this image, which appears to use the exact hue sequence shown in your wiki link’s animation. I’m confused why you object to it being supported. Is your objection to their use of Hue spectrum positions 0,90,180,270 (R,G,C,M) - as already implemented in CSS today - as the four saturated qualia rather than NCS’s specified four qualia positions of 0,90,180,270 (R,Y,G,B)?
It is emphatically not “literally the exact [...] triangle”.
The NCS is a similar concept, but executed based on a plausible theoretical model and (more or less) sound empirical study of human perceptual response to visual stimuli.
“HWB”, like HSL, is just someone’s trivial half-assed transformation of the RGB cube, completely ignoring more than a century of color science research. It’s what you get when a person off the street were tasked with redefining the NCS, without understanding it. It reminds me of people’s bicycle sketches, http://www.gianlucagimini.it/prototypes/velocipedia.html
Personally I am not the biggest fan of the NCS system for designating colors; I find Munsell-like coordinate systems to work better for me, in practice. But at least it has some kind of theoretical and empirical basis.
CSS, having already standardized on Munsell hue circles (page 5) in the past, appears content to continue forward with them as the hue circle of choice for HWB. While I respect that you would prefer to see them use the NSL hue circle (pages 10-11), it appears that they are unlikely to do so at this time.
One bonus find here is the abstract for the cited Whitfield (1988) paper, where the paper's authors attempted to replicate the assertion that NSL is better than Munsell, and failed:
The study reported here is a replication of experiments cited as support for this claim. Subjects were trained in the NCS using NCS training material and carried out colour‐identification tasks. For comparison, a further subject group was trained in the Munsell system and carried out identical tasks. The results indicated (a) a lower level of accuracy than previously reported for those subjects trained in the NCS and (b) little difference in performance between the NCS‐ and Munsell‐trained groups.
CSS has nothing to do with Munsell hues or NCS hues. I have no idea what you mean by “NSL”.
The “HSL” / “HWB” hue circle is just a trivial transformation of the RGB cube (namely: zigzag along the 6 most colorful edges of the cube at constant speed), designed by non-color-expert computer programmers based on what was convenient to implement on workstation computers from the late 1970s (note: these considerations are not relevant 40 years later), and has almost nothing to do with human perception.
It is nowhere near perceptually uniform (unlike the goals of Munsell hues), and also does not have human-perception-meaningful landmarks like the NCS cardinal directions.
If you follow a circle of constant “W” and “B” in the “HWB” model, at constant speed in terms of “H”, then a typical human observer will see wildly varying “lightness”, “colorfulness”, “saturation”, “whiteness”, “blackness” with respect to their own perception, and will see perceived hue change at highly irregular and unsmooth speed.
And this (read the Appendix on the BACKLIGHT of the Sharp Quattron, and take a look at Figures 1.3, 3.5, 9.2, G.3!):
Note however, that all of this completely ignores the fact that humans seem capable of some form of HDR color fusion via binocular vision, as impressively demonstrated in this paper:
Given that many people seem to report slight differences in monochromatic color differentiating between eyes, we can speculate that binocular vision influences color perception in some way.
But frankly using CIECAM02 or CAM16 (or whatever) vs. CIELAB for doing gamut mapping is a relatively minor improvement in most cases. There can be serious issues when trying to convert RGB images to CMYK or similar for printing, especially hue shifts in the blue–purple region. But for converting colors from sRGB to a wider-gamut display there shouldn’t be any significant issue.
The big problem is that historically most browsers have done no color management of CSS colors. Looks like that is now changing, which is encouraging, whether or not the gamut mapping algorithm they use is state-of-the-art.
> ignores the fact that humans seem capable of some form of HDR color fusion
This seems largely irrelevant to the discussion in this thread.
Nice, thanks for sharing! You seem to work on a lot of stuff I find highly interesting! :) entirely off topic, but, you might find this of interest to your logarithmic spirals work:
>But for converting colors from sRGB to a wider-gamut display there shouldn’t be any significant issue.
I agree, but I'd prefer it if eventually, we treated sRGB colors the same way we treat CGA colors. Especially due to the issues outlined in the other paper I linked. (Namely, that our 'red' subpixels ain't red, they're more orange-red, and that the 'green' ones ain't green either, they're more yellow-green. Really a shame Sharp messed up their tech in that regard by just using a standard back-light, it put a huge blemish in the quite sane idea of having yellow subpixels.)
But, at the moment, we don't even have Chrome properly supporting ICCv4 profiles, so, those dreams of the far future will have to wait.
>This seems largely irrelevant to the discussion in this thread.
>largely
Yes, I agree, I placed it there as a note of caution about:
1. Limitations in the works linked to;
2. The fact that color science doesn't seem to account for stereoblindness and monocular vs. binocular stimulii more often than not;
that's all.
That's also why I linked that PhD dissertation, which also goes beyond CAM16. I in fact neglected to mention some other limitations, namely, that it also doesn't fully factor in:
1. The works on color perception by Brian P. Schmidt¹ et al.: https://bps10.github.io/ (Note: It does factor it in /in part/)
¹ NOT the Brian P. Schmidt who won part of the 2011 Physics Nobel price
Edit: Almost entirely off-topic, but, I try to keep my thematically related Hacker News comments at least indirectly hyperlinked to each other, so, here, another color related comment:
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.)