Improving Color on the Web

https://webkit.org/blog/6682/improving-color-on-the-web/

by rayshan • 10 years ago

231 74 10 years ago

ecaron• 10 years 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

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• 10 years 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

I with they would fix these things before worrying about wide gamut

Gaelan4• 10 years 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• 10 years ago

On my Mac they look the same. https://www.evernote.com/l/AAG4fivAqoxHTb61wKDTesbMbR-OWtXd3...

Gaelan4• 10 years ago

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

userbinator7• 10 years 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

userbinator7• 10 years 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.

Gaelan4• 10 years ago

This is what I'm getting. Safari on right, Chrome on left. 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.

userbinator7• 10 years 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• 10 years 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.

hollander2• 10 years 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?

cmurf• 10 years ago

For a long time now, display technologies have been moving away from sRGB. Not just by design, but the decay rate and vector of the primaries due to the different phosphors and filters being used.

So anything about consistent color on the web ignores the reality that the viewing device is likely not at all sRGB. And then just as big of a problem and sometimes worse is the viewing condition is highly variable.

snuxoll• 10 years ago

Even my monitor (ASUS VE248Q) when set to the sRGB profile shows the image fine, which seems a little odd to me. Even stranger, when in "Theater" or "Standard" profiles it doesn't appear. I don't think any of these settings likely change the color profile of the display, but probably just tweak brightness/contrast/etc levels - so sRGB isn't even really sRGB a lot of the time even if it "says so".

mwfunk• 10 years 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.

JoshTriplett3• 10 years 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.

foolrush• 10 years ago

He changed the original statement.

The reason for this for anyone not familiar with colours and pixels is that the Apple P3 primary colour red is a different red from sRGB's. That means that if you do not provide additional metadata, the value will be dumped directly to whatever type of display you are using, making it display the colours using your display's lights.

As other posters have noted, if you view the colour with no colour management system in place, you are instructing the machine to display 241 intensity as is, which means you are seeing (very likely) the sRGB lights in your display set to 241 and 255 intensity; a very easy difference to spot. This is not the intention of his example.

In a colour managed system, that 241 value is transformed into an absolute colour model, and from there it is mapped to the smaller gamut of sRGB. That is, the Apple P3 RGB lights are converted to meaningful sRGB RGB light representations.

So why does an Apple P3 value end up being the "same" sRGB value, despite being different colours? It amounts to a mapping issue.

The entire range of intensity values at 8 bits per pixels for the Apple P3 red channel is an identical colour at all intensity levels. Same goes for sRGB; intensity does not change the colour. When we examine any single P3 intensity, we can map that colour to a "closest possible" sRGB triplet. No matter what we do, the P3 red is different to the sRGB red light, and the sRGB red light can never represent the fully saturated and different red of the Apple P3, no matter what encoded intensity value.

Given that the P3 primary for red is quite different, we end up with a value for sRGB, that after transformation and clipping to the sRGB gamut, is a collision when mapped to sRGB; several different colours might end up mapped to the same sRGB colour due to quantization. In the case of 241, it happens to map to 255 using the rendering intent he selected because some or both of the complimentary values end up negative and clipped in the smaller sRGB gamut. Every other value is also being mapped to sRGB, and there are going to be mapping collisions along the entire intensity range because again, no matter what we do, the sRGB red lights can never represent the red lights of Apple's P3.

An excellent reference on ICC colour management is here for anyone interested, including covering rendering intents and other issues: http://www.cambridgeincolour.com/tutorials/color-space-conve...

modeless• 10 years 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• 10 years 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• 10 years 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.

vladdanilov3• 10 years 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 [2] https://twitter.com/vmdanilov/status/712327571116056576

userbinator7• 10 years ago

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.

lcrs5• 10 years ago

The antialiasing linear vs. gamma debate is an interesting one - check out this conversation, wherein nobody could figure out a reasoned method other than "sometimes AA in sRGB looks good"... https://twitter.com/rygorous/status/512371399542202368

nness• 10 years ago

