9 ms·

Improving Color on the Web

231 points by rayshan 10y ago

Gaelan 10y ago
One thing I've noticed is that Chrome and Safari have a visible difference in color management. Try opening [0] (<style> body { background-color: rgb(88,174,235); } </style>) in both browsers side-by-side, for example. [0]: data:text/html;charset=utf-8;base64,PHN0eWxlPiBib2R5IHsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDg4LDE3NCwyMzUpOyB9IDwvc3R5bGU+
- acangiano 10y ago
  On my Mac they look the same. https://www.evernote.com/l/AAG4fivAqoxHTb61wKDTesbMbR-OWtXd31o https://www.evernote.com/l/AAG4fivAqoxHTb61wKDTesbMbR-OWtXd3...
  - Gaelan 10y ago
    FF and Chrome look the same to me as well. Safari looks different.
    - jacobolus 10y ago
      FF and Chrome are both broken w/r/t color management.
      - emn13 10y ago
        http://www.gballard.net/firefox/ http://www.gballard.net/firefox/ Edge & Firefox support color management; though for best results in firefox you'll want to toggle http://kb.mozillazine.org/Gfx.color_management.mode http://kb.mozillazine.org/Gfx.color_management.mode to 1 - the default is 2, which is Not Good. Edge works out of the box.
  - userbinator 10y ago
    They are the same, but the actual colour in that screenshot is 99,183,238 which (un?)surprisingly is different from the 88,174,235 specified: http://i.imgur.com/PtkjfVj.png http://i.imgur.com/PtkjfVj.png
- userbinator 10y ago
  Is this a Mac-specific quirk, and what happens if you take a screenshot and compare the pixel values? On my Windows system I tried Chromium, Firefox, IE, and Opera (no Safari), they looked exactly the same. Taking a screenshot and sampling the pixel values gives 88,174,235 for all the browsers, as expected.
  - Gaelan 10y ago
    This is what I'm getting. Safari on right, Chrome on left. https://ipfs.pics/ipfs/QmS8hkCPxGr7iLDqotuHG6NXNeSesmQSWJGNKjX2f3PKoS https://ipfs.pics/ipfs/QmS8hkCPxGr7iLDqotuHG6NXNeSesmQSWJGNK... When Digital Color Meter (color-sampling tool on Mac) is set to "display native values," Chrome's values are consistent with CSS. When DCM is set to "display in sRGB," Safari's values are consistent with the CSS. edit: Not shown in screenshot, but Firefox is the same as Chrome.
    - pvg 10y ago
      It looks like in Chrome, the display profile correction is not being applied. If you change it to sRGB both are the same. Safari is doing the right thing here.
      - Gaelan 10y ago
        Chrome has a bug filed: https://bugs.chromium.org/p/chromium/issues/detail?id=254361&q=color%20srgb&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified https://bugs.chromium.org/p/chromium/issues/detail?id=254361... I can't tell if Firefox has a bug for this exact issue, but they do have some open color-management related issues.
        4ad 10y ago
        Firefox has the same bug. It has a non-default hidden option where you could previously set it to work correctly, but that option stopped working some time ago (at least on OS X). Chrome has had this bug filled 7 years ago, and they kept ignoring it (although it's a very popular bug, people complain about it all the time). It drives me insane. Basically I am forced to run Safari, although I'd very much prefer to use an open source browser.
ecaron 10y ago
This reminds me of a demo page from the late 90s that made me appreciate graphic formats on the web, where it highlighted what true alpha transparency could really accomplish and what you miss out on when you don't have it http://www.libpng.org/pub/png/pngs-img.html http://www.libpng.org/pub/png/pngs-img.html Beyond just the topic at hand, this is a wonderful example of showing people how much more the web can do and why it is important that we keep pushing for progress.
- vanderZwan 10y ago
  > If the images have obvious rectangular borders (due to the color specified in the bKGD chunk), the browser is broken. Well, Chrome is still broken for some of these images on Linux. Not surprising though, it also screws up resizing images: http://www.4p8.com/eric.brasseur/gamma.html http://www.4p8.com/eric.brasseur/gamma.html I with they would fix these things before worrying about wide gamut
deleted 10y ago
[deleted]
userbinator 10y ago
Here’s another example, this time with a generated image. To users on an sRGB display there is a uniform red square below. However, it’s a bit of a trick. There are actually two different shades of red in that image, one of which is only distinct on wide-gamut displays. On such a display you’ll see a faint WebKit logo inside the red square. I can clearly see the logo and I'm using a Samsung LCD from 2003. The pixel values are significantly different; the background is 255,0,0 and the logo is 241,0,0. The rest of my hardware is 2009-vintage. Likewise, the two shoe examples look very slightly (not a whole lot, but it's noticeable) different. On an sRGB display, you can’t see the logo, because all the red values above 241 in Display P3 are beyond the highest red in sRGB, so the 241 red and the 255 red end up as the same color. Seriously? 241 and 255 look very different to me, and if I remember correctly, would have always looked different in all the 24-bit colour monitors I've used. Edit: experimentation with my monitor a little more shows that I can just barely discern 252,0,0 from 255,0,0, but 253 and 254 look identical to 255. This probably depends on my colour perception too. Either way, I still doubt my monitor is "wide-gamut", so what's going on here?
- cbr 10y ago
  I think your system is ignoring the color profile attached to the image. They wrote: Remember the red square with the faint WebKit logo? That was generated by creating an image in the Display P3 color space, filling it with 100% red, rgb(255, 0, 0), and then painting the logo in a slightly different red, rgb(241, 0, 0). On an sRGB display, you can’t see the logo, because all the red values above 241 in Display P3 are beyond the highest red in sRGB, so the 241 red and the 255 red end up as the same color. But if your browser ignores color profiles, and many do, then the P3 -> sRGB conversion won't happen, and your sRGB monitor will be told to display some 241 red and some 255 red instead of all 255 red.
  - hollander 10y ago
    I have a retina display, use Firefox as default browser. In firefox I see the webkit logo, in Safari not. So it seems like Firefox has better color support than Safari? I would expect the opposite. How does this work?
