Support for color management

[wilecoyote2015]

Support for color management is provided by the systemd service, which provides a database of Icc profiles and their associations with output devices. See https://www.freedesktop.org/software/colord/

Use Cases Color management is a very crucial aspect of any activities covering graphics and photography. Color management is needed to achive a predictable and consistent color reproduction throughout the production chain from the input device (e.g. a camera) to the display for working on the image and up to the desired output device (e.g. printing).

Overview There are two aspects of icc profiles regarding the display chain:

1. Calibration: Calibration curves are applied to the output in order to align the output response curve to a demanded target response. As far as I know, this task is performed either by X11 or by modifying the configured response curves of the graphics card with X11, but I cannot find usable information about the possible handling in wayland.
2. Profiling: Color managed applications load the corresponding display profile and perform proper color space conversion from their color space into the dislay color space.

Here, Colord acts a persistent database and provides an API for applications (such as X) to get the profiles for recent displays and communiate them towards client applications.

Some general information can be found here: https://displaycal.net/#concept https://wiki.archlinux.org/index.php/ICC_profiles

Current implementations Gnome and KDE provide color management also working with wayland through their own color managers. User information can be found here: https://help.gnome.org/users/gnome-help/stable/color.html.en

According to section "Loading ICC profiles" in https://wiki.archlinux.org/index.php/ICC_profiles, loading ICC profiles for deskop environments not providing color management can be done in X11 using XICCD. I have tested this in sway by first setting the ICC profile in colord for my display using colormgr, and then starting the xiccd daemon. On this way, I can get the calibration part of the color management to work for xwayland-applications like gimp at least. No display calibration can be applied using xiccd. Unfortunately, I have not found useful information regarding implementation details of color management in Gnome and KDE or in Wayland in general yet.

[jypma]

FWIW, I dug up the part weston implements (cms-helper.c), which ends up calling drmModeCrtcSetGamma. That seems to be the key, since ChromeOS's color management apparently relies on it as well. I couldn't find anything further on drmModeCrtcSetGamma, but it seems to be the entry point to the individual xf86 drivers implementing gamma.

It's only gamma curves for R, G and B; I don't know enough about ICC whether that's enough.

[emersion]

Here's the colord implementation: https://github.com/wayland-project/weston/blob/42c0e14808bfd39e1a2eea34f43f0b5fe20fbb16/compositor/cms-colord.c

We already have support for setting gamma ramps. However I'm not sure how this would work with e.g. redshift…

[HeroicKatora]

I'm having quite a bit of a headache on how to correctly support color profiles as an application and WM user. Regarding 2., if I understand correctly, you intend all applications to query the display color space independently from the window manager, then render to some color space it has found. My problem with that approach is this, especially in a multi-display setup:

1. An application may end up spread over different monitors as its final positioning is performed by the window manager. An application rendering with mixed color profiles at the same time is unrealistically difficult.
2. If the color profile information is specific not only to rendering system but also to the actual compositor/window, it is very counter intuitive that rendering as sRGB would yield different colors even on calibrated systems. In case I cannot supports particular WMs simply because I don't know them/there is no budget for such specialization, and I choose to render to the least common denominator sRGB, what reason is there for the WM to assume that I did not render as sRGB when it may know for a fact that the program did not adjust for a particular output.
3. As a pure user, not a developer, it should be possible to correctly display an application that has been coded with no particular support for color profiles. Similar to above, it is unreasonable to expect devs to support any fringe WM. Hence, shouldn't the enduser always have the possibility of making sRGB applications show up correctly? Without affecting other applications that are aware of the output, in particular without configuring global gamma tables or ICCs which should only change when the display hardware or output lightning conditions change?

Without particular pretense on object truth, it is my understand that 1. implies the window manager converting application output to the display color space during compositing, 2. would be possible by asking the particular WM to interpret application framebuffer as a particular color space, and 3. requires it be possible for the user to override that interpretation for example through a window directive in the .config file such as for_window. If those are feasible is another question, for example if kernel drm doesn't support it performant enough, I do not know.

