5 ms·

Most likely that's because the application you are using (or the graphics stack it's running on) is not respecting the ICC color profile embedded in the image,

by mwfunk 10y ago

Most likely that's because the application you are using (or the graphics stack it's running on) is not respecting the ICC color profile embedded in the image, and is instead interpreting the pixel values as being in the sRGB color space. What they are trying to demonstrate only works if the app is interpreting the pixel values in P3 and then converting them to sRGB. A graphics stack that includes a CMS (color management system) will always do this in preparation for display on an sRGB device, which is probably very close to your display's gamut. The macOS graphics stack incorporates a CMS (ColorSync) that is turned on by default. Windows and Linux have great CMS support as well, but depending on the OS it may require installing an extra package, or enabling a CMS in the display properties.

JoshTriplett 10y ago
For images that actually contain a color profile, the browser should certainly respect that. But for images that don't contain a color profile, assuming sRGB artificially creates a problem where none existed. WebKit is intentionally squashing rgb(241,0,0) into rgb(255,0,0), whether the display shows them as distinct colors or not. That might improve consistency across displays, in that it'll make every display lower quality, but it doesn't actually improve quality. It might be nice to know that the display you render on has better color fidelity, but why not show all the colors present in the image rather than squashing them together? Then, for instance, if you have a display that has better color reproduction than sRGB but not as good as P3, you'll get the full color reproduction your display can manage.
- lstamour 10y ago
  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.
- leni536 10y ago
  Well I agree that it is wrong simply because it breaks (for example) the PNG standard: "RGB samples represent calibrated colour information if the colour space is indicated (by gAMA and cHRM, or sRGB, or iCCP) or uncalibrated device-dependent colour if not." So webkit shouldn't try to transform the colors to sRGB but simply display it according to whatever display is present. Having said that sRGB designed to be consistent and not high quality. It even has a "black point" defined, but nobody respects that since it would cause a maximum contrast ratio for all images represented in sRGB.

by mwfunk 10y ago

JoshTriplett 10y ago

For images that actually contain a color profile, the browser should certainly respect that. But for images that don't contain a color profile, assuming sRGB artificially creates a problem where none existed. WebKit is intentionally squashing rgb(241,0,0) into rgb(255,0,0), whether the display shows them as distinct colors or not. That might improve consistency across displays, in that it'll make every display lower quality, but it doesn't actually improve quality. It might be nice to know that the display you render on has better color fidelity, but why not show all the colors present in the image rather than squashing them together? Then, for instance, if you have a display that has better color reproduction than sRGB but not as good as P3, you'll get the full color reproduction your display can manage.

lstamour 10y ago
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.
leni536 10y ago
Well I agree that it is wrong simply because it breaks (for example) the PNG standard: "RGB samples represent calibrated colour information if the colour space is indicated (by gAMA and cHRM, or sRGB, or iCCP) or uncalibrated device-dependent colour if not." So webkit shouldn't try to transform the colors to sRGB but simply display it according to whatever display is present. Having said that sRGB designed to be consistent and not high quality. It even has a "black point" defined, but nobody respects that since it would cause a maximum contrast ratio for all images represented in sRGB.