5 ms·

But the image was presumably shot and colour corrected in P3, which means to squash it down to sRGB will by necessity change the imperceptible colour difference

But the image was presumably shot and colour corrected in P3, which means to squash it down to sRGB will by necessity change the imperceptible colour differences into something perceptible -- and therefore change the image into a new image, one slightly off -- very slightly in some cases. Consider retina displays-- do you prefer the browser messing with your image to produce a 1x image from a 2x? Nope. Do you prefer not having 2x? Nope. Yes a browser can scale it and it will function, but is it as intended? Especially if the browser changes it to be less noticeable or have similar contrast--that would be like a 1x image getting blurred to 2x or shrunk with an algorithm from 2x to 1x. Media queries and other syntax exist so we as creators can decide how we want things to look, down to the Last pixel. You as the content author can export two versions of the image, one colour corrected or edited on a P3 monitor and one corrected/edited on an sRGB and stand a chance that while sRGB will remain the default for now, P3 and beyond should gain as much market share as 2x, "Retina" or 4K displays, in part thanks to UHD Premium displays and content.

JoshTriplett 10y ago
> But the image was presumably shot and colour corrected in P3 That's not a reasonable assumption to make about an arbitrary image that doesn't contain a color profile. For instance, consider a pixel-art image drawn entirely on a computer and saved as a PNG with no color profile. If an image contains a color profile, it's somewhat more reasonable to attempt to interpret that color profile (though it's still odd to not at least attempt to take advantage of higher-gamut-but-not-identified-as-such displays by using the full 8-bit RGB range, on the assumption that the display may or may not render ). And it seems reasonable to support media queries for image color profiles as well. But to quote the article: > If an image doesn’t have a tagged profile, WebKit assumes that it is sRGB. That's the behavior I'm arguing is completely wrong: if an image with no color profile contains the colors rgb(241, 0, 0) and rgb(255, 0, 0), the browser should render those as distinct colors, not squash them together.
- comex 10y ago
  The image in question: https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png does have a color profile. By the way, it also uses 15-bit color channels. Here is the same image after pngcrush removed the color profile PNG chunks: http://dl.dropbox.com/u/1237941/Webkit-logo-profile-removed.png http://dl.dropbox.com/u/1237941/Webkit-logo-profile-removed.... In Safari on my non-high-gamut Mac, the logo is clearly visible. (Edit: To be specific, on the default "Color LCD" profile I get 252,13,27 and 238,12,25 as native equivalents of the sRGB 255,0,0 and 241,0,0. Presumably there is some slight clamping around the edges of the profile, as well as some inherent precision loss if WebKit is performing the conversion on 24-bit colors, but it's not anywhere near as crazy as making 241,0,0 and 255,0,0 look the same.)
  - JoshTriplett 10y ago
    > The image in question: > https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png > does have a color profile. I didn't comment on the handling of that image. My comment related to the bit of the article I quoted, which states that WebKit treats images without a color profile as sRGB.
    - comex 10y ago
      Then you're conflating two different transformations. Squashing 241,0,0 and 255,0,0 is the transformation from P3, as performed on that image. As I stated in the last bit of my comment, the transformation from sRGB to the display's native color space, as performed on images without a color profile, CSS colors, etc. [edit: and of course images tagged as sRGB!] is far more subtle.
