6 ms·

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,

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.)
- floatingatoll 7y ago
  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.
  - jacobolus 7y ago
    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. If you want a color model related to NCS, specify something which properly follows its principles. https://en.wikipedia.org/wiki/Natural_Color_System https://en.wikipedia.org/wiki/Natural_Color_System > magical shortcut 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.
    - floatingatoll 7y ago
      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)? HWB: https://commons.wikimedia.org/wiki/File:GTK_color_chooser.png https://commons.wikimedia.org/wiki/File:GTK_color_chooser.pn... NCS: https://commons.wikimedia.org/wiki/File:Animation_of_the_NCS_Colour_System.gif https://commons.wikimedia.org/wiki/File:Animation_of_the_NCS...

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.)

floatingatoll 7y ago
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.
- jacobolus 7y ago
  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. If you want a color model related to NCS, specify something which properly follows its principles. https://en.wikipedia.org/wiki/Natural_Color_System https://en.wikipedia.org/wiki/Natural_Color_System > magical shortcut 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.
  - floatingatoll 7y ago
    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)? HWB: https://commons.wikimedia.org/wiki/File:GTK_color_chooser.png https://commons.wikimedia.org/wiki/File:GTK_color_chooser.pn... NCS: https://commons.wikimedia.org/wiki/File:Animation_of_the_NCS_Colour_System.gif https://commons.wikimedia.org/wiki/File:Animation_of_the_NCS...