using darktable in Wayland with color management?

I understand there are currently unresolved, but work-in-progress fixes to issues with Wayland (Wayland color management) but at least on GNOME with Wayland, there is color management with profiling and everything. And darktable runs in XWayland anyway, right? So it’s in X in Wayland. And there are ways of manually selecting a profile in darkable too.

I’ve been running in X for a while due to darktable and color management, but there are just other issues with X that Wayland solves. (Wayland has smoother performance, supports HiDPI, supports mixed DPI with monitors, fixes some security issues in X (where every app can interact with every other), and so on…)

Anyway, back to a theoretical possible way to have Wayland and color management in darktable.

darktable-cmstest returns:

darktable-cmstest version 3.1.0+2516~gcf9a63c47-dirty
this executable was built with colord support enabled
darktable itself was built with colord support enabled

couldn't locate primary CRTC!

XWAYLAND0	the X atom and colord returned the same profile
	X atom:	_ICC_PROFILE (0 bytes)
		description: (none)
	colord:	"(none)"
		description: (file not found)

Better check your system setup
 - some monitors lacked a profile
You may experience inconsistent color rendition between color managed applications

But I do have a color profile applied in Wayland in GNOME.


(I did have additional profiles at some point, but removed them when I made new ones. I didn’t skip from 2018 to 2020 without profiling. Or have such big gaps between those shown. :wink:)

So then I dug around a bit and found references in the documentation of darktable @ https://darktable.gitlab.io/doc/en/lighttable_chapter.html#lighttable_overview which mentions ICC profiles in $HOME/.config/darktable/color/out — and that directory didn’t exist locally.

As colord is on my system and working in Wayland (but apparently doesn’t pass information through XWayland, if I’m understanding the output darktable-cmstest properly)… I had the idea of doing a symlink from the ICC directory GNOME’s color settings use via colord. ln -s ~/.local/share/icc ~/.config/darktable/color/out — and sure enough, after starting up darktable after that, I can see the profile ICCs in the little monitor icon in the lighttable. So I set it to the same ICC as my display.

Does this work? How can I check? Things “look” “correct”, but just looking “correct” defeats the purpose of profiling.

Can someone let me know if this is a way to use color profiling on Wayland, or if any step is wrong?

Or if it’s just currently impossible to use profiled colors on Wayland (and then I guess I have to go back to X and have to put up with my laptop being halfway broken when I want to do dual-monitor setups).

Yes setting a manual profile and making sure that the calibrations from that profile are applied to the screen should (still[1]) work (I don’t know if gnome under wayland applies the calibrations should be findable in the code though). There are 3 issues with this though

  1. It is somewhat inconvenient for the end user, the current sollutions for X11 work because an application knows on what screens it is outputting. An application on wayland might know in which output region it is but such an output region might go to multiple screens (or even be partial overlapping) so doesn’t know which output it is on
  2. large gamut displays are becoming more common and so we want full screen color management[2] and thus also a way for applications to tell if they are doing their own color management (or if not in sRGB in which color space they are) become necessary
  3. At least for gnome the provided calibration tool is fairly minimal and support is needed for other more feature full calibration tools, due to how wayland works the compositor needs to be involved in this, meaning a protocol is needed

Conclusion yes it is possible to use profiles under wayland (theoretically at least) but it is neither convenient and some features are missing that currently are available under X11. (Also we really want to get it right this time since although it works it is not the cleanest way of doing it under X)


[1] This is how it used to be under X before the color management X atom spec and colord
[2] Artist who know what is going on can probably live with user interface color being total out of whack so long as the images they are working on are correct, but is not really nice for a more normal user

1 Like

Nice! Glad to know this is a work-around that can work for me for the time being. (And for others who really want something working right now and know how to manually set this up.)

I did some texts with exported JPEGs side-by-side with darktable, and things did look exactly the same color-wise, so I figured it was probably working. Super happy to have a confirmation that this should actually work. (Thanks, @dutch_wolf!!!)

The color profile I made was not actually done via GNOME’s color management setting, but with DisplayCal on Fedora 31 in a toolbox on Fedora 32 (to work-around the lack of Python 2 in Fedora 32). More info in this thread: DisplayCAL and Fedora 32. Wacky, right?

But, yeah, this all feels like a stack of cards just be able to run a modern distro with Wayland to have things work. (At least on my very nice, but standard display.)

For everyone who doesn’t want to jump through hoops, keep using X for now, I guess?

Looking forward to the eventual progress where everything works by default again, in Wayland.

Yeah pretty much.