Wayland color management

Software
709

But well, redhat wanted to implement hdr support and the kids (all those wayland devs are/were actually kids, like around 20) that were hired realized that color management is a requirement for hdr.

Meanwhile most things are working. If you install KDE Plasma 6, you can set profiles for different screens etc. Loading calibration cureves works, too. It’s an actual system wide color management. Desktop icons are not oversaturated etc. The only thing that does not work yet is the communication between the clients and the color management engine. And of course there is no properly working calibration/profiling software.

2 Likes
710

As of right now Wayland has way better support for displays with mixed pixel density and scaling than X11 ever had though.

1 Like
711

I think one main reason for the communication difficulties between wayland devs and artists/graphics devs is the fact that they don’t know and meet each other in person. It’s a real pity that few devs were present at LGM2024. The organizers do reimburse at least the flights and the train/bus rides. It would have been interesting to listen to different opinions about wayland color management.

3 Likes
712

I too wish this communication gap was solved. May be redhat or some other org can host a sprint with both the side in one place. And wish both side listened to the problems as well as solutions from each other’s perspective.

They do have hackfests every now and then, but it is not done along with the application developers.

1 Like
713

As someone who co-founded an open source project (the AOSP derivative OmniRom, I’m now LONG retired) consisting primarily of volunteers, and more importantly, mostly younger volunters, spread across nearly every timezone - a systems architect/systems engineer/developer (a lot of the problems here are less bad development practices than bad systems architecture/systems engineering practices…) who needs in-person communication is a deficient one.

Developer conferences like the Big Android BBQ (BABBQ) were nice for the Android community, but not necessary. The problem is that for many people, there’s more issue than the flights - there’s the issue of vacation time. When I went to the BABBQ for 2-3 years, the problem for me was not the cost of the flights, rental car (not necessary, but I decided to splurge on my second and third years), or hotels, but the precious limited amount of vacation days I had to spend.

3 Likes
714

That’s just a sign that the project is not important enough for you. Or you don’t know your priorities.

But I also disagree about in person meetings.

715

This seems unnecessarily harsh. We yanks general have two weeks a year off. If you spend a week at some conference, that’s pretty much all ya got.

6 Likes
716

Agreed. Even for an european with our mostly 4 weeks per year(depending on the country) who has the time to spend even 3 or 4 days on a trip to a conference for a project that doesn’t go farther than being a hobbie? Between family, using vacation days for “housekeeping” and other things, it goes by very quickly and it’s a valuable resource.

I’d bet most people who attend those conferences do so because it’s part of their work, not a personal project.

5 Likes
717

Hi all, KWin developer here. This is quite the long thread… Let me add even more!

The color management protocol is IMO pretty close to being in a state where it can be merged; my goal is to finally get it merged in the next few months and ship it in Plasma 6.2. If there’s anyone in here that’s interested in pushing it forward, we already have two compositors implementing it, but if you implement it for any application that does color management, it would help a lot. For testing app side implementations, Plasma 6.0+ ships with an implementation of a tag of the protocol that’s supported if you set the KWIN_ENABLE_XX_COLOR_MANAGEMENT=1 environment variable for KWin.

If there’s any authors of applications that won’t be ported to be Wayland native any time soon, we can make (specifically, bigger than sRGB gamut) color management work with apps running through Xwayland too, as long as the app adds support for some custom X11 atoms on their windows. If you want to go down that route, please talk to me! The KWin side wouldn’t be too complicated to implement at least…

For the profiling part, that is indeed still a big issue, but @betazoid is right, if DisplayCAL / ArgyllCMS didn’t try to set calibration curves, the resulting profile should be correct - as long as the user makes sure HDR isn’t used, no ICC profile is set in the system settings, night light and similar effects aren’t active, all surfaces effectively get pass-through to the display. Last time I tested this, IIRC it seemed to assume it could apply a gamma 0.95 calibration curve, so the result was incorrect.

Mind you, that has been a while ago and with possibly messed up settings. I’ll try again with an up to date DisplayCAL very soon; if someone here already knows where that default calibration curve might’ve come from or how to make sure it doesn’t do that, I’d be happy about some pointers in the right direction :slight_smile:

As far as my understanding of the calibration curves goes, they don’t appear to make any sense in a full color managed system - their inverse gets baked into the TRC of the profile, so when KWin applies the profile, it just ends up not doing anything at all. If that’s incorrect, please someone correct me.

In total, all that would be necessary for DisplayCal to be a pretty good experience on Wayland with minimal effort would be to make sure it doesn’t try to apply any calibration curves (and ideally hide the relevant UI from the user), and to have some integration with the compositor to un-set the active ICC profile, night light and similar. For the latter, if anyone wants to make that happen, I’d be more than happy to type up a small Wayland protocol and the implementation in KWin for that purpose.

8 Likes
718

How is that working with multiple displays ?

i.e. how does your renderer know to apply the correct destination profile for pixels intended for each different display ?

