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.
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?)
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...
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.
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
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.
But some of these values have to be reserved for those extra colors in the wide gamut colorspace. And sRGB just fits in that range. That's why to truly take advantage of the wide gamut, the whole rendering process from a software through a GPU to an output device has to be at least 10 bits per channel (relying on what's being widely adopted). Otherwise, customers will be missing out with almost all available content.
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!
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.
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.
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.
This is kinda happening - the "UHD Alliance Premium Certified" spec for TVs mandates 10-bit from the input to the panel. It's a shame the UHD Blu-ray standard doesn't mandate 10-bit, thought hopefully most will use it :) Dolby Vision mandates 12-bit mastering and delivery, though it sounds like 10-bit connections to the panel can be considered acceptable...
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.