color management / different profiles returned by darktable-cmstest etc

[aadm (Alessandro Amato del Monte (aadm))]

I know that this is something that has been discussed before but I’m unable to find the solution.

Sidenote: this may be something new since my update to Ubuntu 22.04, I don’t think I’ve noticed this before… I may be wrong about that and simply did not notice it before.

So the problem is this, that darktable-cmstest returns this message:

(base) aadm@psion:~ $ darktable-cmstest 
darktable-cmstest version 4.0.0
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
CRTC for screen 0 CRTC 4 has no mode or no output, skipping
CRTC for screen 0 CRTC 5 has no mode or no output, skipping
CRTC for screen 0 CRTC 6 has no mode or no output, skipping

DP-0	the X atom and colord returned different profiles
	X atom:	_ICC_PROFILE (724 bytes)
		description: sRGB built-in
	colord:	"/home/aadm/.local/share/icc/SW2700 #1 2022-12-15 10-00 120cdm² D6500 2.2 F-S XYZLUT+MTX.icc"
		description: SW2700 #1 2022-12-15 10-00 120cdm2 D6500 2.2 F-S XYZLUT+MTX

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

As you see I have a profile calculated with displayCAL (the fork by @eoyilmaz, compiled from source), and it looks like this is correctly “loaded” into the system.

First of all I don’t properly understand X atom and colord, I’ve understood they’re two different tools to “load” the profile into the system and you have the option to choose which one to use in prefs/“miscellaneous”/“interface” section/“ (and I’ve deliberately set "method to use for getting the display profile” → “colord” intead of “all” since colord sees the correct profile).

Anyway I would have happily disregarded the above msg but when I run dt (or ansel) I see these msg when opening an image in the darkroom:

(base) aadm@psion:~ $ ansel
[get_output_profile] called with ICC type -1
[colorspaces] Trying to fetch embedded profile.
image 56154
embedded color profile NOT found
embedded matrix NOT found
[colorspaces] could not fetch the profile.
[colorspaces] WARNING: no colorspace found, sRGB will be tagged in final exported file. Colors may be inconsistent

Can anybody pls tell me if this is a problem, how can I check if an exported image is properly “calibrated”, i.e. what color profile it’s been assigned / if sRGB is indeed what I should aim for when I send for example this photo to an outside printing service or to share with others, how to make “X atom” load the same profile that colord sees, etc

(I know it’s a lot of things and probably confused and surely many of you will send me back to some earlier post that I’ve probably read but haven’t realized its pertinence to my question etc…)

Disclaimer: I have read (as suggested by @claes) the section “Loading The Profile In Your User Session” in https://encrypted.pcode.nl/blog/2013/11/24/display-color-profiling-on-linux/ but really I don’t understand how to do that, check if this is already present in my system, what is xiccd, etc…

Disclaimer bis: I have also read lots of other threads as mentioned above!

[rvietor]

As I read those error messages, ansel is complaining about the absence of a color profile embedded in the image you are loading. That shouldn’t be a problem in itself. And it has nothing to do with your system setup.

Of course, if this is an image that was exported by dt/ansel, you may have had a problem with the export…

I’m not sure about the X atom/colord issue. As I understand it, the X atom is just a way to store the filename of the display profile to use. colord is doing the actual color correction, and it seems to use the correct profile…

One thing to keep in mind is that we are talking about completely different types of files here:

• The output of darktable_cmstest is concerned with display (device) profiles, which are used to correct for rendering errors of your display. Such profiles should never be embedded in an image file…
• the message from ansel concerns a colour space description (sRGB, Rec2020, …), telling the program how the colours in the loaded file are encoded. And it is good practice to always have the proper colour space information in your image files (either the name of a standard colour space, or the full definition). But many programs assume sRGB if there’s no colour space information in the file.

I know, both files have an .icc extension…

[danny]

@aadm

First of all I don’t properly understand X atom and colord, I’ve understood they’re two different tools to “load” the profile into the system and you have the option to choose which one to use in prefs/“miscellaneous”/“interface” section/“ (and I’ve deliberately set "method to use for getting the display profile” → “colord” intead of “all” since colord sees the correct profile).

This should be ok then for darktable, however other sw may use x atom profile and show different result. E.g. in kde plasma changing profile in the color correction settings sets it for both x atom and colord. I’m not sure how gnome handles it tho.

[aadm (Alessandro Amato del Monte (aadm))]

Thanks @rvietor for all the infos. To be honest this following bit was obscure to me so very useful clarification:

@rvietor

One thing to keep in mind is that we are talking about completely different types of files here:

• The output of darktable_cmstest is concerned with display (device) profiles, […]
• the message from ansel concerns a colour space description (sRGB, Rec2020, …), […]

Also:

@rvietor

Of course, if this is an image that was exported by dt/ansel, you may have had a problem with the export…

…are you suggesting then to simply export a photo from dt/ansel and re-import it to see if everything’s alright? I mean these errors come up with all the photos that are simple straight import from my cameras.

I’ll have to check then if my exported photos are seen correctly elsewhere e.g. on other computers etc. I guess I will have to read back this thread here because it is this very issue that’s been discussed.

About my system, I will gladly wait for any further clarification on how to set up “X atom” (and what is it etc).

PS: thanks to @danny too for the reply

[gwgill (Graeme W. Gill)]

@rvietor

I’m not sure about the X atom/colord issue. As I understand it, the X atom is just a way to store the filename of the display profile to use. colord is doing the actual color correction, and it seems to use the correct profile…

The X atom has the actual profile in it. It’s a simple way for the application to know what to convert to when it does the color management.
Note that colord doesn’t actually do any color management - that’s an application thing, since the application is rendering the images.
Complicating things is which element is setting up the per channel calibration curves. Usually something has to get the curves from the display profile’s ‘vcgt’ tag and send them to the graphics card hardware. That could be colord, or could be something else such as dispwin, Xcalib etc., depending on how things have been setup on your system.

[Peter]

Same issue here. The problem started when I updated to Ubuntu 22.04.

The problem is that when I export to sRGB everything gets oversaturated on everything else than darktable. If I want things to work, I need to set sRGB as display profile.

Another thing is that if I don’t use LittleCMS 2 in the settings, everything goes dark if I use display profile from the system or if I use my own profile DEL2023.icm

A third thing is that the preview doesn’t work. If I want to preview from my system profile to sRGB, nothing happens, but it works if I preview a printer profile.

I use X11 and not Wayland.