One question I have is what does “correct” mean? If a DCI-P3 image is displayed on an sRGB monitor, is there a “correct” way to do it? I would think that there might be multiple valid ways to convert wide gamut colors into sRGB, and that it really depends on what constraints the viewer wants satisfied. For example, if I want to preserve relative perceived differences between colors, maybe I’d map the boundary of DCI-P3 to the boundary of sRGB, and then interpolate all the interior colors (possibly with some non-linearities). This would allow people with sRGB monitors to see the WebKit logo in the article’s example, and it’s a perfectly reasonable and valid way to convert colors. However, this would make it so that converting from sRGB red to DCI-P3 and back returns a different color (less bright and/or saturated) than what you started with. So a different and perfectly reasonable conversion would be to match the colors within the sRGB gamut perfectly at all times, and clamp colors outside the sRGB gamut to the sRGB boundary. Even when clamping, there are multiple valid choices - clamp to the nearest point (prioritize brightness), or move toward the center of the gamut and stop on the boundary intersection (prioritize hue). A third option would be to preserve some overlapping interior region of the two gamuts exactly, and start to smoothly blend between them near the boundary.

What I think this means is that I don’t know whether I can expect to see the WebKit logo on an sRGB display. Since the browser doesn’t ask me what kind of conversion I’d like, it’s reasonable to assume it’s clamping when converting (in which case the logo is lost), and it’s also (perhaps) reasonable to expect color differences to get preserved (in which case I’d see the logo).

Probably the most correct thing to do would be to let either the developer and/or the viewer have a say in how the conversion should happen?

> you can’t just have the renderer do color management from a single source - sRGB - to a single target

I’m not sure I understand what you mean here, could you elaborate? What else needs to be involved? I would think knowing the source color space, and the target monitor’s nearest supported color space is exactly what you need, so if the source is DCI-P3 and the monitor only has sRGB, a sophisticated but well defined conversion is used, while if the monitor is DCI-P3 then the conversion is the identity function.

You are correct here. The conversion from one color space to another when the gamuts are not identical is an artistic decision, and there is no scientifically "correct" way to do it.

There can be standards so a content creator can know what to expect, and there's an awful lot of weight put into attaching metadata to source images so the transform can be informed by the metadata, but I also think it's fair to say the entire thing is a mess and that in 99+% of the cases there's a good chance trying to do fancy color management will cause something to go wrong (if not least, inconsistent results on some clients), whereas keeping everything in sRGB gives you a baseline of quality; the only thing you don't get are those super-bright colors.

Most of the algorithms built into common software for converting from one color space to another (especially e.g. RGB to CMYK) are pretty terrible, and even though it’s a tricky problem with no right answer per se, the automatic transformation could be much better. A competent human photoshop user is going to get substantially better results than current algorithms almost every time.

Great question. You're 100% correct, the whole test depends on the specifics of renderer behavior. The author of the article is assuming that any screen with less than sRGB coverage will tonemap the DCI-P3 image to look exactly the same as the sRGB one.

> if I want to preserve relative perceived differences between colors, maybe I’d map the boundary of DCI-P3 to the boundary of sRGB, and then interpolate all the interior colors (possibly with some non-linearities). This would allow people with sRGB monitors to see the WebKit logo in the article’s example

Yep. This sort of tonemapping is frequently applied to video. With images, this problem is usually handled through a chosen rendering intent [1] This way of doing it is usually called a perceptual rendering intent, and there are various algorithms that do it in different ways. However, for photographic materials the preferred approach is usually a colorimetric rendering intent, usually relative colorimetric.

With relative colorimetric, white point adjustments are made (if necessary), but more importantly, out-of-gamut colors are simply clamped to the nearest in-gamut color. This means something very important: if the user's screen only shows a subset of sRGB colors, then both the sRGB image and the DCI-P3 image will be clamped in exactly the same way, and appear to be indistinguishable. So basically, the comparison relies on the renderer using a relative colorimetric rendering intent, not a perceptual one. This is usually (?) a safe assumption.

> I’m not sure I understand what you mean here, could you elaborate?

Note that I'm not 100% sure that I'm right about the browser internal specifics. Basically, I have a screen that's roughly DCI-P3 capable. The browser has access to an ICC profile that describes the properties of my screen. There are lots of things in the browser that need to be adapted from whatever color space they're in natively to the screen's color space. There are canvases, videos, CSS colors, untagged images, images with ICC tags, etc etc.

So the problem is that each one of these elements may have a different (or entirely untagged) source space, and they all have to be converted to the monitor space. The approach you take to canvases may need to be different than the approach you take to video. Video has to be done very quickly if you're going to do it at all because each frame only lives a few ms. One really easy way to do a color space conversion would be to just assume that every layer the compositor sees is sRGB, and convert that to the monitor space. You get roughly correct video rather cheaply that way, for example, because the Rec. 709 space used by most web video is almost the same as sRGB.

