
Improving Color on the Web - rayshan
https://webkit.org/blog/6682/improving-color-on-the-web/
======
modeless
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.

~~~
vladdanilov
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)

~~~
userbinator
_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._

Unless they're just being mapped directly, which would probably make
everything automatically look much more vivid... and that would help sell
those displays too.

~~~
vladdanilov
But some of these values have to be reserved for those extra colors in the
wide gamut colorspace. And sRGB just fits in that range. That's why to truly
take advantage of the wide gamut, the whole rendering process from a software
through a GPU to an output device has to be at least 10 bits per channel
(relying on what's being widely adopted). Otherwise, customers will be missing
out with almost all available content.

------
userbinator
_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
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
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?

~~~
spiralganglion
To the best of my knowledge, the only Apple devices with wide-gamut displays
are the 2015 iMac and the 2016 9.7" iPad Pro. So I'd suspect that Firefox is
either ignoring the color profiles, or handling them differently than Safari.

~~~
lloeki
To be fair, on my 2013 rMPB, the Shoes one does not show a single difference
whereas the Iceland, Italy, Sunset and Flower ones are much more vibrant and
indicate that a wider gamut than sRGB may be available, but certainly not as
much as the latest display.

~~~
givinguflac
I have an iPad Pro 9.7, and the color differences are very noticeable,
especially in the wider variation of grass colors in the shoe image.

------
ecaron
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
> _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

------
Daiz
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
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 :(

------
Gaelan
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
On my Mac they look the same.
[https://www.evernote.com/l/AAG4fivAqoxHTb61wKDTesbMbR-
OWtXd3...](https://www.evernote.com/l/AAG4fivAqoxHTb61wKDTesbMbR-OWtXd31o)

~~~
Gaelan
FF and Chrome look the same to me as well. Safari looks different.

~~~
jacobolus
FF and Chrome are both broken w/r/t color management.

~~~
emn13
[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.

------
achairapart
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-c...](http://www.cultofmac.com/395028/apple-quietly-added-10-bit-
color-support-for-new-5k-imac/)

~~~
saulr
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
Correct! But for wider gamuts (and higher-contrast displays), the benefit
becomes more obvious in the lack of banding.

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

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

------
TheRealPomax
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...](https://pomax.github.io/1436836360570/we-are-really-terrible-at-
digital-colours-and-digital-photography) \- seeing someone finally acknowledge
this on the actual webkit blog is heartening. Maybe things _can_ change.

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

------
hollander
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
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
The 9.7" iPad Pro also has a P3 display if I'm not mistaken.

