While a backlit display will have constant contrast ratio with changes in backlight level in terms of its light output, that isn’t typically the case when the viewing context is taken into account. Very few viewing conditions are completely dark, so a minimum black is set by the ambient light and the reflectance of the unlit display. So the practical contrast ratio tends to fall with a fall with display brightness.
The ambient light level tends to set limits on the practical display brightness and contrast ratio. Too low a brightness and the display looks washed out and shadow detail disappears. Too high a brightness and the display becomes uncomfortable to look at, shadow detail may become exaggerated, and highlight detail will tend to disappear.
I think I might be missing something. Isn’t a dark room precisely the situation where one would use a low screen brightness, thus making it more likely that the black level of the monitor will indeed be the limiting factor?
Obviously, I can’t speak for everyone, but at night, I have occasionally used my monitor in complete darkness, with a “white” (2700K) luminance of approximately 50 cd/m², and in those conditions, I am glad that the black point is around 0.06 cd/m² rather than the ~0.2 cd/m² that it would be with the backlight at full power. I lose enough contrast as it is by deviating so much from my monitor’s native white chromaticity.
I have actually played a bit with a similar idea (if I understand yours correctly), which is that I profiled my monitor at maximum brightness, and then I used DisplayCAL’s 3D LUT creator to create a LUT from BT.2020 + SMPTE 2084 (PQ) to that profile with luminance information and highlight roll-off:
After that, I applied it to HDR videos with ffmpeg’s lut3d filter (it’s quite slow… DaVinci Resolve does it faster if you are in a hurry) and played the result in a non-color-managed player (ffplay), and I found the result quite convincing.
So, I’m trying to summarize the situation. I also think this is what apple does. If there is anything that’s wrong or unclear please speak up! Same if you think it does not match what apple does.
Also, if anyone has access to a HDR display and MacOS and/or Windows: I would very much appreciate some testing so we can be sure what the behavior is!
1:
We use the backlight control to get the diffuse white luminance as closely to the surround luminance as possible. It uniformly scales the luminance of all values which should give us the biggest perceived dynamic range/constrast. This should work for SDR and HDR displays in the same way.
For SDR displays diffuse/reference white is usually just the luminance generated by the biggest code value. For HDR we now have enough dynamic range that we can dedicate some of it to highlights (apple calls this “headroom”) which means the reference white is generated by a smaller code value, depending how much headroom we have. Both HDR and SDR content can be tone mapped to the whole range with this common reference white.
Now, if the display is in a very bright environment we might not be able to raise the backlight enough to match the reference white luminance with the surround luminance. In that case we can take away the headroom by moving the reference white up to match the surround luminance (as much as possible).
I personal think that is crucial to have the correct color management from a design point of view.
Or we risk to have a broken system for all the fantastic graphical applications.
Trying to fix the color management issues after the implementation ( and diffusion ) of the protocol would be a big design mistake that would hit hardly all the community who work with colors.
I wouldn’t take that article too much as gospel. Wayland has a number of issues, not the least being the insanity around “security”. If you take the approach that no software is to be trusted, and you don’t trust the user to judge whether software is trustworthy, you end up with a system that is in practice useless to the end user. Yes, such systems can be useful in trivial/consumption only ways, but ultimately a system that doesn’t do what the end user needs, won’t be used. And time and time again the Wayland developers have responded with knee-jerk rejection of the idea that a user should actually be able to configure a display system to suite their needs, i.e. be color managed. The idea of different applications having different permissions seems to be foreign, or alternatively, the idea that if you are developing a graphic display protocol that you claim is going to displace the current solution, you have better make provision for how that system is managed and not simply reject it as “out of scope”, even though the current solution provides it.
This comes on top of a fundamental blunder in the original design of Wayland, making the assumption that RGB values are interchangeable between displays, allowing Wayland to keep the application (the thing that does the actual rendering/creation of the RGB values) in ignorance of which display the RGB values are going to end up on.
This has had to bend when faced with reality, but notably pointing out that RGB values are not interchangeable because different displays have different color responses wasn’t enough to convince anyone involved, it took the in-your-face obviousness that different displays have different DPI’s to force that issue.
I still find it incredible that so many Wayland developers have pontificated about “how color management should/shouldn’t be done” when they have never shown any sign that they have ever made a color profile, or even used a color managed application on a color managed display.
[ Apologies to the couple of Wayland developers that do know what they are talking about in regard to color. ]
And time and time again the Wayland developers have responded with knee-jerk rejection of the idea that a user should actually be able to configure a display system to suite their needs, i.e. be color managed. The idea of different applications having different permissions seems to be foreign, or alternatively, the idea that if you are developing a graphic display protocol that you claim is going to displace the current solution, you have better make provision for how that system is managed and not simply reject it as “out of scope”, even though the current solution provides it.
None of these things are actually at all true, and the reason colour management is in such a lamentable state is a lot to do with people just sitting around flinging insults over the wall.
(I am a Wayland and Weston developer who would love to see us doing colour properly in a way which satisfies professionals with a turbo-tweaked setup as well as end users who just want to not see the same images be purple on one monitor and green on another, and I’m really glad for the efforts of Sebastian, Pekka, etc, to make that happen.)
What I find, from a user perspective, even more interesting is that apparently HDR on Linux is possible, albeit without windowmanagment! I didn’t know that KODI does this already. Kritas HDR branch is only on windows atm, right?
How much coding would be needed for a HDR-Darktable-only mode? I wouldn’t mind rebooting for using darktable (or any other raw-developer for that matter) like Kodi. I know it sounds a bit silly. But whatever is going on in the window manager world, it apparently is not too fruitful in that regard. If I can’t have many windows/programs color-managed, just give me one program for one purpose on one HDR monitor!
the reason colour management is in such a lamentable state is a lot to do with people just sitting around flinging insults over the wall
Dare substantiate that claim? I’m pretty much out of the loop, so I don’t know what’s been going on (but I’ll tell you about my point of view in a moment).
Also, briefly on the topic of knee-jerk reactions, before moving on to more productive matters. The definition of a knee-jerk reaction as defined by (e.g.) dictionary.cambridge.org (first one I could find) is “a quick reaction that does not allow you time to consider something carefully”. If you re-read your own post, wouldn’t you say it is, indeed, categorized pretty well by that definition? The irony. And I don’t find it funny, I find it a bit annoying. Anyway. moving on. Sorry for even bringing it up, but it irked me enough to not being able to ignore it, because it is so prevalent these days. And it’s bad, really bad, because it makes constructive discourse difficult if not impossible.
I am a Wayland and Weston developer who would love to see us doing colour properly in a way which satisfies professionals with a turbo-tweaked setup as well as end users who just want to not see the same images be purple on one monitor and green on another
That’s good to hear, but we should probably quickly leave the notion that professionals have (or even need) “turbo-tweaked” setups behind. For professional work, consistency and reproducibility is key (same reasons why end users may want color management).
And a question. Do Wayland developers, in general, want the input of professionals/experts, with regards to color management? I’m asking this out of genuine curiosity, because there are not so many people in the field who I would consider experts, and in the past, my impression was that some of these experts were not taken too seriously (ahem), and their criticism was rather seen as an attack(?) than anything else. I find that a bit unfortunate.
If I could be bothered, I could go back and quote all the email exchanges to back what I said up. But life is too short. I spend countless hours explaining over and over again and in minute detail the ins outs of color management to the Wayland development list, as well as outlining a (IMO) quite viable way forward, but I got tired of the insults and disrespect, and since I’m not being paid to develop Wayland, I have had to stop there for now. If at some stage I were to find the time to create an implementation, I’m completely confident that it would work as advertised, and that it would be immediately rejected by mainline Wayland as being “unsuitable”
I did not read all of 450+ posts in this thread and I only read a small sampling of posts to the wayland list, so I could be talking out of my ass right now.
However, the sole fact that there hasn’t been a solution in at least 8 years that fullscreen color management for Wayland/Weston is being discussed sounds like a project management issue.
Hence, all technical aspects aside, how — in purely organizational terms — are you planning to ensure that this time round you end up implementing FSCM? And what’s your plan to make sure that your design meets requirements by experts in the field of color management and various stakeholders such as GIMP, Krita, Inkscape, Blender et al.?
I think that Wayland project has the great responsibility to keep together all the GNU/Linux graphic user community ( professionals too ).
GNU/Linux is already a niche ( for desktop ) and there is a real risk to pushing away professional users.
Professional users are often the reference for all users so a project design that is not targeted to professional too will damage all the GNU/Linux community.
I hope that Wayland will be compatible with a color management solution, targeted to all GNU/Linux graphic users ( professionals or not ).
Otherwise the GNU/Linux community should support an alternative solution with a correct design for color management.
And people blamed Mark Shuttleworth for investing in development of MIR…
If they were more accepting to his ideas we would have had a stable display server with all the features and color management we want by now. And we’d have a big company heavily invested in moving it forward. But no…
Now we have nothing ready more than 10 years later and by the time it’s ready it will be a few decades old and the technology would have passed it by.