It may be that I have misunderstood the current state of color support available or planned.

[wilecoyote2015]

I found an interesting thread regarding the practical implications and demand of color management in wayland:

https://discuss.pixls.us/t/wayland-color-management/10804

[emersion]

Recently there's been some discussions about this on the wayland-devel mailing list.

Here is a summary: http://www.argyllcms.com/WaylandCM_v1.txt

[akvadrako]

I have just got a new monitor and it really needs custom profile. I was thinking of adding support to sway (or wlroots) but all the proposals I've seen for it are much more complex then I need.

Would there be support for adding something simple like the wlr-gamma-control protocol or just adding a color_profile option to sway output sections?

[emersion]

color_profile option to sway output sections

This sounds like a good idea, but it's not clear what we'd need to do:

• Do we need special shaders?
• How does this interact with existing wlr-gamma-control clients?

[akvadrako]

* Do we need special shaders?

I don't know how special; I will have to do some research on this. Ideally there is a library that already does it.

* How does this interact with existing `wlr-gamma-control` clients?

I would say the effects should stack - gamma control probably being applied after.

[ascent12]

lcms2 is a library related to handling ICC profiles and colour management. I thing you could blend some profile with what a wlr-gamma-control client provides together, and set the gamma property with that. I think shaders only need to get involved when you start taking colour information from normal clients.

[progandy]

Shouldn't atomic DRM be ablet to use three color correction steps, degamma lut -> 3x3 color transformation matrix -> gamma lut?

I would say the effects should stack - gamma control probably being applied after.

If you consider the default color space sRGB, then shouldn't gamma control be applied before transforming it to the monitor colors? In that case maybe use it as degamme instead of gamma when possible.

[akvadrako]

It looks like https://github.com/haasn/libplacebo should be usable to do arbitrary GPU-accelerated transforms between ICC profiles. I suppose this will be a nicer way forward with HDR support in mind.

[debdrup]

As an updater on this, the Weston compositor supports ICC profiles as of Nov 23, 2021. Since then, lots of other commits relating to color management have also been added.

[mberg2007]

It is not immediately clear how those Weston commits support ICC profiles, at least not the first you link to. The other commits seem to show a work in progress with little to no indication of when or how this will become widely available to end users.

Wayland's lack of support for color profiles is frankly baffling to me. Every monitor you buy today supports AdobeRGB or DCI-P3 out of the box and is often enabled by default. I think users expect their system to be able to take advantage of that. Displaying sRGB on those monitors will produce very inaccurate results which will absolutely be problematic for anyone who uses their computer for image manipulation.

[hajosattila]

It is not immediately clear how those Weston commits support ICC profiles, at least not the first you link to. The other commits seem to show a work in progress with little to no indication of when or how this will become widely available to end users.

Wayland's lack of support for color profiles is frankly baffling to me. Every monitor you buy today supports AdobeRGB or DCI-P3 out of the box and is often enabled by default. I think users expect their system to be able to take advantage of that. Displaying sRGB on those monitors will produce very inaccurate results which will absolutely be problematic for anyone who uses their computer for image manipulation.

Unfortunately, this is a serious shortcoming of Sway. For me at least...

[qdii]

I'm not familiar with any of this, but it looks like KWin has implemented it: https://invent.kde.org/plasma/kwin/-/commit/8d25550c2208b19c3cb2de46364a9bbc9678487e

[barolo]

Can we have it fixed? On my OLED screen colors are unbearably saturated if built-in profile isn't used (which plasma can do, as mentioned above). nvm, it's been merged recently for use with vulkan renderer https://github.com/swaywm/sway/pull/7681

[emersion]

Yeah, let's close this since Sway can now load ICC profiles.

[GalaxySnail]

Is it not implemented in the gles2 renderer, or is it simply impossible for the gles2 renderer?

[emersion]

It would be technically possible (perhaps needing GLES3) but not planned.