https://bugs.kde.org/show_bug.cgi?id=478139
Bug ID: 478139
Summary: The status of color management under Plasma 6 +
Wayland
Classification: Plasma
Product: kwin
Version: 5.90.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: compositing
Assignee: kwin-bugs-n...@kde.org
Reporter: adam.m.fontenot+...@gmail.com
Target Milestone: ---
Created attachment 163931
--> https://bugs.kde.org/attachment.cgi?id=163931&action=edit
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
--
You are receiving this mail because:
You are watching all bug changes.
