This is the way. People should spend more money on displays and less on new camera bodies. Iāve always used hardware-calibrated displays at work, but never at home. macOS at work and Linux at home.
Should probably get a hardware calibrated display for Linux use at home too (considering the Wayland situation). What did you settle for?
Note that Darktable didnāt implement it correctly yet. What they did merely happens to work on older Gnome versions (which didnāt support full color management), but itās limited to sRGB on Plasma 6.0 and Gnome 50+ (thatās assuming Gnome removed colord support, if they did not, then it will have completely wrong colors).
(works in sway git)
and then writing bt2020 data to a A2R10G10B10_UNORM_PACK32 buffer, for hdr using a PQ transfer function. i can use my colorimeter to check a few colour patches for plausibility. this is good except for the colours that are outside the monitorās gamut (it speaks bt2020 but it doesnāt span the whole space, itās not OLED).
hdr is good fun, not sure i want it as my daily driver. has weird halos around bright spots.
OLEDs donāt span the entire 2020 colour gamut either. Youād need a set of single wavelength LASERs to do that (and Iāve only seen one such projector in the entire UK).
There are reasons you wouldnāt want to span the entire gamut, it makes viewer metamerism worse.
The main issue is that thereās no consistency in how out of display gamut colours are mapped in to gamut.
Krita 6.0 was just released with support for Wayland color management. As customary release notes focuses on HDR. But they also say:
the Wayland Color Management Protocol will provide us with all the information we need to provide color managed views of images, including everything we need to know for HDR display
But support for Qt6 isnāt the only thing Krita 6 brings. It also comes with Linux Wayland support, in particular a full featured implementation of the Wayland Color Management protocol. This finally brings HDR support to the Linux version of Krita!
The Wayland Color Management Protocol is still very young. It was the key feature we have been waiting for all these years: where on the older X11 display servers we could always figure out on which monitor we were on and which color profile to associate with that monitor, Waylandās architecture is designed around not giving away that information so easily.
This is a problem for a painting application which core feature is fully integrated color management. Now, the Wayland Color Management Protocol will provide us with all the information we need to provide color managed views of images, including everything we need to know for HDR display. Because this part of Wayland is still very young, using it means you will need an up-to-date window manager that supports it. We ourselves recommend the manager the code has been written against: KWin 6.4.4 and above.
I just noticed something interesting: I set my monitor profile in KDE Plasma display settings and set srgb color intensity to 100% - so the colors are oversaturated on my wide gamut screen and I can do the color management inseide darktable etc. There is also a calibration curve inside my profile because thatās how the colors look best. However, inside Chrome, the colors are correct, and the difference between srgb and adobergb is clearly visible. Even though color management in Chrome is not enabled resp. in set to default. I knew that wcmp is fully implemented in Chrome, but I did not know that this even works when the colors are oversaturated everywhere outside of Chrome.