modeless 10y ago
People who focus on color profile support in a world where all colors are compressed to 8 bits per channel with a nonlinear gamma curve are obsessing about the wrong problems. I notice banding artifacts (caused by quantization to 8 bits) and blending issues (caused by linear blending of nonlinear values) way more often than I notice anything related to color gamuts. People who care about color should be pushing to change the default color representation to a linear format with 16 bits per channel rather than making marginal changes to the edges of 8 bits per channel gamma compressed representations. That has to start with the addition of 16 bit floating point format support to various hardware. It's really a crying shame that so little hardware supports 16 bit floating point. In addition to imaging it would be useful for audio, and deep learning too.
- panic 10y ago
  And if you don't want to pay the memory/bandwidth costs of doubling your image size, you can keep storing your images in 8 bpc sRGB, but convert from sRGB to linear before blending/interpolation and convert back afterward. Modern GPUs have built-in support for this. There's really no excuse for incorrect blending!
  - kbwt 10y ago
    And yet all font rendering on Linux is done with incorrect alpha blending. There are patches for the major toolkits but as anything to do with font rendering, people are very resistant to change.
- vladdanilov 10y ago
  Exactly. The Wide Gamut is simply a selling point to have "vivid" colors. But most of the images including UI are still sRGB. Showing them on a 24-bit wide-gamut display means every color component is mapped to only a subset of 0-255 values. That will lead to a more noticeable banding than viewing the same image on an sRGB display [1]. The aforementioned DCI-P3 even have a higher gamma value of 2.6. Currently, almost all design compositions are done in the gamma compressed space, and the incorrect AA [2] and blending will be even worse on those devices. Another thing is that most of displays are not even calibrated properly. Not even speaking about technical characteristics of the screens. [1] https://twitter.com/vmdanilov/status/745321798309412865 https://twitter.com/vmdanilov/status/745321798309412865 [2] https://twitter.com/vmdanilov/status/712327571116056576 https://twitter.com/vmdanilov/status/712327571116056576
jkeler 10y ago
Wide gamut is not enough, we also need HDR (that is Rec 2020 color space with Perceptual Quantizer). This will allow to show much brighter (and darker) colors.
hollander 10y ago
I have a retina screen, but see no difference with the ProFoto images in the demos. The AdobeRGB images show a difference and improvement. It's a pity that the demo with the sliders results in flickering, which makes it useless.
- scarlac 10y ago
  Retina only refers to resolution. Color representation is a deeper "qualitative" feature of the display. Currently I am only familiar with Apple's retina iMac which would be able to correctly display their examples.
  - Razengan 10y ago
    The 9.7" iPad Pro also has a P3 display if I'm not mistaken.
