Towards richer colors on the Web
darker.ink
darker.ink
Ironic. Given the author's emphasis on Chromium, you would expect this example to work there. But, as far as I can tell, Chromium's "color management" currently converts all images to sRGB before rendering them in the system's color space, so the difference between the images is actually lost there. It works fine in Firefox (with color management enabled).
My understanding is that doing things correctly actually makes color management a lot more complicated for Firefox (because you can't just have the renderer do color management from a single source - sRGB - to a single target - the monitor's profile), but I think getting correct results for wide gamut images is worth it.
Note: my search powers are failing me at the moment, so I actually can't find where I first read about this problem, so I'm not sure whether it's the result of a bug or intended behavior, or even whether the problem extends beyond Linux + SDR screens.
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.
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.
> 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
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...
But I would hazard a guess that if you tried to pump P3 color through CSS or an SVG in Chrome, that would fail.
But does not seem to work on Edge on Windows 10 with a built in Dell XPS display.
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).
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...
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".
How can we tell whether it is the test that is broken or just that some screens render the colours differently?
There's a visible difference in most of the samples here https://webkit.org/blog-files/color-gamut/
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.
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
> 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.
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
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.
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
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/
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.
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.
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...
Kinda seems like it might be quite nice in a web/css world to be able to similarly work in some kind of fairly neutral 'linear' color-space in the code, and let the platform and hardware translate that as well as it can?
Not doing so results in weird looking shading, which has a very 90s/early 2000s feel about it.
I think it's worth noting here that linearizing-after-load is often not good enough, since the renderer most often has already automatically filtered (think MIP pyramid/etc) the texture values by the time you get hold of them. You always want the values in a linear color space (gamma=1.0) during filtering. Some renderers try to support this so you can load a jpeg without thinking about it too hard but myself I would prefer to include an explicit linearization step for extra control and peace of mind. You may end up wanting to use a specific LUT to linearize with for example, and the errors that creep in if gamma is not 1.0 can be quite subtle and hard to put your finger on, but can really sap photorealism in a nasty way.
Not really what you asked for but it helped me understand how massive of an impact colour grading can have on how you perceive a scene.
https://developer.nvidia.com/gpugems/gpugems3/part-iv-image-...
This is about working with linear-to-light values on GPUs however the issues in VFX are largely the same.
In both Firefox and Chrome I couldn't see the webkit logo on the right hand red square, HOWEVER if I copy/pasted the right hand red square into Paint.NET the logo was VERY visible. Why did it work in one app and not the others?
I'm not sure how / whether Paint.NET does color management.
When the manufacturers get this sorted out, you'll likely still have to make a trade-off between latency (240hz), resolution (8K), HDR (bit depth), and your suggestion (more color channels)
Probably most convenient would be to start using 16-bit floating point numbers for each of 3 color channels, so that would still increase bandwidth somewhat compared to current high-end displays which use 10 or 12 bits per channel.
It would eventually cool to have spectral representations of images, but that isn’t necessary for just expanding the gamut.
With paints and pigments, it's pretty common to have more than three primary colors mixed in. But with more non-orthogonal axes, there's more overlap where you can achieve the same color multiple ways by combining the colors in different proportions. E.g. purple could be a single purple wavelength or a combination of blue and red.
There, the main focus is on very bright shades (whiter than white), but highly saturated colors are in scope as well.
I definitely appreciate the work to enable this, but honestly remain skeptical how important it is. I mean, sRGB #FF0000 is a pretty bright red. When do you really need more than that?
The main downside is that as gamuts get expanded via narrower-spectrum primaries, there is an increasing risk of inter-observer variability (I also wonder if they may cause more eye strain, have worse effects on sleep cycles, ...).
A better solution than the current trend of wide gamuts made by 3 primaries with very narrow spectra would be displays with 6+ primaries, but that takes a much more dramatic redesign of the last few stages of the graphics pipeline, a more dramatic hardware redesign, and potentially different content to really show off (content that will moreover be really hard to effectively show on older displays). I’m still hoping it happens within the next couple decades, but I wouldn’t hold my breath.
If you know the shape of common RGB gamuts, you’ll start to notice how much all of our RGB-displayed visual media is constrained and nudged toward particular choices. There are e.g. color choices made in some paintings that can’t be effectively used in films. There are plenty of physical scenes that can’t be effectively reproduced. And on the flip side, areas of the RGB gamut where there is more available contrast get used a lot, even when they don’t quite fit the mood.
I'm interested in exploratory questions of the form "If education content about mumble wasn't such a disaster, then... what? What might doing it well look like? How might doing it well then be used to teach other topics better?"
Color is widely taught preK-6. And yet first-tier physical-sciences graduate students not infrequently reply to "What color is the Sun?", with something like "it doesn't have a color; it's rainbow color". Suggesting that teaching is very not going well.
One might imagine perhaps adapting tablet/phone clip-on spectroscopes down towards K, and developing a spectra-centered content and learning progression for color. So let's hypothesize students with a firm grasp of color. What might they do with it?
> [...] you’ll start to notice how much all of our RGB-displayed visual media is constrained and nudged toward particular choices. There are e.g. color choices made in some paintings that can’t be effectively used in films. There are plenty of physical scenes that can’t be effectively reproduced. And on the flip side, areas of the RGB gamut where there is more available contrast get used a lot, even when they don’t quite fit the mood.
Any suggestions on resources for exploring these further? Any other favorite stories or examples, useful or fun, where understanding color well gives insight or skill? Any other thoughts? Thanks!
This is a hard question to answer. My answer would be something like “intense pain followed by blindness”. :-)
But you could also say that sunlight is “white”, because it excites all of our cone cells and is by far the brightest object in any field of view. You could change the spectral power distribution of the sun quite a bit one way or another and it would remain “white”, because our visual system adapts.
> One might imagine perhaps adapting tablet/phone clip-on spectroscopes
I’d start by handing out diffraction grating glasses, and looking at various kinds of lamps.
Oh, nice - I'd forgotten how the brief version of the question sends conversations in unexpected directions, and turns up a wide variety of conceptions. Long ago, to narrow the diversity of responses, I switched to asking longer versions, like "A 5-year old asks you: 'I'm told the Sun is a big hot ball! Awesome, I love balls! What color is the ball?' What color is the Sun?" Which has gotten a bit boring - same old failure modes grown familiar. Diverse could be useful again, for thinking about teaching color, and more fun.
> “intense pain followed by blindness”. :-)
Sooo... one can't tell what color a light is, unless you can look at it directly...? :P
> sunlight is “white”, because it excites all of our cone cells
So does my red shirt, no? Necessary but not sufficient. I'd love to find some content which tells a K-6 accessible story of spectra being convolved with L/M/S response curves.
Related common misconceptions from textbooks include "white means a mix of all colors" or "all colors equally".
> remain “white”, because our visual system adapts.
IIRC, the range of colors for which you can't tell there's a tint, rather than merely ignoring it, isn't very large. You get used to 5000K incandescent, but can still tell it's "warm" (ie, cooler/redder than white). Hmm, I suppose that's an increasingly less-than-wonderfully-accessible exemplar... maybe tablet/display night mode?
> diffraction grating glasses
Nifty. I wonder how they might be tweaked to be better for education. Maybe increase clarity, by using a strip of one-axis grating, cutting across a neutral-density filter background - so you still get the bright spectra, but can more easily switch between seeing source and spectra. Maybe bend the grating to spread the spectra out more??
Thanks!
No, the light reflected by your red shirt is not like the light from the sun, because it is nowhere near the brightest object in view. But you are right that if you made a lamp with the same spectral power distribution as light reflected by your red shirt but several orders of magnitude brighter, it would still probably be outside the range considered “white”, even after adaptation.
> how they might be tweaked to be better for education.
I think the current disposable cardboard ones which cost like 50¢ each (maybe less?) when bought in bulk are pretty good for education.
If you walk around at night with diffraction grating glasses looking at different kinds of lamps, you can learn a lot about what kind of light they produce.
You probably haven’t seen any “wide gamut” demos with fundamentally different primaries involved; display manufacturers have been expanding their gamuts by making the three RGB primaries have narrower and narrower spectral power distributions, rather than by adding additional primaries.
For a while Sharp made a “4-primary” display, but the additional “yellow” primary was more or less created by an additive mixture of existing “R” and “G” spectra, so didn’t really make as much practical difference as one would hope. https://en.wikipedia.org/wiki/Quattron
You can get a display with like 8 or 10 primaries if you run a color science research lab and can spend tens of thousands of dollars on it (or maybe more? dunno).
If you look at a photo produced by an RGB digital camera, color graded in some standard RGB space, and then presented on an RGB display vs. a 10-primary display, you aren’t going to see any obvious difference, because the content does not take any special advantage of the medium.
In comparison, if you look at a bunch of synthetic images created to highlight the differences / stretch the capabilities of the displays, or e.g. a video produced by a whole hardware–software–author pipeline expecting the more capable display, the differences will be pretty obvious.
If you want a somewhat relevant test, you can try comparing images produced by a photo printer with images printed in old newspapers. Having a larger gamut makes the former much more vibrant.
Current displays produce very intense orangish-red, purplish-blue, yellowish-green, and reddish-purple colors. So the differences with a hypothetical >5-primary display are going to be most noticeable in the blue-green range, and oranges and yellows.
If all you're paying attention to is what's on the screen then it probably doesn't matter much exactly what those colours are because it's all relative, your brain compensates for it, and it's not as if the cells in your eye have a consistent response to colour in any case: it all depends on what you've been looking at recently.
If you've ever been in a television shop, back when they still had shops, you could find two screens next to each other showing the same television channel but with radically different colours, when you compare them side-by-side, but if you watch just one of the screens - it doesn't matter which - you get used to the colours of that screen and everything looks fine.
I mean, sometimes you do. Especially when you're working with canvases. But I fear this will just be abused: what advertiser isn't going to want the brightest possible red in the gamut of the user's screen, instead of just the brightest possible red in sRGB?
... you mean, because it is super ultra orangish red? Your display’s version of FF0000 is literally the most intense vaguely red type of color that it can produce. Some standard RGB space’s version of FF0000 is literally the most intense vaguely red type of color that it can represent. The sRGB version is so colorful that it should be avoided for most practical purposes. Forget about ever putting the P3 version of FF0000 on screen, unless you hate your audience.
Or do you just mean it’s less intense than e.g. a laser pointer?
It's not, because we're talking about #FF0000 in a specific color space. Most monitors these days can go well beyond sRGB's version of red, but you have to have some way to express that through the software to the monitor. This shouldn't just be the brightest red your display can show, unless you calibrated it that way on purpose.
That some displays have a narrower-spectrum (and therefore more colorful) “R” primary than the sRGB spec is literally the premise of this conversation, and is understood by everyone here. But the sRGB spec’d primary is still extremely intense, beyond the practical needs of any user interface and the vast majority of images/videos.
Edit: ps. We are interested in meeting more of those colour domain experts...
50% larger - 1/3 larger would mean that only 1/4 of Display-P3 is missing from sRGB.
Not that it really matters since the LAB color space used to derive this difference makes no attempt to make the color volume meaningful.
The css spec has a rgb(function) for using sRGB values directly.
Yes the function for handling srgb values is called "rgb()"...