I am trying to figure out where a bug lies in my color management workflow. I am running PopOS 22.04, DarkTable 5.2.1 (Flatpak) and GIMP 2.10.30 (.deb). My two monitors are calibrated, and the better monitor (P3 color) is set as the default system profile.
My color settings work perfectly in DarkTable > Web (sRGB), and to various viewers. However, I cannot get reliable color when opening a file in GIMP. It is very close, but slightly flatter in terms of contrast and with less saturated color.
My default is to process using the scene-referred workflow in DarkTable, save as a 16bit linear ProPhotoRGB TIFF set to relative colormetric. I have tried perceptual, Rec 709 RGB, keeping the built in profile, converting to GIMP linear sRGB. The results are always the same.
If I try to “assign” or “convert to” profile once inside GIMP, everything goes out the window and the results are terrible.
If I process the file in GIMP and bring it back to DarkTable then I get an even much more contrasty and colorful version that bears no resemblance to the original nor the intermediate version.
To me it seems as if the image is being displayed as sRGB no matter what options I select (once again: converting or keeping profile, enabling/disabling black point compensation seem to have no visible effect).
I ran darktable-cmstest and the only hiccup is the following (I don’t know how to add the X Atom):
HDMI-1-0 the X atom and colord returned different profiles
X atom: _ICC_PROFILE_1 (0 bytes)
description: (none)
colord: "/home/eric/.local/share/icc/Monitor_1_#1_2025-08-02_16-03_2.2_F-S_XYZLUT+MTX.icc"
description: Monitor_1_#1_2025-08-02_16-03_2.2_F-S_XYZLUT+MTX
Does anyone recognize these issues? Any recommendations as to where I can look to find a solution?
Copyright (c) 2008, Sandy McGuffog. Some rights reserved…This work is licensed under the Creative Commons Attribution-Share Alike 3.0 United States License. To view a copy of this license, visit Deed - Attribution-ShareAlike 3.0 United States - Creative Commons or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.
Example above saved with GIMP built-in linear sRGB profile.
I am unsure if my suggestion will be of any help but if moving from DT to GIMP I would use the 32 bit floating point XCF export option in DT rather than a tiff file.
Yes - provided that the working space is in linear floating point mode.
I can not list them (not allowed to quote AI) but there is nothing to stop you asking “in the GIMP editor, are there any specific scene-referred tools?” outside of this site. Your call …
I also don’t 100 follow what you are comparing…in DT you do your edit and export to srgb…DT profiles don’t support rendering intents so you can ignore that part…so you that is a file saved as 8 bit with the srgb transfer curve…rec709 has a slightly different gamma and at one time so did prophoto but still are you saying that if you export your linear tiff to Gimp so that shouldn’t come into play if things are kept straight…open that and then export from GIMP back to sRGB that it is not the same as DT exported as sRGB??
Are you sure that both have access to and are using the same profiles as well… If you can I would explicitly specify them in both DT and GIMP ie your display profile and the profiles that you are using for any exports or reassigned colorspaces on input??
But as I said I am just missing something as to the nature of what you are comparing as you present a bunch of options
I don’t’ think this really has much to do with it…I think there might be a glitch in the color management between the two software and or the way linear profiles are being used and then compared to srgb output… some clarity on things might inform that…
For example went the OP says its like everything is treated as if srgb that sometimes means that the embedded profile is not recognized by a software and so it strips or defaults to srgb…in any case are you clear what final images are not matching??
I just mean that I don’t think this is a “scene referred” issue. I think its going to prove to be some combination of a profile issue at some point in the workflow or the configuration of the software
At the time of the original post, I meant that on screen appearance of the image in Darktable vs GIMP isn’t exactly the same. Close but not exactly identical.
I’m using a large colorspace workflow as the images are to be saved as archival master versions. The only reason to detour into gimp in this case is for retouching. I don’t want tone or color to change during this round trip into gimp before going back into Darktable.
All that being said, I now think opening in gimp introduces a scene- to display-referred conversion that I can’t control and need to figure out how to manage or bypass.
Thanks, noted. I will experiment tomorrow with D50 G1.8 and also load the flatpak version of gimp so I can access the enhanced color management capabilities of version 3.
Thanks for the update…I would assume what you see is the data processed by the display profile if color management is work. If you have DT in a linear prophoto working profile (though I would keep it at rec2020) and then export that in linear prophoto you should have a no-op data transfer from DT to your output (ie no colorspace conversion)… Viewing that in Gimp processed by the same display profile as DT should look the same I would think.
If you share a raw …it could be a throw away and an xmp to see just what edits you are doing someone could try to replicate it
I think I recall at one point that Andy was mixing linear and gamma prophoto until he noticed during some workflows when he first started working with DT…so it might be good to get a second set of eyes just to check everything
Why do you use that profile for your monitor…does it not have one…sometimes the black point is managed in a set way…that is just an srgb profile from color.org?? Just curious on that decision?? I mean in the end if your monitor is close to sRGB it likely won’t matter too much but in the absence of a calibrated profile I would think the next best option is the icc provided for the monitor by the manufacturer??
I took 2 images one being a test image color chart from dpreview …lots of colors and detail and colors in blocks…
I took DT and just nothing but export it as an uncompressed 16 bit tiff with linear prophoto.
I imported them back in to DT and checked against the original and they seemed similar to me…
Then I opened the Tiff in GIMP 3.02 or whatever I currently have. I kept the profile and tried with and without black point compensation as that can if the profile supports it make things less contrasted as it lifts the blacks in a manner of speaking …
My DT background is the light gray and GIMP was a little darker but opening both to 100% and moving the screen around to make them as similar as possible I toggled back and forth between DT and GIMP and to me they didn’t look much different…
Depending on the image and the modules there could be one thing to double check…
If you do your exports with HQR set to yes then be sure that you preview in DT with that preview on as well. And the reverse. This slows down the preview and it is off by default…intermingling of these modes has in some cases in the past caused some users to notice a difference…the default preview esp zoomed out to full screen can seem a bit more contrasted when using the downsampled data than it does when you activate the HQ preview … these are the modes activated in the lower right part of the status bar…
You could just check that but over all I did not experience a noticable difference. I could split color patches in the colorchecker with snapshots and it would be no different to my eye in color/contrast/brightness between the edit and the tiff export…
I run Win 11 and I manually specify my calibrated profile in both Gimp and DT and this ensures the display is being processed the same way in both apps…
I am not sure any of this helps but I can’t replicate what you are seeing at least in the 2 or 3 images I tried…
