Paalanen: Developing Wayland Color Management and High Dynamic Range

Posted Nov 20, 2020 9:35 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: Paalanen: Developing Wayland Color Management and High Dynamic Range by pabs
Parent article: Paalanen: Developing Wayland Color Management and High Dynamic Range

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.