The Plasma 6.2 beta notes has two color management bullets:
- Turned on support for KWin’s implementation of the Wayland color management protocol Feature Discuss
- Option to use color profile data built into your monitor, if it has one
Can you explain how/if the first one relates to the discussion in this thread @Zamundaaa?
Not directly related but quite adjacent. It seems like Valve has become tired of waiting for protocols to be merged so they can implement them in gamescope. I wonder if this will set the wheels rolling a bit faster when it comes to protocol discussions.
It’s quite absurd how for example, a window icon protocol has been in the works for 9 months! Seems like the developers are aiming for perfection instead of near perfection, but this slows down things too much.
One wonders if we will reach a time where when a protocol is finished it won’t even be worth implementing since everyone else has moved on to something else(their own implementation, creating fragmentation). This is not a case of lack of contributors, I don’t want people to think I’m an ingrate. I’m thankful for all the work done but it’s simply the culture of the project.
For those of you using KDE, there is a new version of the UI available.
It supposedly implements colour management in Wayland.
EDIT: There is a complete list of changes on this page
6.2 was pushed to Fedora stable. That was quick.
I think I just found a “bug” in wayland color management: if you are using wayland, at the moment the best strategy is to profile only and let the app such as darktable do the color management, since no graphics program can yet communicate with the wayland color management engine. However, if you also need calibration curves, because e.g. your laptop screen has a color cast and it’s not possible to fix the color cast with the osd of the screen, at the moment there is on way to apply the calibration curves only in wayland, and let darktable do the rest.
I think it is better to report these bugs . Also we can ask @Zamundaaa about these
@Zamundaaa I think the best default setting for now would be “let the app do color management” (instead of “assume srgb”) so the desktop etc. (which is not color managed on x11) is color managed. As long as there are no apps that can communicate with the wayland color management protocol. Or maybe there is a possibility to exclude apps such as darktable, krita etc. (that can do color management on their own) from kde plasma/wayland system wide color management?
I recently switched to Kubuntu 24.10 and tried Waynland because I am curious if it makes any difference to me for my daily work. So far I don’t really see a significant difference or benefits.
However I would like to understand the colour management situation a bit better. In particular because Plasma 6 allows me to select a colour profile. I read a few articles and wonder if my conclusion that Waynland supports color management, but there has to be some work done on the software side to make it work is correct? Otherwise Waynland will assume sRGB input?
Things are changing fast and that makes the situation somewhat unclear to me.
I have 2 questions at the moment:
Would full support mean, that DT has to be Waynland native?
Is it correct, that if I set the output profile in DT to sRGB colour management works within the limitations of the colour space?
Looking forward for some “dehaze”.
BR, Till
Edit: Is there any image viewer that fully supports Waynland Color Management?
Perhaps when Kubuntu 26.04 comes out, Wayland will be feature complete and fully support colour management! 
Selecting and applying a color profile is the easy part of color management. We still need to be able to run the calibration tools to generate the profile.
Yes. Darktable has hard dependencies on x11 right now.
Displaycal/argyll runs well with xwayland. The only thing that does not work is creating a profile that includes calibration curves, but that’s not recommended anyway.
I heard that onKDE plasma the problem that graphics apps cannot communicate with the wayland color management engine will be solved soon. According to my sources graphics apps such as darktable that can do color management themselves will be excluded from system wide color management. Haven’t found the pull request yet though.
Works well with xwayland.
Yeah but I’d hardly call that “working in Wayland.” If it has to use an X emulated mode, I’d rather just use X.
Thanks for you answers, I think, that X11 is the better choice for now. It seems there are too many pitfalls. Let’s see how long the mainstream distros will support it.
XWayland is not an emulation, it’s an X Server running inside wayland for that window only, for all purposes it’s as “native” as if you were using it on X11.
Fair point, but not what I’d call “working in Wayland” still.
Well during the next few years a lot of apps will use xwayland. And x11 will be removed sooner than you think.
Question from a simple user: after updating to Ubuntu 24.10 DT and digikam did not start with x11 any more. In Wayland they started right away. Do I have to assume that DT is using xWayland? Very confusing situation for a normal user.
For me both work fine X11 and Waynland. For DT I use the Ubuntu version installed via apt and for Digikam I use the AppImage. How did you install the programs (apt, flatpak,…)?
I don´t remember exactly. I usually install by apt. Is there a way to find out how it was installed?
You could try 'sudo apt remove’, start typing darktable and hit Tab, if it appears then I think it’s apt installed (or ‘apt install darktable’ and see if it prompts you to confirm download size). Or for flatpack see installed packages