Interesting article about the state of color management in Wayland - X11
Debian 12 KDE Plasma: The right GNU/Linux distribution for professional digital painting in 2024. Reasons and complete installation guide.
2 Likes
It is an interesting article. However I think Mint Cinnamon overall is easier to get setup for a photo editing workstation 
Iâve added a short section on the ArgyllCMS home page relating my experiences with Wayland.
10 Likes
I posted your quote to the Fedora KDE Matrix channel and got this reply:
This is quoted from a GNOME Mutter developer who literally doesnât look at how KDE does things. But none of that matters. The only real blocker at this point to color management in Wayland is that no clients implement support for using the protocol.
KWin implements color management: Merge requests ¡ Plasma / KWin ¡ GitLab
And the original merge request that implemented it for Plasma 6 actually includes testing of whitepoint calibration: backends/drm: support applying icc profiles with color management (!4471) ¡ Merge requests ¡ Plasma / KWin ¡ GitLab
So thatâs another perspective. This is getting dizzyingâŚ
Aah the sweet fedora devs, who think color management workflow is on par with X11. They neither own a colorimeter nor do they have any first hand experience in actually working with colour managed application. They only know to perpetuate this falsehood and also give PResque reply when someone tells them the truth.
Here let me give you another proof, here is a blogpost by the kwin dev -
see this line from the blogpost
buy a Colorimeter and profile your display. That costs money though, and the display profiling situation on Linux isnât in great shape at the moment (DisplayCAL on Flathub is 4 years old, my last attempt at building it on Fedora didnât work, and it only works correctly on Xorg atm)
So if you care about color accuracy, this is not a way out of getting a Colorimeter and profiling your displayâŚ
Now tell me are the fedora devs working on colour management that they spread this falsehood or do we believe the actual developers who are working on things?
Yes I agree i have seen that MR they link the person who tested used display cal to calibrate but it is not accurate because there are issues with argyll cms which is used by display cal we canât be sure that the measurement are accurate. Moreover even fedora devs accept there is no implementation on the application side. So knowing this truth why do they spread falsehood like saying it is on par with X11 and then use this to justify dropping X11 without fallback?
So no amount of pointless rebuttal from the fedora team counters the two point that I mentioned in my post above.
Colour profiling and calibration is not ready right now.- All or most apps are now in legacy mode which is sRGB only ( if they blame applications, a user does not care whose fault it is, they need things to work)
1 Like
from graemeâs document:
1) No color management. Either the Wayland server doesn't support
the color management extensions, or the clients wl_output has no output
color profile configured. Client output will be interpreted as
being in the outputs native color space for all outputs and
no color transformations will be performed.
this is actually the mode of operation i would like things to work for my simple end-user application that only applies the output device profile (while waiting for the rest to settle and support to trickle down to all involved libraries, iâll do this myself pleaseandthankyou).
it appears there is a matching vulkan extension supporting colour space VK_COLOR_SPACE_PASS_THROUGH_EXT, which would allow me to signal this without the need for extra support in say SDL or glfw⌠only that there seem to be issues: the lifetime of the annotation is per swapchain in vk and per surface in wayland⌠iâll set the abovementioned colour space in the hope that it doesnât make things worse. i think this means that thereâs hope, but yes, seems there is some work left to do here.
4 Likes
Thatâs it.
Thatâs actually true. I met Sebastian at LGM while I was calibrating the screen for my workshop and he told me that he saw this for the first time.
Well heâs a dev, not a photographer or even interested in art, I think he was sent to LGM by Fedora/Red Hat in order to spread the knowledge about how to implement the communication with the system wide color management engine. Unfortunatelyfew of the graphics devs were there, and he didnât really seem to be interested in the talks of the others.
1 Like
Now tell me why donât these devs reach out to the users? I have even offered to sponsor a colorimeter to the kwin dev but they said their employer can give it to them. None of the wayland devs or fedora devs have sat down with artists or any person related to print design industry. As far as i know they have taken feedback from people in multimedia industry for HDR and other stuff. Now a person who is creating a protocol for users doesnât even know the workflow of the users. Is this the right way?
There have been some complications in communication from the wayland devs and the graphic application developers you can see this in the Wayland colour management MR where krita developer and other have given feedback only to be closed. They have some issue with the so called âtraditional colour management expertsâ it seems. You can read it somewhere in the documentation. Hopefully both side will communicate and solve the issues before all distros jump the wayland bandwagon
1 Like
I tested Displaycal/argyll on Wayland. I mean the newest Python 3 version. Itâs actually Wayland native, and for the most part functional, the only issue is loading calibration curves before profiling.
So profiling only is no problem at all. Creating a profile with calibration curves is a problem.
From what I understand display cal is using hacks to get the data. It will only function properly when there is a mechanism like a portal to get data from the compositor. Till then it will not be perfect. And there are talks to create a new portal for this but that is just talks, who knows when it will be a reality.
Also check this post although it applies to gnome I think it is true on KDE too
1 Like
Actually if I understood Sebastian 's talk correctly, it should also be possible to tag a surface with âdo no color managementâ or 'client does color management â or something like that. The talk is online now, btw, see above.
1 Like
I think I tested this, I think KDE does apply calbration curves if they are in the profile.
I think there is no definitive answer for this. The compositor is supposed to do nothing (although it may do something as there is no guarantee) only if the application tags its window surface the same profile as the display is using. But the application doesnât know what the display profile is by design on wayland so this never happens. That is where this hypothesized portal comes into picture. As far as I know KDSâs kwin may have some mechanism for this now to let the app know about display profile.
But even then there is no guarantee that your colours are not touched by the compositor. You can read this thread in the wayland colour management MR where a Krita devs asks for this specific thing a pass through mode but the discussion is closed.
This all seems hugely ambiguous, one compositor may do one thing other might do other thing it doesnât look anywhere near ready to me.
Yeah but what happens when you want to recalibrate, does kwin allow display cal to reset previous calibration? can you do it manually by removing the profile from the setting?
yes. only that i donât talk to wayland, i talk to glfw. so iâd need to either rewrite everything, dropping support for xorg/windows(/macintosh) or wait for glfw to implement this. talking to vulkan only seems like the more realistic way out here.
2 Likes
I guess Iâve been developing color management SW for too long 
- Iâve accumulated something like 30-40 instruments in that time. It always boggles me that the most active Wayland CM developer seems to have little to no actual experience.
This canât be true. DisplayCAL uses ArgyllCMS to do the work, and ArgyllCMS has no awareness of Wayland. If it goes through the motions, then maybe XWayland is allowing it to happen, but I would have no confidence that a resulting profile will be useful, since the worklflows are at the mercy of the Wayland compositor, and this is likely to get more uncertain as CM code is added to Wayland. (One of the banes of color management is unclear processing of the pixels by applications or display systems.) A very clear understanding of how pixels are processed from application to display is needed by both CM applications and graphic applications for CM to be reliable and successful.
3 Likes
I think thatâs what works at the moment.
2 Likes
That means effectively clipping wide gamut display to sRGB since all xwayland apps are sRGB argyll would have access to only sRGB at the moment, thus ruining your profile.
Well I made another test. Strange thing: apparently Displaycal needs Xwayland to start, but if I type xlsclients into a terminal during profiling, it returns nothing. The funny thing is: I am now using Wayfire, which has those distinct window decorations for apps that are using Xwayland. I see those decorations while starting Dispaycal around the Displaycal logo, but not around the main Displaycal gui or the color swatches.
The profile that is the result of the profiling on Wayland seems to be perfectly usable. I have an AdobeRGB screen and if I use the profile everything looks correct and not oversaturated.
The profile very well might be clipped to sRGB, you wouldnât notice drastic change I think. Our main issue is that we donât have a way to verify things 
1 Like