Yet another Wayland Colour Managment Question

My apologies if this has already been answered elsewhere, there’s a lot of wayland colour management discussion, and I may have missed something.

Is it possible to have accurate colours on a specific display using wayland?

From my understanding, the display “calibration” and display “characterization” are separate, where the calibration is adjusting the RGB sliders for adjusting the white-point and brightness, and creating a VCGT/VideoLUT to made additional adjustments that can be loaded using colord.

A display profile (ICC) contains the VCGT, and the display characterization (TRC, XYZ Matrix), and an application can use the display characterization to apply colour transformations to accurately map colour spaces and to make adjustments for rendering intent.

If this is possible, would I then be able to provide the display’s ICC profile (using DisplayCAL) to the software (rawtherapee) and have the colours display accurately?

Limitations being that this only works for one specific monitor, and only on some supported applications, rather than across the desktop.

I am using Sway as my wayland compositor. Maybe some hacky workaround like launching the wayland compositor as an X client, instead of using DRM

Any guidance is much appreciated, and please do correct any errors or misunderstandings in this post.

1 Like

Wayland has been able to use colord to load an ICC profile for a while.

Its running displaycal under wayland that doesn’t work.

In addition, neither rawtherapee nor darktable have Wayland support yet, they’d be using xwayland. Not sure how that changes things.

Probably a few years until this all settles, if I had to guess.

Is it a valid solution to run DisplayCAL under X to create an ICC profile once in a while and then load this in colord in Wayland?

Would DisplayCAL (if it would run under Wayland) produce a different result than if it runs under X? Does the displayserver have an influence on how colours are produced?

1 Like

Does it not? I ran it just a few days ago (3.9.11) and created a profile which does load just fine in gnome (wayland session). I’ve read a lot of conflicting information but nothing too recent. I’ve also seen that there is another thread about colour managment under wayland which didn’t receive updates in the past few months.

As far as I can tell, displaycal works, setting profiles with colord works (both, copied over from windows and created with displaycal under wayland) and that DT looks about correct. It is hard though to know if everything really works as it should.

Is there any up to date information on how to check if colour management in DT works as it is supposed to? Or, if we want to go further back, is there a way for me to know that displaycal indeed didn’t work as intended as @paperdigits claims? As far as I can tell, the profiles from windows and linux give about the same results and both load just fine.

I tried it a couple off days ago. DisplayCal runs, but didn’t show the colour patch.
So I could not get a profile made in Wayland… I might try another time

I’m on Fedora 38, KDE spin

Well, that definitely worked for me.

I am on Arch and used whatever were the latest versions of gnome/colord/wayland/displaycal available in the official repositories at the time of testing. It’s also worth noting that I am using two screens (laptop+external) and was able to calibrate both with both using different profiles. As stated above, everything seems to work fine.

If it really does and if the profiles are accurate is something I do not know how to ascertain. Things “look” correct and as they do with Windows.

What’s the output of darktable-cmstest?

darktable-cmstest version 4.5.0+727~gc41951c53b
this executable was built with colord support enabled
darktable itself was built with colord support enabled

primary CRTC is at CRTC 0

eDP-1	the X atom and colord returned different profiles
	X atom:	_ICC_PROFILE (0 bytes)
		description: (none)
	colord:	"/home/xxx/.local/share/icc/xxx #1 2023-09-18 20-36 0.3127x 0.329y sRGB F-S XYZLUT+MTX.icc"
		description: xxx #1 2023-09-18 20-36 0.3127x 0.329y sRGB F-S XYZLUT+MTX

Better check your system setup
 - some monitors reported different profiles
You may experience inconsistent color rendition between color managed applications

If you are missing the external monitor I mentioned: it is not currently connected.

The protocols for Wayland have not even been finalized and there isn’t any code for it. Maybe you ran displaycal under xwayland?

How to verify reliably?

Using this method

Launch xeyes and move mouse over a window. If the eyes are moving, it’s an XWayland window, otherwise it’s a native Wayland window.

it seems to me, that displaycal is using wayland. The eyes do not move. They do not move for Firefox either, which I made sure is using wayland. For darktable itself they do move.

