Created attachment 163931 [details] Plasma 6 Color Management Status Board 2023-12-05 INTRODUCTION This is going to be a very broad bug report, which is necessary given the incomplete state of color management work for Plasma 6. I'm going to be highlighting a number of issues I've encountered in testing the Plasma 6 beta. Individual issues can be spun out from this as needed or upon request. I'm hoping this report will help coordinate efforts around color management under KDE + Wayland. I can test changes on calibrated WCG and HDR screens, and update the status board I've included here. OVERVIEW If you're familiar with color management on Linux, skip this section. Linux color management, in the traditional SDR + X11 world, comes in two pieces. There is a gamut mapping piece, and a gamma / white balance / grey balance adjustment piece. A calibrated device profile (*.icc, *.icm) contains information about both - a display characterization that applications can use to map managed colors into the display gamut along with a LUT that allows the display to hit a particular gamma and color target. Traditionally, colord was at the heart of this process. Colord loaded the LUT into the video card gamma tables (VCGT), making this part of the color correction process the responsibility of the graphics driver (hopefully offloaded to hardware). Colord is also a daemon that applications talk to in order to receive the display profile for their current screen. Applications that did so managed their own colors. Applications that did not had unmanaged colors (though they still benefited from the corrections applied via the VCGT). Under Wayland, most compositors (including KWin) want to have control over the process. As I understand it, the current plan for KWin is to have the compositor apply both halves of color management itself. Rather than offloading the gamma ramsp in the display profile to the VCGT, these are applied in the compositor for each screen. Likewise, Wayland supporting applications are supposed to communicate with the compositor (via a brand new protocol) to tell it what intermediate profile they are targeting, which is then mapped by the compositor into the display space. This has several advantages: applications not supporting color management can be assumed to be sRGB, so they will finally look right. And applications should now be properly color-managed on multi-monitor setups, without any finicky hacks by the application to switch profiles dynamically. PLASMA 6 BETA STATUS Please refer to the attached status board I've put together showing everything I've been able to test, as well as stuff that I currently haven't been able to test. The overall situation looks like this for the core features: ✅ KWin appears to handle the loading of ICC profiles on a per-display basis, and applies the gamma curves within those profiles. I have not verified that it does so correctly. ✅ KWin appears to apply color corrections to unmanaged applications, and assumes sRGB -> display is the correct mapping for this. As a result of this, previously unmanaged applications and the Plasma desktop itself look correct. (At present, this might be implemented as a hack by mapping the entire screen at once. If so this means that any form of color management for applications is unsupported.) ❌ Legacy applications are broken at present. Even with the colord daemon running, `colormgr get-devices` returns no devices when running under Plasma 6. (The Color Management KCM is also missing, that's Bug 477083). ❌ KWin incorrectly maps legacy color managed applications from sRGB into the display space. This is almost certainly the biggest color management issue with respect to the upcoming release, because it represents a major regression of the situation under X11. Graphics artists, photographers, and others working with materials outside the sRGB space will need to avoid the Wayland release unless this is fixed. ❓The Wayland color management protocol is still a work in process (and unmerged). I believe KWin is implementing a draft version of it. Because it's so new, I was not able to find programs that advertise support for it. Therefore I was unable to test a major aspect of recent color management work: the ability of Wayland apps to tag windows with an appropriate intermediate color space and have the compositor manage the colors on those windows for them. ❓Likewise, it's not clear whether Wayland-aware applications are currently able to request direct access to the display space. One would expect, at the very least, full screen applications (e.g. games) to be able to request that the compositor avoid potential sources of latency like color management. (There are other more narrow use cases for this as well.) HDR SUPPORT ✅ KWin + Plasma 6 beta correctly activates HDR mode (when enabled) on an HDR display, and tonemaps SDR content as expected. ❓Unfortunately, I don't know of any applications that currently support the Wayland protocols necessary to inform the compositor that their windows are HDR tagged (e.g. P3-D65 + PQ), so I haven't been able to test that. All windows are SDR-only and tonemapped when HDR mode is enabled. OPEN QUESTIONS * The overwhelming majority of color managed applications on Linux are what I called "legacy applications", meaning they support mapping colors into the display space themselves, but have no means of communicating this to the compositor (that I know of). Even if 100% of color management issues in KDE are fixed prior to the release of Plasma 6, most applications are still going to be legacy, which means they need to be supported. How will KWin distinguish "unmanaged" applications (which need to be mapped from sRGB to display space) from "legacy managed" applications, which *must not* be mapped? Does xwayland throw an additional wrench into this? * What is the future of colord under Wayland? If it's kept around (which is probably necessary because of e.g. printers and scanners), it needs to be Wayland-aware, and not try to load gamma curves under compositors like KWin. * What is the level of precision at which these gamut mapping processes occur? The Wayland approach introduces another layer (the "intermediate" gamut that application windows use), and there's a risk of banding with repeated operations if windows are only drawn at 8 or 10 bits of precision. The traditional approach has the advantage that mapping from image-native space to display-native space happens in a single transformation. USEFUL LINKS https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/winsys_color_pipeline.rst https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
Thanks for taking an interest and testing it! > Legacy applications are broken at present. Even with the colord daemon running, `colormgr get-devices` returns no devices when running under Plasma 6 That's intentional. There's no way to know which apps use the icc profile from colord (or which icc profile!), and which don't use it. With colord not exposing anything for the displays and there not being any X11 root window to load an icc profile from, they should all use sRGB instead of whatever is set in colord, and that we can work with. We can put something together for X11 apps, so that they can opt into at least arbitrary primaries + gamma 2.2 or sRGB, but they'll still have to be updated to make that happen, so idk how much that would be used. > KWin incorrectly maps legacy color managed applications from sRGB into the display space Legacy color management apps don't have an icc profile, so they'll target sRGB. If they have internal settings to choose some profile, please make a bug report to the relevant applications so that they disable that on Wayland until they can actually support that. > Likewise, it's not clear whether Wayland-aware applications are currently able to request direct access to the display space. One would expect, at the very least, full screen applications (e.g. games) to be able to request that the compositor avoid potential sources of latency like color management. (There are other more narrow use cases for this as well.) That is intentionally not supported. Apps will be able to target whatever colorspace they want, including one the compositor deems ideal (at least in KWin's case that would be the display's primaries + transfer function), but they cannot get any "direct access" or "pass-through". It's up to the compositor to know which processing steps are expensive and which aren't, and to set the preferred colorspace accordingly. > Unfortunately, I don't know of any applications that currently support the Wayland protocols necessary to inform the compositor that their windows are HDR tagged (e.g. P3-D65 + PQ), so I haven't been able to test that. All windows are SDR-only and tonemapped when HDR mode is enabled. If you install https://github.com/Zamundaaa/VK_hdr_layer, Wayland native Vulkan apps that have ENABLE_HDR_WSI=1 set can do rec.2020 and scRGB. Gamescope can use it, Quake II RTX can use it, and I've been told that mpv with the right flags can do it too. > How will KWin distinguish "unmanaged" applications (which need to be mapped from sRGB to display space) from "legacy managed" applications, which *must not* be mapped? Does xwayland throw an additional wrench into this? It can't. Xwayland doesn't help nor cause problems with that, it's X11 itself that's the problem, as apps never needed to or had any way to communicate what their colors actually mean. Like mentioned before, we could put something together to make that happen, but apps wil still need to add new code for that. > What is the future of colord under Wayland? colord may continue to exist, but it has nothing to do with the windowing system anymore. > If it's kept around (which is probably necessary because of e.g. printers and scanners), it needs to be Wayland-aware, and not try to load gamma curves under compositors like KWin Only the compositor can set GPU state like "gamma" curves, colord was never able to do that. The VCGT of the selected icc profile only did something because KWin loaded it from the profile. > What is the level of precision at which these gamut mapping processes occur? The calculations happen with 32 bit floats on all GPUs that aren't from the stone age, and probably with many of those too. Let's please continue this at https://invent.kde.org/plasma/kwin/-/issues/11 though, bugzilla isn't too great for things like this.