Paalanen: Developing Wayland Color Management and High Dynamic Range

[Posted November 20, 2020 by jake]

Over on the Collabora blog, Pekka Paalanen writes about adding color management and high dynamic range (HDR) support to the Wayland display server protocol. X11 already has support for color management tools and workflow, but not HDR, and Wayland currently doesn't support either, but Paalanen and others are working to change that. "As color management is all about color spaces and gamuts, and high dynamic range (HDR) is also very much about color spaces and gamuts plus extended luminance range, Sebastian [Wick] and I decided that Wayland color management extension should cater for both from the beginning. Combining traditional color management and HDR is a fairly new thing as far as I know, and I'm not sure we have much prior art to base upon, so this is an interesting research journey as well. There is a lot of prior art on HDR and color management separately, but they tend to have fundamental differences that makes the combination not obvious."

Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Nov 20, 2020 3:10 UTC (Fri) by flussence (guest, #85566) [Link] (2 responses)

Wayland might be a chance to finally sort out this mess. I've got two monitors that support basic 30bpp input, one a decade old now, and it's never been safe to use on X because so many things make the assumption that every drawable is 24bit (some may even be assuming it can't be *lower*, but I don't want to check).

Of course, graphics drivers missing 30bpp support for years didn't help…

Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Nov 20, 2020 5:18 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

I think that’s a third issue. You can have 10 bits per channel (R,G,B) but still not accurately model the colour gamut provided by the monitor. If the computer produces a signal which is 100% red, 40% green and 20% blue, what exactly is that in terms of frequencies of light coming from the screen? Is there an exponential relation between the size of these numbers and the amount of light, and if so what is the gamma? And how are those perceived as colours by a human? All these questions apply equally whether you have 30 bit, 24 bit or even 6 bit output.

Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Nov 23, 2020 15:07 UTC (Mon) by imMute (guest, #96323) [Link]

>If the computer produces a signal which is 100% red, 40% green and 20% blue, what exactly is that in terms of frequencies of light coming from the screen? Is there an exponential relation between the size of these numbers and the amount of light, and if so what is the gamma? And how are those perceived as colours by a human?

All of this is defined in the EOTF of the color standard the computer and display are using. In SDR days, that was universally assumed to be sRGB (for color primaries) and gamma (transfer function). For HDR, it's some other set of primaries (maybe Rec. 2020) and either PQ or HLG (for the transfer function).

And yes, all of that is orthogonal to the bit depth of the data (other than PQ and HLG really needing at least 10 bits to be of sufficient quality).

Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Nov 20, 2020 3:33 UTC (Fri) by rillian (subscriber, #11344) [Link]

Nice to see someone finally working on colour management in Wayland!

Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Nov 20, 2020 8:37 UTC (Fri) by pabs (subscriber, #43278) [Link] (5 responses)

I feel like there is going to be a lot of complexity around what are the potential effects are of always running monitors in HDR mode. Do they use more power for the same luminance? less? Does it reduce the lifetime of the hardware? Does it cause damage to the hardware (like burn-in on CRTs?)? Does it work better or worse than SDR for some display technology types? How well tested is the HDR support on a specific monitor, will there be glitches or firmware bugs?

Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Nov 20, 2020 9:35 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Monitors always run in HDR mode. It's just that in the SDR mode the color correction is done by the monitor's hardware, and not your GPU.

I guess HDR mode might use a bit more power since the GPU will have to do color conversion?

Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Nov 20, 2020 14:23 UTC (Fri) by leitec (subscriber, #129199) [Link] (3 responses)

It shouldn't be too bad power-wise. MacOS has been doing GPU-based color space conversions at the OS level since 2009's Snow Leopard, if I recall correctly.

One side effect that has come up when applications enable color management is that some users have gotten used to and prefer their uncorrected wide gamut monitors. I think this is a problem on Android, too. There were a lot of _very_ angry responses in Chromium's and Visual Studio Code's bug trackers about "wrong colors" after that. VScode and some other Electron apps ended up disabling it by default.

The irony is that if you get used to oversaturation and hue shift when displaying sRGB/Rec709 content on a wide-gamut screen, true wide-gamut content closer to the monitor's gamut can end up looking dull.

Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Nov 21, 2020 16:16 UTC (Sat) by dgm (subscriber, #49227) [Link]

The thing is, in my humble opinion, that out of the few professional users that really, REALLY need to match colors on the screen with colors on other media (paper, photo, movies) it really is not that important. After all, the human visual system has evolved to be excel at ignoring slightly off colors and bad lighting.

Except... when you have multiple displays. In this case, the changes in color and brightness when you move a window from one display to the next can drive you nutts...

I hope that this new Wayland capabilities make fixing this easy for desktop environments.

Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Dec 1, 2020 0:57 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (1 responses)

There are a lot of text-based applications that have very fervent user bases. And these days, it's *mostly* possible to detect whether a terminal supports 8 colors, 256 colors, or true color (24-bit, 16 million colors) using various terminfo capabilities. The thing about 8 colors is that you normally use a fixed palette which can be customized in the terminal emulator's settings, and different emulators have different defaults. The same 8-color application may look different on different systems, and the user may further customize those 8 colors as they see fit (e.g. using per-application terminal profiles). On the other hand, it's not really possible to customize the higher-depth color spaces without explicit application support. So I have to wonder if there have been any similar incidents when an app started autodetecting color depth and switched from 8 colors to 256 colors or true color, suddenly "breaking" lots of setups at once.

Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Dec 12, 2020 6:06 UTC (Sat) by flussence (guest, #85566) [Link]

I seem to remember terminal programs rendering garbage when they tried to use true color in rxvt-unicode, which deliberately misimplemented it (among other things, like unicode) to scare people away from trying. Maybe it's caught up a decade later, but an attitude like that was enough to put me off the author's software forever.

Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Nov 20, 2020 13:41 UTC (Fri) by daenzer (subscriber, #7050) [Link] (3 responses)

I'd pick this quote:

"To me it was obvious from the start that color management architecture on Wayland must be fundamentally different from X11. I thought the display server must be part of the color management stack instead of an untrusted, unknown entity that must be bypassed and overridden by applications that fight each other for who gets to configure the display."

"X11 already has support for color management tools and workflow" is kind of an overstatement. It allows each client to control the whole colour processing pipeline, with no coordination between clients.

Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Nov 20, 2020 14:33 UTC (Fri) by Herve5 (guest, #115399) [Link] (2 responses)

Real beginner here, but isn't 'coordination between clients' performed, today, through color profiles straight in the system?

I mean, I have a (hardware) profiler, with which I calibrated each one of my screens, and then by selecting these color profiles, per screen, once and for all* I really see that once activated I do have the same color palette respected when for instance I move a picture window from screen A to screen B...
Which is basically my main need at color management (the next one is having the same profiler calibrate my printers)

I agree color profiles aren't specially HDR, but they still seem to perform a huge task for me, that not any HDR software will do until each one of our screens will self-calibrate...

(*)OK, I'm supposed to recalibrate every now and then, to compensate for ageing

Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Nov 23, 2020 12:33 UTC (Mon) by Baughn (subscriber, #124425) [Link] (1 responses)

Which color calibration tool do you use?

I have a need for something similar, but there are tons of cheap and not so cheap options out there and I have no idea which would work. I have one HDR monitor, and three non-HDR ones, but really I just want windows to look the same regardless of monitor.

color cal. tool : XRite i1Studio

Posted Nov 25, 2020 17:22 UTC (Wed) by Herve5 (guest, #115399) [Link]

Hardware side, I have an XRite i1Studio, that can calibrate practically anything (printers, monitors, projectors...). It comes with software for macs, windows and NOT Linux but (a) you can scan and get a profile .icc file with these systems then copy it into Linux and (b) on Linux there are the Argyll package, very efficient if more complicated, that do the job...
Indeed it's extremely significant to move an image from a screen to another and seeing the same colors, and more than that, then switch to any of your printers and still see the same nuances once printed. You just won't regress...
XRite also proposes quite cheaper devices for just screens but I definitely don't regret mine...