Edit: well, could it be that the actual calibration window (i.e. colour patch) uses a different display server? I cannot verify if this is a wayland window too or not since I do not have access to the calibration instrument at the moment. All I can say is that the displaycal main window seems to be using wayland.

If the calibration itself took place using xwayland, what downsides would there be? Whatever it did, it seems to have produced a valid profile.

For some reason DisplayCAL (python-3) wasn’t detecting my i1p3 yesterday when running under sway.

The GUI in displayCAL is wayland native, but colour patch (argyll) is running under XWayland (xeyes test, killing xwayland kills the patch)

Strangely, colormgr get-outputs doesnt return anything, so I dont think that the VCGT is being applied, although maybe I’m using it wrong.

Okay, that’s what I thought. Still not sure what the implications are exactly. So maybe my profile is garbage, even though it looks correct somehow? I don’t have time to investigate further now. Maybe I can try to create a new profile in Windows in the next few days and compare the outputs.

Not knowing what went on exactly and unsure of wether the generated profile is valid or not, I am happy with how things look for now. Before I go on to do some “serious” work, I will investigate further. As I said above, for now things look reasonable the the somewhat greenish tint of my display is gone - just like when I calibrated on Windows.

There is also a open issue on github github which states that VCGTs cannot be (re)set with wayland. Indeed the options are greyed out in displaycal’s GUI. Anyway…more insight is welcome.

1 Like

That its not Wayland. In my own personal experience, the people who advocate for Wayland have been extremely pushy and not very good at listening.

I don’t want a hack stack of xwayland. Wayland doesn’t have a full color management stack yet, thus it isn’t very useful if you’re serious about photo editing.

These are just the facts. Xorg works now and has worked for a while. Is it the future? No. But its certainly the working present.

If that’s OK with you, then go for it. I’ll wait for things to be 100% working. But don’t claim Wayland is ready for this use case. It is not. Any even when it is, there is still quite a bit of software that needs to adapt before the whole stack is ready.

1 Like

I’m not sure if so much bluntness is required. I get it that people keep posting wayland problems when it’s not officially supported by most major photo applications but keeping almost a personal grudge about it doesn’t seem like the way to go… I’ve seen it on other wayland posts too, but never commented.

In the end I’m not sure if we lose more than we gain by having early adopters like this, specially now as wayland is finalizing part of their color management stack. In a way we’ll have a chicken and the egg problem really soon when it comes to photo app developers(and users) being willing to get on wayland so they implement what is required.

2 Likes

running the calibration under xwayland and xorg (openbox) produced the same results.

Of course, the appeal of wayland is not needing to deal a hacky mess like X11, so ideally Xwayland is only temporary.

We need people who simultaneously want to use wayland and want colour management to push change.

“Looks right” is absolutely the wrong way to think about calibration. “Is measureably within the tolerances for accurate color” is much better.

The code says that it can only be set with colord, but I can’t seem to figure out how to get colord to list my outputs.

I’ve personally had too many encounters with the Wayland crew saying its time to leave Xorg and Wayland is ready for my use case. But it isn’t. Is that being too blunt?

Sure when its ready with a full color management stack and the downstream software like DT and rt have worked out the kinks, I’m sure it’ll be great. Wayland has a lot of great features… But its not ready and I have photos to edit now. I’m glad you’ve picked up on my frustrations on being told what I should use on my computer and what my needs for a specific stack are, because, I am, in fact, very frustrated by this.

You can compound this frustration because the Wayland people will start sliding the goalposts backward, “oh um well you can load an ICC profile, that’s good enough.” And if that’s good enough for you, that’s great, go for it.

Keep in mind this has been happening for years. I’m glad that Wayland is getting there now, and I’ll be happy to switch. But that doesn’t erase this frustration.

2 Likes

No, that’s fine and it’s the truth.

I didn’t mean it with ill intention, just that these users in particular might not even be part of the “wayland crowd” and just regular folk who happen to use it, without being apologists (I’ve seen those, maybe not here yet but on other forums). Your frustration is completely valid, specially as a mod/someone who has to provide support often.

I didn’t take it with I’ll intent and didn’t take the other post with I’ll intent either. I hope my frustrations aren’t off putting.

We do need to test when Wayland compositors start landing these features. However, right now they’re adding API to the spec.

1 Like