pmontra 10y ago
Firefox, Ubuntu 16.04, HP Zbook 15 (G1) with a 1080p display (not the DreamColor one). I do see the differences in all the images with the exception of Shoes, Flowers and Rose. I remember that Ubuntu installed a color profile but I don't know if it's calibrated for my screen. Nice to know that I have an above average display.
achairapart 10y ago
It's worth mentioning that Apple only introduced 10bit per color support since OSX El Capitan[0] and with the iPad Pro while wide-gamut monitors, both professional and prosumer ones, have been around for years now. [0]: http://www.cultofmac.com/395028/apple-quietly-added-10-bit-color-support-for-new-5k-imac/ http://www.cultofmac.com/395028/apple-quietly-added-10-bit-c...
- saulr 10y ago
  Very interesting. Just to clarify, am I right in saying that 10-bit colour just provides more precise colours within the sRGB gamut? 10-bit colour does not extend the colour gamut in anyway?
  - lcrs 10y ago
    Correct! But for wider gamuts (and higher-contrast displays), the benefit becomes more obvious in the lack of banding.
Daiz 10y ago
On the matter of improving colors, it would also be nice if browsers played nice with colorspaces (Rec.601/Rec.709) when dealing with YUV to RGB conversion in HTML5 video. Right now all browsers I've tested straight up ignore colorspace tagging in H.264 video and have some other issues too. I have a little thing you can use to see this for yourself: http://daiz.io/yuv-to-rgb-in-html5-video/ http://daiz.io/yuv-to-rgb-in-html5-video/ Basically, if the Result doesn't match up with Expected, the browser is doing it wrong. Ideally browsers should handle YUV colorspaces like so: H.264 video - look for colorspace tagging in the video by default and use it if available, otherwise fall back to guessing based on resolution. SD video (up to 1024x576) should be converted with Rec.601, HD video (width >1024 or height >576) with Rec.709. VP8 video - VP8 is defined as Rec.601 only, so always use it. Theora - Same as VP8. How browsers actually fare today (tested on Windows 10): IE11/Edge - Always assumes Rec.601 for H.264 video. Doesn't support VP8/Theora. Chrome - No colorspace tagging support for H.264. Converts HD video with Rec.709, SD video with Rec.601. 1024x576 is treated as HD already. VP8 is always converted with Rec.601 as it should. Theora gets Rec.601 in SD but incorrectly uses Rec.709 in HD. Firefox - No colorspace tagging support for H.264. HD uses Rec.709, SD uses Rec.601, 1024x576 treated as HD like in Chrome. VP8 and Theora both always use Rec.601 as they should. The unfortunate conclusion from this is that color accuracy is pretty much a crapshoot when dealing with HD video on the web. The only way to guarantee accurate results right now would be to convert your video to Rec.601 (if you're mastering HD video chances are you're using Rec.709 by default), serve VP8 video by default and have a Rec.601 H.264 fallback for IE/Edge (I haven't tested how Flash video playback handles this matter so you might also need a Rec.709 H.264 fallback for that).
- lcrs 10y ago
  The IE11 result makes me weep here, given the popularity of it - thanks for doing these tests. The amount of work we put into maintaining correct colour through the production chain seems increasingly wasted... FYI I tested Safari 9.1.1 (11601.6.17) and it failed on a whole bunch of the tests, including, frighteningly, the untagged HD 709 H264 :(
TheRealPomax 10y ago
I have bugs for this on webkit outside for... 4 years and counting. To the point I got so frustrated I wrote my own rant on gamuts and color spaces over on https://pomax.github.io/1436836360570/we-are-really-terrible-at-digital-colours-and-digital-photography https://pomax.github.io/1436836360570/we-are-really-terrible... - seeing someone finally acknowledge this on the actual webkit blog is heartening. Maybe things _can_ change.
opticalflow 10y ago
This whole situation is rather nasty. There was enough of consternation going from NTSC ("never-the-same-color") to digital, with the bifurcation/trifurcation of SMPTE 240M, BT.601 and BT.709, plus the bifucation of "legal" versus "PC" color ranges for all of the foregoing (thanks, Microsoft). I've seen VERY few pieces of software (and even broadcast hardware) that get even just THAT complication all sorted, and even less people who really know what they're doing operating the systems and software tools involved. Now, we're adding BT.2020, SMPTE 2084, Dolby Vision, and all sorts of proprietary stuff like Sony S-LAB. This is going to be a disaster -- nothing will properly talk to each other, e.g. cameras, encoders, video displays/monitors. Everyone can't even agree whether 10-bit is enough or whether we really need 12-bit for accurate reproduction. SMPTE and ISO just punted the question down the road by saying you can have any flavor of ice cream you want. I predict fun times ahead at next year's NAB...

231 points by rayshan 10y ago

One thing I've noticed is that Chrome and Safari have a visible difference in color management. Try opening [0] (<style> body { background-color: rgb(88,174,235); } </style>) in both browsers side-by-side, for example. [0]: data:text/html;charset=utf-8;base64,PHN0eWxlPiBib2R5IHsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDg4LDE3NCwyMzUpOyB9IDwvc3R5bGU+

acangiano 10y ago
On my Mac they look the same. https://www.evernote.com/l/AAG4fivAqoxHTb61wKDTesbMbR-OWtXd31o https://www.evernote.com/l/AAG4fivAqoxHTb61wKDTesbMbR-OWtXd3...
- Gaelan 10y ago
  FF and Chrome look the same to me as well. Safari looks different.
  - jacobolus 10y ago
    FF and Chrome are both broken w/r/t color management.
    - emn13 10y ago
      http://www.gballard.net/firefox/ http://www.gballard.net/firefox/ Edge & Firefox support color management; though for best results in firefox you'll want to toggle http://kb.mozillazine.org/Gfx.color_management.mode http://kb.mozillazine.org/Gfx.color_management.mode to 1 - the default is 2, which is Not Good. Edge works out of the box.
- userbinator 10y ago
  They are the same, but the actual colour in that screenshot is 99,183,238 which (un?)surprisingly is different from the 88,174,235 specified: http://i.imgur.com/PtkjfVj.png http://i.imgur.com/PtkjfVj.png
userbinator 10y ago
Is this a Mac-specific quirk, and what happens if you take a screenshot and compare the pixel values? On my Windows system I tried Chromium, Firefox, IE, and Opera (no Safari), they looked exactly the same. Taking a screenshot and sampling the pixel values gives 88,174,235 for all the browsers, as expected.
- Gaelan 10y ago
  This is what I'm getting. Safari on right, Chrome on left. https://ipfs.pics/ipfs/QmS8hkCPxGr7iLDqotuHG6NXNeSesmQSWJGNKjX2f3PKoS https://ipfs.pics/ipfs/QmS8hkCPxGr7iLDqotuHG6NXNeSesmQSWJGNK... When Digital Color Meter (color-sampling tool on Mac) is set to "display native values," Chrome's values are consistent with CSS. When DCM is set to "display in sRGB," Safari's values are consistent with the CSS. edit: Not shown in screenshot, but Firefox is the same as Chrome.
  - pvg 10y ago
    It looks like in Chrome, the display profile correction is not being applied. If you change it to sRGB both are the same. Safari is doing the right thing here.
    - Gaelan 10y ago
      Chrome has a bug filed: https://bugs.chromium.org/p/chromium/issues/detail?id=254361&q=color%20srgb&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified https://bugs.chromium.org/p/chromium/issues/detail?id=254361... I can't tell if Firefox has a bug for this exact issue, but they do have some open color-management related issues.
      - 4ad 10y ago
        Firefox has the same bug. It has a non-default hidden option where you could previously set it to work correctly, but that option stopped working some time ago (at least on OS X). Chrome has had this bug filled 7 years ago, and they kept ignoring it (although it's a very popular bug, people complain about it all the time). It drives me insane. Basically I am forced to run Safari, although I'd very much prefer to use an open source browser.

ecaron 10y ago

This reminds me of a demo page from the late 90s that made me appreciate graphic formats on the web, where it highlighted what true alpha transparency could really accomplish and what you miss out on when you don't have it http://www.libpng.org/pub/png/pngs-img.html http://www.libpng.org/pub/png/pngs-img.html Beyond just the topic at hand, this is a wonderful example of showing people how much more the web can do and why it is important that we keep pushing for progress.

vanderZwan 10y ago
> If the images have obvious rectangular borders (due to the color specified in the bKGD chunk), the browser is broken. Well, Chrome is still broken for some of these images on Linux. Not surprising though, it also screws up resizing images: http://www.4p8.com/eric.brasseur/gamma.html http://www.4p8.com/eric.brasseur/gamma.html I with they would fix these things before worrying about wide gamut

deleted 10y ago

[deleted]

userbinator 10y ago

Here’s another example, this time with a generated image. To users on an sRGB display there is a uniform red square below. However, it’s a bit of a trick. There are actually two different shades of red in that image, one of which is only distinct on wide-gamut displays. On such a display you’ll see a faint WebKit logo inside the red square. I can clearly see the logo and I'm using a Samsung LCD from 2003. The pixel values are significantly different; the background is 255,0,0 and the logo is 241,0,0. The rest of my hardware is 2009-vintage. Likewise, the two shoe examples look very slightly (not a whole lot, but it's noticeable) different. On an sRGB display, you can’t see the logo, because all the red values above 241 in Display P3 are beyond the highest red in sRGB, so the 241 red and the 255 red end up as the same color. Seriously? 241 and 255 look very different to me, and if I remember correctly, would have always looked different in all the 24-bit colour monitors I've used. Edit: experimentation with my monitor a little more shows that I can just barely discern 252,0,0 from 255,0,0, but 253 and 254 look identical to 255. This probably depends on my colour perception too. Either way, I still doubt my monitor is "wide-gamut", so what's going on here?

cbr 10y ago
I think your system is ignoring the color profile attached to the image. They wrote: Remember the red square with the faint WebKit logo? That was generated by creating an image in the Display P3 color space, filling it with 100% red, rgb(255, 0, 0), and then painting the logo in a slightly different red, rgb(241, 0, 0). On an sRGB display, you can’t see the logo, because all the red values above 241 in Display P3 are beyond the highest red in sRGB, so the 241 red and the 255 red end up as the same color. But if your browser ignores color profiles, and many do, then the P3 -> sRGB conversion won't happen, and your sRGB monitor will be told to display some 241 red and some 255 red instead of all 255 red.
- hollander 10y ago
  I have a retina display, use Firefox as default browser. In firefox I see the webkit logo, in Safari not. So it seems like Firefox has better color support than Safari? I would expect the opposite. How does this work?

modeless 10y ago

People who focus on color profile support in a world where all colors are compressed to 8 bits per channel with a nonlinear gamma curve are obsessing about the wrong problems. I notice banding artifacts (caused by quantization to 8 bits) and blending issues (caused by linear blending of nonlinear values) way more often than I notice anything related to color gamuts. People who care about color should be pushing to change the default color representation to a linear format with 16 bits per channel rather than making marginal changes to the edges of 8 bits per channel gamma compressed representations. That has to start with the addition of 16 bit floating point format support to various hardware. It's really a crying shame that so little hardware supports 16 bit floating point. In addition to imaging it would be useful for audio, and deep learning too.

panic 10y ago
And if you don't want to pay the memory/bandwidth costs of doubling your image size, you can keep storing your images in 8 bpc sRGB, but convert from sRGB to linear before blending/interpolation and convert back afterward. Modern GPUs have built-in support for this. There's really no excuse for incorrect blending!
- kbwt 10y ago
  And yet all font rendering on Linux is done with incorrect alpha blending. There are patches for the major toolkits but as anything to do with font rendering, people are very resistant to change.
vladdanilov 10y ago
Exactly. The Wide Gamut is simply a selling point to have "vivid" colors. But most of the images including UI are still sRGB. Showing them on a 24-bit wide-gamut display means every color component is mapped to only a subset of 0-255 values. That will lead to a more noticeable banding than viewing the same image on an sRGB display [1]. The aforementioned DCI-P3 even have a higher gamma value of 2.6. Currently, almost all design compositions are done in the gamma compressed space, and the incorrect AA [2] and blending will be even worse on those devices. Another thing is that most of displays are not even calibrated properly. Not even speaking about technical characteristics of the screens. [1] https://twitter.com/vmdanilov/status/745321798309412865 https://twitter.com/vmdanilov/status/745321798309412865 [2] https://twitter.com/vmdanilov/status/712327571116056576 https://twitter.com/vmdanilov/status/712327571116056576

jkeler 10y ago

Wide gamut is not enough, we also need HDR (that is Rec 2020 color space with Perceptual Quantizer). This will allow to show much brighter (and darker) colors.

hollander 10y ago

I have a retina screen, but see no difference with the ProFoto images in the demos. The AdobeRGB images show a difference and improvement. It's a pity that the demo with the sliders results in flickering, which makes it useless.

scarlac 10y ago
Retina only refers to resolution. Color representation is a deeper "qualitative" feature of the display. Currently I am only familiar with Apple's retina iMac which would be able to correctly display their examples.
- Razengan 10y ago
  The 9.7" iPad Pro also has a P3 display if I'm not mistaken.

pmontra 10y ago

Firefox, Ubuntu 16.04, HP Zbook 15 (G1) with a 1080p display (not the DreamColor one). I do see the differences in all the images with the exception of Shoes, Flowers and Rose. I remember that Ubuntu installed a color profile but I don't know if it's calibrated for my screen. Nice to know that I have an above average display.

achairapart 10y ago

It's worth mentioning that Apple only introduced 10bit per color support since OSX El Capitan[0] and with the iPad Pro while wide-gamut monitors, both professional and prosumer ones, have been around for years now. [0]: http://www.cultofmac.com/395028/apple-quietly-added-10-bit-color-support-for-new-5k-imac/ http://www.cultofmac.com/395028/apple-quietly-added-10-bit-c...

saulr 10y ago
Very interesting. Just to clarify, am I right in saying that 10-bit colour just provides more precise colours within the sRGB gamut? 10-bit colour does not extend the colour gamut in anyway?
- lcrs 10y ago
  Correct! But for wider gamuts (and higher-contrast displays), the benefit becomes more obvious in the lack of banding.

Daiz 10y ago

On the matter of improving colors, it would also be nice if browsers played nice with colorspaces (Rec.601/Rec.709) when dealing with YUV to RGB conversion in HTML5 video. Right now all browsers I've tested straight up ignore colorspace tagging in H.264 video and have some other issues too. I have a little thing you can use to see this for yourself: http://daiz.io/yuv-to-rgb-in-html5-video/ http://daiz.io/yuv-to-rgb-in-html5-video/ Basically, if the Result doesn't match up with Expected, the browser is doing it wrong. Ideally browsers should handle YUV colorspaces like so: H.264 video - look for colorspace tagging in the video by default and use it if available, otherwise fall back to guessing based on resolution. SD video (up to 1024x576) should be converted with Rec.601, HD video (width >1024 or height >576) with Rec.709. VP8 video - VP8 is defined as Rec.601 only, so always use it. Theora - Same as VP8. How browsers actually fare today (tested on Windows 10): IE11/Edge - Always assumes Rec.601 for H.264 video. Doesn't support VP8/Theora. Chrome - No colorspace tagging support for H.264. Converts HD video with Rec.709, SD video with Rec.601. 1024x576 is treated as HD already. VP8 is always converted with Rec.601 as it should. Theora gets Rec.601 in SD but incorrectly uses Rec.709 in HD. Firefox - No colorspace tagging support for H.264. HD uses Rec.709, SD uses Rec.601, 1024x576 treated as HD like in Chrome. VP8 and Theora both always use Rec.601 as they should. The unfortunate conclusion from this is that color accuracy is pretty much a crapshoot when dealing with HD video on the web. The only way to guarantee accurate results right now would be to convert your video to Rec.601 (if you're mastering HD video chances are you're using Rec.709 by default), serve VP8 video by default and have a Rec.601 H.264 fallback for IE/Edge (I haven't tested how Flash video playback handles this matter so you might also need a Rec.709 H.264 fallback for that).

