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) <i>way</i> more often than I notice anything related to color gamuts.<p>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.<p>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.
<i>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><p>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.<p><i>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.</i><p>Seriously? 241 and 255 look <i>very</i> different to me, and if I remember correctly, would have always looked different in all the 24-bit colour monitors I've used.<p>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?
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 <a href="http://www.libpng.org/pub/png/pngs-img.html" rel="nofollow">http://www.libpng.org/pub/png/pngs-img.html</a><p>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.
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: <a href="http://daiz.io/yuv-to-rgb-in-html5-video/" rel="nofollow">http://daiz.io/yuv-to-rgb-in-html5-video/</a><p>Basically, if the Result doesn't match up with Expected, the browser is doing it wrong. Ideally browsers should handle YUV colorspaces like so:<p>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.<p>VP8 video - VP8 is defined as Rec.601 only, so always use it.<p>Theora - Same as VP8.<p>How browsers actually fare today (tested on Windows 10):<p>IE11/Edge - Always assumes Rec.601 for H.264 video. Doesn't support VP8/Theora.<p>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.<p>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.<p>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).
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.<p>[0]: data:text/html;charset=utf-8;base64,PHN0eWxlPiBib2R5IHsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDg4LDE3NCwyMzUpOyB9IDwvc3R5bGU+
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.<p>[0]: <a href="http://www.cultofmac.com/395028/apple-quietly-added-10-bit-color-support-for-new-5k-imac/" rel="nofollow">http://www.cultofmac.com/395028/apple-quietly-added-10-bit-c...</a>
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...
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.
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 <a href="https://pomax.github.io/1436836360570/we-are-really-terrible-at-digital-colours-and-digital-photography" rel="nofollow">https://pomax.github.io/1436836360570/we-are-really-terrible...</a> - seeing someone finally acknowledge this on the actual webkit blog is heartening. Maybe things _can_ change.
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.
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.