This is outlined here. To re-phrase it in a little more detail:

  1. Per channel curves can improve color profile quality by making the display better behaved. Per channel display behavior can be characterized in a lot more detail than 3D space, simply because of sampling density. It is also a very important way of setting HDR display response.

  2. Typically the per channel lookups increase color depth, thereby allowing more precise setting of the luminance response. i.e. 8 bit per component frame buffer feeding a 10/12/14/16 bit out, thereby reducing visible banding. This is really important to graphic arts users, and even more so when the display has an expanded luminance range such as HDR.

  3. Many displays have no easily accessible and reproducible way of setting white point, black point and brightness. Setting per channel calibration curves is a universal mechanism for providing this. Not supporting this is a regression on current color management capabilities.

2 Likes
719

Displaycal depends on argyll cms for showing colour patches which means argyll cms would run in xwayland mode. I guess argyll cms would need changes to show correct patches not clipped to sRGB?

720

Welcome @Zamundaaa, great to see you here! Now I don’t have to be the end user messenger between developer camps. :wink:
Just noticed you have a blog where you write about color management developments. Perhaps people here would be interested in that.

4 Likes
721

If there’s any authors of applications that won’t be ported to be Wayland native any time soon, we can make (specifically, bigger than sRGB gamut) color management work with apps running through Xwayland too, as long as the app adds support for some custom X11 atoms on their windows. If you want to go down that route, please talk to me! The KWin side wouldn’t be too complicated to implement at least…

2 Likes
722

These are the settings for skipping calibration curves, if I understood the question/problem correctly:

displaycal1
displaycal11920×1200 1.73 MB

And in this dialogue, you just do nothing an click on continue to profiling:

displaycal2
displaycal21920×1200 2.02 MB

1 Like
723

Clipping to srgb only occurs if system wide color management is on. If it’s off, i.e. no profile set in KDE Plasma 6 or Gnome, there is no clipping. At least according to my tests and experience. And if I understood you correctly.

Edit: And there is no clipping/color management for xwayland apps anyway, if no profile is set for xwayland with dispwin or so.

1 Like
724

i.e. how does your renderer know to apply the correct destination profile for pixels intended for each different display ?

It doesn’t. When you don’t have any color management features enabled for a display, KWin just assumes it’s sRGB. It also assumes Xwayland windows are sRGB, so no color transformation happens.

Per channel curves can improve color profile quality by making the display better behaved. Per channel display behavior can be characterized in a lot more detail than 3D space, simply because of sampling density. It is also a very important way of setting HDR display response

Typically the per channel lookups increase color depth, thereby allowing more precise setting of the luminance response. i.e. 8 bit per component frame buffer feeding a 10/12/14/16 bit out, thereby reducing visible banding. This is really important to graphic arts users, and even more so when the display has an expanded luminance range such as HDR

Yes, but you only need the TRC for that, not the VCGT, right?

Many displays have no easily accessible and reproducible way of setting white point, black point and brightness. Setting per channel calibration curves is a universal mechanism for providing this. Not supporting this is a regression on current color management capabilities

Ah. I was thinking of adjustments in the EOTF, which is the use case someone told me was broken by the full color management system, but it makes sense that it would work for the whitepoint and brightness… the TRC are normalized after all.

As a follow up question, is that still needed with a full color management system, which allows you to set whitepoint and brightness directly, outside of the profile? I can’t think of any downsides of doing it that way atm, but maybe I’m overlooking something. (to be clear, I don’t have whitepoint adjustment implemented yet aside from night light, but it would be trivial to do so)

As a follow up to the follow up, does anyone use a different white point per display, or would you always use the same on all displays? I would imagine that having a different one could be problematic, as you’d be constantly adapting between the different whitepoints.

3 Likes
725

I think my last comment also explains this

1 Like
726

First of all let me thank you for giving us your time and creating account and offering us your help in understanding stuff and also for clearing our doubts. I missed saying this in my first comment. I am very happy that you are here.

So on a fresh system (with a wide gamut monitor example adobe rgb) argyll cms which shows the colour patches on screen for measurement and profiling is shown as sRGB. So the colours in the patches are limited to sRGB? Sorry for repeat question but I wanted to clarify this. As @betazoid says it is not clipped but you say that it assumes xwayland apps are sRGB. So I am confused.

I do not use different white point while profiling and calibrating. However some might use it depending on the use of that particular monitor, for example one monitor can be used for doing colour critical work and other for browsing web etc.

1 Like
727

Thank you, I appreciate it. I hope we can get some productive results here :slight_smile:

It’s important here to distinguish between what the individual components think about the colorspace, and what they actually are.

KWin, with no color management information from apps, and no color management information set for the output, doesn’t know any color spaces. It just takes image data in some unknown encoding from applications, and copies it to the image in some unknown encoding to the output.

The internal color management system can’t work with “unknown” though, it has to have some numbers. For those numbers it uses sRGB (or to be more precise, rec.709 with gamma 2.2 TF) as a placeholder, which works well for “not color managed apps” on wide color gamut displays, but it also works for profiling, where argyllcms outputs colors encoded in the unknown display color space.

If both input and output color spaces are “unknown” / sRGB, or really any arbitrary colorspace, as long as it’s the same, the conversation between them is an identity matrix and KWin does nothing at all with the colors. This is exactly what we want for profiling: unknown in → unknown out, without any transformations in between.

5 Likes
728

So when argyll cms runs through Xwayland (or natively on wayland in future) it needs to set its window in the colour space of the display then kwin doesn’t do anything in between. Do we need to set anything before running displaycal or argyll cms to have it match the display color space. Or by default it works out of the box like this.