> The image on the left below is a uniform red square in the sRGB gamut. The image on the right is slightly different, as it actually uses two different shades of red: one that is within the sRGB gamut and another that is outside of it. On sRGB displays, both colors are painted the same and the result is a uniform red square, just like the first image. However, on a system that can display wide-gamut colors, both shades of red will be painted differently and you will be able to see a faint WebKit logo inside the square.
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.
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
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.
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.
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".
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 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.
> 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.
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.
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).
In VFX for film, color is a huge issue too. What companies mostly do is to try to use a 'linear-to-light' color-space internally, pre-linearizing turned-over footage before working with it, and then post-transforming the final composites either back to the original colour space, or something similar. Doing this allows images to be freely filtered, resized, defocused, color-corrected etc whilst within the pipeline without it creating incorrect results because of non-linear color.
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?
This is also how modern game engines work. Textures are converted to linear space and all rendering is done in linear space before being converted to sRGB for display at the end.
Not doing so results in weird looking shading, which has a very 90s/early 2000s feel about it.
Yeah totally! Some of the ideas from openEXR seem like they could help a lot here! Of course there's nothing stopping ppl from storing not-linear pixel values in whatever color space you like in an exr file, but at least the format can do a reasonable job of recording metadata about this, so that it can still hopefully still be linearized on load.
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.
Someone posted this cool little tool[1][2] on Reddit a while back (no affiliation). It colour grades an image you upload based on a scene you select from their gallery.
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.
What I didn't understand, and maybe someone can explain it to me...
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?
The right image is not in sRGB, it's in Display P3. The difference in reds is pretty subtle, so most likely if Paint.NET is showing a dramatic difference, it's misinterpreting the color space of the PNG image.
Do you have color management fully enabled in Firefox? If you don't have a color profile assigned then Firefox will probably just treat your screen as sRGB, meaning that both images will be compressed into the tiny sRGB gamut and look the same.
I'm not sure how / whether Paint.NET does color management.
There are bandwidth limitations. My 120hz 4K main monitor supports HDR, but a single displayport cable can't push data fast enough to use HDR at that resolution and frame rate. I can connect 2 cables between my monitor and 3090 GPU to enable HDR, but that would break gsync.
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)
You don’t need more color channels in all of your images to support more display primaries (at least, to a basic level). You just need GPU-type hardware built into the display which can convert each small area of an image made of pixels with colors represented in a trichromatic space to the appropriate signals sent to whatever physical arrangement of varied-primary pixels to reproduce the intended color (assuming a human viewer with typical color vision).
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.
ProPhoto RGB colorspace has room for some non-physical colors, but it still only has three axes for primaries. It just has a range broad enough to include most visible colors as well as some that don't correspond to a sensory input you can get with your three color receptors.
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 FF0000 part of the wider gamut is pretty useless per se, but widening the gamut also gives you a lot of nice non-eye-bleeding colors in other areas. RGB gamuts are very limited in light red, dark yellow, light and dark teal, etc. colors.
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.
> If you know the shape of common RGB gamuts, you’ll start to notice [...]
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??
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.
I've never seen a wide gamut demo that was impressive to me. High frame rate yes, high contrast/brightness for HDR yes, those are definitely worthwhile. But wide gamut just doesn't seem to make a big difference to justify the implementation cost. I'd love to see some content that would justify wide gamut for me. Any suggestions?
I sometimes make hue a meaningful attribute in data visualizations, but try to keep chroma roughly consistent for various hues, so that varying chroma does not cause visual artifacts unrelated to the data. RGB gamuts are very limited in blue–green colors (when you additively mix purplish blue “B” and yellowish green “G”, it’s hard to make a bright blue–green), and as a result my whole data visualization ends up with relatively lower chroma than I would like. With an additional few primaries (say, adding a greenish blue primary and a bluish green primary), the chroma-width of the gamut would be much more consistent across various hues, which would let these visualizations be something like twice as intense. It would make a huge difference.
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).
I'm sure if I saw a 10 primary display sitting next to an RGB one for reference, I could tell a difference. But if it was just sitting there by itself, in regular non-ideal viewing conditions, I doubt I would think that it is significantly better than normal displays. Whereas for high frame rate and high brightness/contrast displays I can easily see a big improvement under normal non-ideal viewing conditions without needing a reference.
Again, it would depend on the content shown. If you watch a 24 frame/second video on a 120 Hz computer display, I’m not sure you’ll notice much difference. If you use an extremely high contrast display to show a low-contrast image, you won’t see any obvious difference. If you use a 4K display to show a 240p video, you won’t see any obvious difference. If you watch a video with monophonic sound on a 7.1 sound system, you won’t hear any obvious difference. Etc.
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.
High frame rate benefits all interactive content, and touchscreen interaction especially. High brightness and contrast benefits most content generally and practically all content under bright viewing conditions. But even if you upgraded all of your content to high gamut, I think only a small fraction of it would benefit in any noticeable way.
It would be noticeable if all content authors were experienced in the medium, but in the transitional period there would be little obvious difference, because the entire culture of digital imaging, including almost all existing content, is based around the limitations of RGB displays and images.
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.
I think it would only be useful if the colours on the screen have to match colours off the screen.
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, sRGB #FF0000 is a pretty bright red. When do you really need more than that?
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?
If you look at the color space diagrams, #FF0000 isn't super ultra red. If your monitor is showing it that way, maybe it's miscalibrated, and inaccurately showing a brighter red than is actually encoded in the file?
... 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?
literally the most intense vaguely red type of color that it can produce
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.
By chopping “Your display’s version of FF0000” out of your quotation, you dropped the whole point of the sentence, which is about the native RGB space of your display.
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.
I enjoy articles that do the following. There are people in my team who specialize in this area and know so much more than me about it than I do. We are working on really exciting projects that I don't get the chance as a manger to understand fully under-the-hood, but casual weekend reading just got me closer! It always interests me how much top developers are not just coding experts but also domain experts.
Edit: ps. We are interested in meeting more of those colour domain experts...
> The Display-P3 space is about one third larger than sRGB. This means that from CSS we have no access to roughly one third of the colors that modern monitors can display.
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.
I love how most recent CSS specs about color were done though a linear lens. When color functions like darken() were in the spec, the color math wasn't done in sRGB which explains why darken in Less and Sass often look bad and the CSS blur filter makes ugly muddy browns between blocks of color.
I think the confusion arises from the css specs using absolute RGB values as opposed to values calculated within the sRGB color space designed by HP ETAL.
The css spec has a rgb(function) for using sRGB values directly.
Yes the function for handling srgb values is called "rgb()"...
With a lot of things fighting for my time, could someone give me a TL;DR ? Specifically, is this blog post just another a re-hash of the modern web colour stuff already covered in Refactoring UI[1] ?
To;dr: traditional sRGB displays have a narrow color gamut, the new displays have a much better gamut, with brighter reds and greens. A new color API uses Lab and LCh color spaces, better suited to human vision, allow interesting ways to express and manipulate color, including the newly available. Chromium has some support, if you have the right screen (I don't). The API is backwards compatible to sRGB screens. Many small demos.
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.