I have calibrated my display and have an ICC profile. Been using it for a long time, it just works (with colour managed apps that use it, off course).
I run darktable-cmstest and see that the X atom reports a different icc profile than colord. (I don’t think this matters, darktable happily picks up the colord profile). In any case, I use ‘dispwin’ to set the X atom and darktable-cmstest lists the same icc profile and reports everything seems to be fine.
So far so good.
Now I am using the flatpak version of darktable, been using it for many months. It has been quite the learning curve using flatpaks, I posted here a while back about not being able to use LUA scripts for things like integration with GIMP or HUGIN. By the by, I now have another issue/question.
Is the flatpak version of darktable colour managed?
I now recently learned how to run a command within a flatpak sandbox, so I run darktable-cmstest like this:
flatpak run command=darktable-cmstest org.darktable.Darktable
Here is the output:
darktable-cmstest version 5.0.1
this executable was built with colord support enabled
darktable itself was built with colord support enabled
primary CRTC is at CRTC 0
CRTC for screen 0 CRTC 1 has no mode or no output, skipping
CRTC for screen 0 CRTC 2 has no mode or no output, skipping
CRTC for screen 0 CRTC 3 has no mode or no output, skipping
DVI-D-0 the X atom and colord returned different profiles
X atom: _ICC_PROFILE (724 bytes)
description: sRGB built-in
colord: "(none)"
description: (file not found)
Better check your system setup
- some monitors reported different profiles
You may experience inconsistent color rendition between color managed applications
Does the flatpak version of darktable have working colour management? Do I need to colour manage differently with the flatpak version?
As far as I know, the flatpak is the same code, but packaged differently. Of course it’s possible that the packager has disabled colour management, that should be checked with your source for the flatpak.
But your output shows:
this executable was built with colord support enabled
darktable itself was built with colord support enabled
and
CRTC for screen 0 CRTC 1 has no mode or no output, skipping
It’s possible that the flatpak doesn’t have access to (some of) the required files or hardware. That seems to be a recurrent problem with (darktable) flatpaks…
I suspect you might be right. I have flatseal installed which enables configuration of flatpak access permissions but I am no expert with this either.
When I set the display profile within the gnome desktop, I see a visual change to colours. When I set the display icc profile within darktable (via the soft proof option) I see a visual change to colours. (The BRG test icc profile is good for this).
Does this indicate that it is colour managed, it just can’t query the OS icc profile so it has to be set manually?
I have often wondered why deb packages arn’t just regularly updated, for manual installation. What with snap, flatpak, deb and appimage the Ubuntu user experience can be a challenge sometimes.
Roger that, makes sense. No doubt the exact issue that flatpaks are trying to overcome.
I do dual boot (multi boot actually), I became a bit handy with grub a few years ago for a project in work. I wonder if I should just run a seperate install of Ubuntu and keep it updated to all the interim releases, specifically for my photo work. I might look into that.
After very bad experiences with snap, AppImage & Co., I am taking a different approach:
use (predominantly) Ubuntu LTS versions
exclusively use Debian packages, installed/managed with dpkg, apt or compile/build myself locally
snap, AppImage & Co. are banned from the system, including snaps that come with the standard installation of Ubuntu
Mixing different package formats that are managed by different tools you should not be surprised when problems with unresolvable dependencies or missing functionality arise sooner or later.
Many thanks. I have compiled programs before, this all looks familiar. What I was pleasantly surprised to see is that there is a simple build script that can be run. That’s nice.
They also give instructions on how to run a test version alongside a main version (basically installing to a different folder and disabling xmp creation) so looks easy enough to compile and run multiple versions. That’s also nice.
I don’t really want to update from 22.04 just yet, as apart from my flatpak woes it is just working for me without any major issues at all. I am tentatively confident that this will resolve my frustrations, including the LUA scripts working again. It never occured to me to compile from source, I just jumped straight to flatpak.
I compiled from source, was easy enough once I figured out how to specify the compiler version to use. I just needed to export it as a session variable.
The next problem is that Hugin isn’t available in the Ubuntu 22.04 repos, so I am still stuck with having to use that as a flatpak. Compiling that from source looks quite a task.
I think the sensible thing to do at this stage is to upgrade to Ubuntu 24.04, still compile Darktable from source (24.04 has DT v4.6 in the repos) and install Hugin from the repos. That will get me back on track without needing any Flatpaks.