In a practical sense, if you are doing lots of complicated blending or gradients in Photoshop, you can set your mode to 16-bits. It will stop reduce a lot of banding issues, and you can convert back to 8-bits with dithering when saving out as a common format.

Keyframe2• 10 years ago

I do film color work as part of my job. It's nuts how many hoops one has to jump over to give proper, almost proper, image experience on a variety of viewing devices. It's akin to sound mastering.

When there are gradients visible, more or less the only thing you can do is to introduce artificial monichromatic noise to the image to hide the perception of a staggered gradient.

I would like to see an industry-wide push for consumer-grade (at least) 10-bit signal chain from graphics cards to monitors with high dynamic range. That would have more impact on image quality than crap being pushed for now, like 4k and VR.

HDR B4 4K, chaps!

givinguflac3• 10 years ago

I do not disagree that focus is needed in that area too, but larger gamut can cut down or eliminate many banding artifacts by default.

emn133• 10 years ago

I've got a wide gamut monitor, and I vehemently disagree. Banding issues are real, but in my experience minor inconveniences compared to the huge step forward in realism that wide gamut brings.

Part of it is probably the kind of content you care about: "artificial looking" UI such as e.g. typical desktop apps care least (imho) about gamut. But if they don't do subtle gradients, then you won't notice banding either. On the other hand, for photographic content, you really notice those new colors you just can't represent in sRGB. I would really regret having to give that up, and would tolerate even visibly annoying banding every day to if it means having pictures that actually look like real life, and not like muddy, lifeless copies.

But to be clear: I very rarely notice any banding whatsoever, and when I do it certainly seems to be due to the source not the processing. Perhaps it's an OS/driver thing, or perhaps it's because more pictures contain sufficient noise to act as poor mans dithering, but banding just doesn't seem to be a (meaningful) issue. I mean: it's visible if you have large area subtle gradients, but not to a huge degree nor and well... don't do that?

Most things I see are either entirely flat (no banding) or photographic (noisy enough that you won't easily see banding).

I agree that a deeper color space is about time, although I suspect that going 16-bit floating point is an overreaction for most scenarios. Floating point isn't free, and neither are all those extra bits. With a decently high gamma, you can probably get away with just 10bits per channel, which would conveniently keep a pixel within 32-bit for efficient packed processing. And in the odd case that you really want to spend more than 10bits on color detail, then even for HDR you really don't need floating point - due to gamma correction, 2 extra bits means 20-50 times more light - more than enough for any kind of hdr that's likely to be displayable any time soon (and really, even if we could make peaks of 30000 nits - does that sound like something you want to look at?)

lcrs5• 10 years ago

10-bit with a log or gamma encoding is widespread in film and video work, and I've never known a banding problem, even with purely generated gradients. The Rec. 2020 UHD standard does recommend 12-bit gamma-encoded to deal with the ludicrously wide gamut.

For HDR, a PQ (perceptual quantisation) encoding curve is already standardised by SMPTE - page 8 in these slides goes through the process of how it was worked out, right from human visual system basics: https://www.smpte.org/sites/default/files/2014-05-06-EOTF-Mi...

Given the abundance of log or gamma encodings for display imagery you might wonder why true linear 16-bit float is so common in CG production - why not log encode those 16 bits and get loads smoother gradients? Maybe the answer is that during production those linear files often also encode non-image data like vertex positions and normals, and perceptually "good" quantisation of those could lead to unexpected precision problems...

jkeler• 10 years 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.

hollander2• 10 years 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• 10 years 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• 10 years ago

The 9.7" iPad Pro also has a P3 display if I'm not mistaken.

pmontra• 10 years 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• 10 years 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-c...

saulr• 10 years 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?

lcrs5• 10 years ago

Correct! But for wider gamuts (and higher-contrast displays), the benefit becomes more obvious in the lack of banding.

Daiz• 10 years 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/

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

lcrs5• 10 years 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• 10 years 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... - seeing someone finally acknowledge this on the actual webkit blog is heartening. Maybe things _can_ change.

opticalflow• 10 years 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...

Improving Color on the Web

Related Stories