But this means that earlier in the chain, any part of the page that is known not to be sRGB (like ICC tagged images) will need to be converted to sRGB so the compositor can handle it. This acts as a choke point. My experience suggests that this is the approach that Chrome takes on Linux. They get color management for free for any new thing because it's usually safe to just assume it's sRGB.

Firefox does it differently. Every different page element is responsible for its own color space conversion. That's why canvases weren't color managed at all in Firefox until very recently. Video still isn't, I think. AVIF images (which are still under a feature flag) still aren't color managed either. So color management in Firefox is shaky. But for anything that is color managed, you get correct colors, even if the source color space isn't sRGB!

    Chrome:
      (page elements) => sRGB -> monitor space
    Firefox:
      (some page elements) -> monitor space

[1] https://en.wikipedia.org/wiki/Color_management#Rendering_int...

Interestingly, the DCI-P3 demo is working in Chrome on Mac now. (It didn't used to-- Safari/Webkit was the only browser that handled DCI-P3 images on Mac for a while.)

That's good. I assume you mean the webkit logo test. I wonder what's different about color management on macOS such that this was hard for the other browsers to support.

Correctly decoding images tagged in any color space has worked correctly in both Firefox and Chromium for as long as I can remember on Linux. In fact, it's even working "correctly" now on Chromium+Linux, it's just that they're seemingly choosing to render everything to an intermediate color space of sRGB before rendering out to the screen.

I found a good additional test to illustrate the problem with Chrome. [1] With the first test, "How far from sRGB is your display color gamut" the bars look exactly the same in Chrome to me. [2] But they're not oversaturated (i.e. in the monitor color space), they're seemingly correct sRGB colors, as displayed in a color managed way on my screen. The ProPhoto tagged image in Chrome looks exactly like the sRGB tagged image does in Firefox. So Chrome is performing color management, it's just effectively clamping the output to the sRGB gamut.

[1] https://cameratico.com/tools/web-browser-color-management-te...

[2] https://ipfs.io/ipfs/QmeVGD9kWXFNyywgJZpnfwFdv3KDuEADwkiA9va...

Safari uses an OS level thing for decoding images — this is why Safari 14 for MacOS “Big Sur” can display WebP images, but Safari 14 Catalina cannot. So it is possible that Chrome is using the same system lib to render images, which thusly can display P3.

But I would hazard a guess that if you tried to pump P3 color through CSS or an SVG in Chrome, that would fail.

It's working on an iPhone with iOS 14 with Edge and Safari (both of course using the same rendering engine on iOS)

But does not seem to work on Edge on Windows 10 with a built in Dell XPS display.

Yes, to be precise, it doesn't work on many Chrominum derived browsers because they can't consistently handle rich colour spaces.

It works on Safari and Firefox, and in some cases, Chrome on Mac.

Get off Google-controlled browsers. Stop using Chrome in 2021. The open Web matters. Google is actively evil (Manifest v3 hindering uBlock Origin, AMP, FLoC, collusion deal with FB, etc).

> doesn't work on many Chrominum derived browsers because they can't consistently handle rich colour spaces.

Do you have any references documenting the problems with Chrome's handling of wide color gamuts? I can't seem to find anyone discussing the problem I'm seeing with the colors being clamped to sRGB. Maybe I discovered it a few months ago, but I seem to remember finding a discussion about it somewhere...

> It works fine in Firefox (with color management enabled).

Hmmmm. I do have two different reds in Firefox. But I wouldn't describe the test as "working fine"; the two reds are so similar to each other that I'm unable to perceive the webkit logo. I can tell there's a circle, and that takes effort.

For a test to be "working", the judge needs to be able to tell the difference between "test succeeded" and "test failed".

I'm also on Firefox and can very clearly see the difference between the two reds.

How can we tell whether it is the test that is broken or just that some screens render the colours differently?

I'm on Linux/Firefox and the colour difference is very stark for me. I tested with both AdobeRGB and sRGB modes of my monitor.

There's a visible difference in most of the samples here https://webkit.org/blog-files/color-gamut/

Even if you see it, the hardware could be lying to you! Unless the whole pipeline has support, you get subtly wrong results.

My Firefox on Android happily displays a difference, the webkit logo is very visible. And my AMOLED screen can actually go beyond DCI-P3.

But the phone is cheating. It's "enhancing" sRGB colors to wide gamut by cranking up the saturation accross the whole screen, and the settings are "sRGB" or "DCI-P3", but that doesn't turn off the post-processing filter it just adjusts the strength.

The P3 flowers on that test page in particular look completely wrong on my phone.

You likely have a "fake" HDR monitor. To cover most of the new gamut requires very bright backlight. Most cheap HDR PC monitors are only ~400nits, not nearly bright enough. They bare bones HDR 400 spec most meet is... Not very HDR.

For proper HDR you need 1000+ nits. Only Apple monitors and a few very expensive alternatives can do this. On other monitors the gamut is compressed and there's little difference between the colors at the edges.

You can test your monitor with this https://m.youtube.com/watch?v=NlAsAuBtmps When it stops getting brighter, you've maxed out your display and it can't display the additional range.

For whatever reason TV tech is way better. Even cheap TVs tend to be brighter than the brightest PC monitors. If you have the space, a 40 inch TV sitting farther away will be far superior picture quality than a monitor

This isn't quite right. You can have colors that are significantly out of gamut without being over-bright. Moreover, they might be using a traditional SDR screen which doesn't have any management of brightness at all. I can easily see the difference between the two images on my screen, which displays gamut differences out to about DCI-P3 despite only being a ~250 nit laptop screen.

> You can test your monitor with this https://m.youtube.com/watch?v=NlAsAuBtmps

Actually I'm surprised to hear Youtube supports HDR video at all. I was under the impression that web support for HDR video was still rather lacking.

You are right, but many of these colors are physically dim and much harder to notice than the HDR "pop" of extremely bright colors.

YouTube has surprisingly great support for HDR and Wide Color Gamut. There's some utterly breathtaking 4k 60fps HDR WCG videos of Japanese cities I've been watching. The only downside is you practically need a supercomputer to decode them in realtime.

Many games are also getting "definitive edition" remasters with HDR and they look glorious.

Getting a quality HDR screen was a bigger upgrade for me than 1080p->4k . There's simply a shitload of colors that older monitors can't produce

> YouTube has surprisingly great support for HDR and Wide Color Gamut.

That's good to hear. Does it work on PC? I assume it's browser / OS limited if so.

> but many of these colors are physically dim and much harder to notice than the HDR "pop" of extremely bright colors

That's true, but on the other hand the typical diffuse white of an HDR film is only about 200 nits or so, well within reach of most SDR screens. Extremely bright things like small points of light and explosions do look way better in HDR, but there are also plenty of extra-sRGB colors that display perfectly fine on a 200 or 300 nit WCG SDR scren.

> Getting a quality HDR screen was a bigger upgrade for me than 1080p->4k

That's the exciting part of the new technology for sure. You've got to sit pretty close to a 4k screen to notice a difference. It's more useful for professionals who sit a couple feet away typing text into a 30 inch monitor all day.

I've only gotten it to work on Windows with Chrome so kinda lame, but at least it works well.

HDR is great for lifelike scenes. Games and movie. For browsing, kinda pointless.

People don't realize that sunny days are 5000+ nits and regular screens only hit 300. HDR makes things way more lifelike

It's worked fine in Chrome for years on Macs with P3 displays, I don't know why Chromium would be any different.

While Firefox only finally brought proper color management last month. [1]

Maybe's it's a Chromium-on-Linux thing?

[1] https://www.mozilla.org/en-US/firefox/89.0/releasenotes/

> While Firefox only finally brought proper color management last month.

This was just a flag they turned on (on macOS?) to treat untagged images and CSS colors as sRGB. It's been available for everyone on all platforms since Firefox 3.5, which was released in 2009.

I believe the argument for not enabling it is that supposedly there are a lot of Windows systems out there with incorrect color profiles installed, and doing color management on every image on the web makes that suddenly very obvious. Chrome has faced quite a bit of user rage over this, and still has a setting to allow users to force the browser to treat their screen as sRGB for that reason. People like their oversaturated colors.

http://kb.mozillazine.org/Gfx.color_management.enabled

If 99.9% of your users don't turn on a flag, then as a web designer, it doesn't exist. Saying "it's there behind a flag" is utterly useless. It's something web designers need to depend on, not users.

And who likes oversaturated colors? What user rage? I've never heard of any of that. To the contrary, it was a huge problem that in Firefox, image RGB values didn't match CSS RGB values on P3 displays. How the heck are you supposed to create an interface with, you know, colors that match? Kind of a basic requirement. Thankfully, they finally fixed it. Why it took them 12 years is beyond me, though.

> And who likes oversaturated colors? What user rage?

I regret to inform you...

https://techdows.com/2020/07/chrome-84-force-color-profile-s...

https://old.reddit.com/r/chrome/comments/930egn/set_force_co...

https://support.google.com/chrome/thread/50631110/force-colo...

https://bugs.chromium.org/p/chromium/issues/detail?id=110556...

Ha, I was surprised that my monitor was physically capable of displaying it, but it didn't even occur to me that I should have been just as surprised that Firefox could render it!

It doesn't work in Vivaldi on Android either. You have to download it and open it in Google Photos to see the difference (all other apps I tried work exclusively in sRGB too).