lcrs 10y ago
The IE11 result makes me weep here, given the popularity of it - thanks for doing these tests. The amount of work we put into maintaining correct colour through the production chain seems increasingly wasted... FYI I tested Safari 9.1.1 (11601.6.17) and it failed on a whole bunch of the tests, including, frighteningly, the untagged HD 709 H264 :(

TheRealPomax 10y ago

I have bugs for this on webkit outside for... 4 years and counting. To the point I got so frustrated I wrote my own rant on gamuts and color spaces over on https://pomax.github.io/1436836360570/we-are-really-terrible-at-digital-colours-and-digital-photography https://pomax.github.io/1436836360570/we-are-really-terrible... - seeing someone finally acknowledge this on the actual webkit blog is heartening. Maybe things _can_ change.

opticalflow 10y ago

This whole situation is rather nasty. There was enough of consternation going from NTSC ("never-the-same-color") to digital, with the bifurcation/trifurcation of SMPTE 240M, BT.601 and BT.709, plus the bifucation of "legal" versus "PC" color ranges for all of the foregoing (thanks, Microsoft). I've seen VERY few pieces of software (and even broadcast hardware) that get even just THAT complication all sorted, and even less people who really know what they're doing operating the systems and software tools involved. Now, we're adding BT.2020, SMPTE 2084, Dolby Vision, and all sorts of proprietary stuff like Sony S-LAB. This is going to be a disaster -- nothing will properly talk to each other, e.g. cameras, encoders, video displays/monitors. Everyone can't even agree whether 10-bit is enough or whether we really need 12-bit for accurate reproduction. SMPTE and ISO just punted the question down the road by saying you can have any flavor of ice cream you want. I predict fun times ahead at next year's NAB...