- jacobolus 10y ago
  No offense, but you’re wrong. Full stop. (It’s okay though. This is something which developers without training in human color perception / color reproduction are commonly wrong about. It comes from lack of training and lack of experience. The proper thing to do is not a priori intuitively obvious to the layman, in the same way optimizing algorithms for CPU cache locality might not be obvious to a color scientist.) If you take an image which was authored to be sRGB, and show it on a wide-gamut display, stretching all the colors out to fill the gamut, you will supersaturate all the colors and totally distort all of the lightness, hue, and chroma relationships in the image, and it will look terrible. Likewise, if you take an image which was authored for P3 (or whatever), and squish it down to fit on an sRGB gamut, everything will end up undersaturated, again distorting all the lightness, hue, and chroma relationships. Again, it will look terrible. There are fancier ways to do gamut mapping than pure clipping, but there is a lot of subtlety involved (Ján Morovič wrote a several-hundred-page monograph about this, if you want more details, https://amzn.com/0470030321 https://amzn.com/0470030321), the best one to use varies from image to image, depends a bit on viewing conditions and other context, and the nicer methods are quite computationally expensive. The HTML/CSS/etc. specs declare that untagged images and other untagged colors are to be treated as sRGB. This is the only reasonable assumption in a world where sRGB has been the primary standard for 20 years. Any 2016 browser / operating system / image viewer which treats an untagged image as anything other than sRGB is spec-non-compliant and functionally broken. (Sadly, this includes most browsers on most platforms.)
  - userbinator 10y ago
    First of all, "terrible" and "amazing" are subjective. Any 2016 browser / operating system / image viewer which treats an untagged image as anything other than sRGB is spec-non-compliant and functionally broken. (Sadly, this includes most browsers on most platforms.) Given the blatant loss of information that occurs if you do that, as evidenced by the WebKit logo example, I'd argue the spec is broken. Pixels of different values should be different when displayed, because that's what matters to the majority of users.
    - jacobolus 10y ago
userbinator 10y ago
After reading a bit more about this here (thanks for all the informative replies) and on colour management in general, I'm pretty sure I prefer my monitor being able to display all 256 different intensities of one colour even if they're not exactly the same as some standard colour, than a scaled and truncated fraction of those (which seems like it'd just cause more visible banding.) The example image shows that clearly. I adjust my monitor's contrast and brightness to my preference, and colour perception is quite subjective anyway (not to mention affected by viewing conditions, hence those hooded monitors and controlled lighting when it is important) so I think colour management is not for me. In fact, I'd say that if you displayed that example image simultaneously on a non-colour-managed sRGB monitor (logo visible), colour-managed sRGB monitor (logo invisible), and (colour-managed?) P3 monitor (logo visible), no average user is going to want the middle option.
- givinguflac 10y ago
  If you ever have a chance to actually calibrate your display with a real hardware calibration tool, I think you'd quickly decide that color management was for you.
  - rasz_pl 10y ago
    And if you ever spend $400 on a wooden volume knob you will quickly decide $1000 power cables are also for you.

JoshTriplett 10y ago

> But the image was presumably shot and colour corrected in P3 That's not a reasonable assumption to make about an arbitrary image that doesn't contain a color profile. For instance, consider a pixel-art image drawn entirely on a computer and saved as a PNG with no color profile. If an image contains a color profile, it's somewhat more reasonable to attempt to interpret that color profile (though it's still odd to not at least attempt to take advantage of higher-gamut-but-not-identified-as-such displays by using the full 8-bit RGB range, on the assumption that the display may or may not render ). And it seems reasonable to support media queries for image color profiles as well. But to quote the article: > If an image doesn’t have a tagged profile, WebKit assumes that it is sRGB. That's the behavior I'm arguing is completely wrong: if an image with no color profile contains the colors rgb(241, 0, 0) and rgb(255, 0, 0), the browser should render those as distinct colors, not squash them together.

comex 10y ago
The image in question: https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png does have a color profile. By the way, it also uses 15-bit color channels. Here is the same image after pngcrush removed the color profile PNG chunks: http://dl.dropbox.com/u/1237941/Webkit-logo-profile-removed.png http://dl.dropbox.com/u/1237941/Webkit-logo-profile-removed.... In Safari on my non-high-gamut Mac, the logo is clearly visible. (Edit: To be specific, on the default "Color LCD" profile I get 252,13,27 and 238,12,25 as native equivalents of the sRGB 255,0,0 and 241,0,0. Presumably there is some slight clamping around the edges of the profile, as well as some inherent precision loss if WebKit is performing the conversion on 24-bit colors, but it's not anywhere near as crazy as making 241,0,0 and 255,0,0 look the same.)
- JoshTriplett 10y ago
  > The image in question: > https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png > does have a color profile. I didn't comment on the handling of that image. My comment related to the bit of the article I quoted, which states that WebKit treats images without a color profile as sRGB.
  - comex 10y ago
    Then you're conflating two different transformations. Squashing 241,0,0 and 255,0,0 is the transformation from P3, as performed on that image. As I stated in the last bit of my comment, the transformation from sRGB to the display's native color space, as performed on images without a color profile, CSS colors, etc. [edit: and of course images tagged as sRGB!] is far more subtle.
jacobolus 10y ago
No offense, but you’re wrong. Full stop. (It’s okay though. This is something which developers without training in human color perception / color reproduction are commonly wrong about. It comes from lack of training and lack of experience. The proper thing to do is not a priori intuitively obvious to the layman, in the same way optimizing algorithms for CPU cache locality might not be obvious to a color scientist.) If you take an image which was authored to be sRGB, and show it on a wide-gamut display, stretching all the colors out to fill the gamut, you will supersaturate all the colors and totally distort all of the lightness, hue, and chroma relationships in the image, and it will look terrible. Likewise, if you take an image which was authored for P3 (or whatever), and squish it down to fit on an sRGB gamut, everything will end up undersaturated, again distorting all the lightness, hue, and chroma relationships. Again, it will look terrible. There are fancier ways to do gamut mapping than pure clipping, but there is a lot of subtlety involved (Ján Morovič wrote a several-hundred-page monograph about this, if you want more details, https://amzn.com/0470030321 https://amzn.com/0470030321), the best one to use varies from image to image, depends a bit on viewing conditions and other context, and the nicer methods are quite computationally expensive. The HTML/CSS/etc. specs declare that untagged images and other untagged colors are to be treated as sRGB. This is the only reasonable assumption in a world where sRGB has been the primary standard for 20 years. Any 2016 browser / operating system / image viewer which treats an untagged image as anything other than sRGB is spec-non-compliant and functionally broken. (Sadly, this includes most browsers on most platforms.)
- userbinator 10y ago
  First of all, "terrible" and "amazing" are subjective. Any 2016 browser / operating system / image viewer which treats an untagged image as anything other than sRGB is spec-non-compliant and functionally broken. (Sadly, this includes most browsers on most platforms.) Given the blatant loss of information that occurs if you do that, as evidenced by the WebKit logo example, I'd argue the spec is broken. Pixels of different values should be different when displayed, because that's what matters to the majority of users.
  - jacobolus 10y ago

userbinator 10y ago

After reading a bit more about this here (thanks for all the informative replies) and on colour management in general, I'm pretty sure I prefer my monitor being able to display all 256 different intensities of one colour even if they're not exactly the same as some standard colour, than a scaled and truncated fraction of those (which seems like it'd just cause more visible banding.) The example image shows that clearly. I adjust my monitor's contrast and brightness to my preference, and colour perception is quite subjective anyway (not to mention affected by viewing conditions, hence those hooded monitors and controlled lighting when it is important) so I think colour management is not for me. In fact, I'd say that if you displayed that example image simultaneously on a non-colour-managed sRGB monitor (logo visible), colour-managed sRGB monitor (logo invisible), and (colour-managed?) P3 monitor (logo visible), no average user is going to want the middle option.

givinguflac 10y ago
If you ever have a chance to actually calibrate your display with a real hardware calibration tool, I think you'd quickly decide that color management was for you.
- rasz_pl 10y ago
  And if you ever spend $400 on a wooden volume knob you will quickly decide $1000 power cables are also for you.