If I export in darktable my picture to JPG, like:
the result is way less saturated than the dartable preview: left is JPG viewed in Gwenview, right is Darktable:
I don’t think I used anything crazy, except that I am using the recommended filmic rvb node, with scene-related workflow:
I tried to enable/disable high quality sampling, set profile to jpg… not much success so far. What am I missing?
Its hard to say too much from this …if you can at least share the xmp and if possible the source image or a source image that demonstrates what you see that would be great…If your display is not so close to sRGB you might see some difference after export… but its hard to say at this point what the issue is…how are you viewing the result… back in DT or a viewer?? Is the viewer color managed??
Pretty much all such cases turn out to be colour management issues.
Start by running darktable-cmstest from the command line.
Check this recent thread:
Thanks for your answers.
IMG_9138.CR2.xmp (13.4 KB)
I will try to upload the CR2 when I have a better internet connection. Meanwhile, here is the exported file:
I have no idea, how could I check? The name is Gwenview. But I guess there is something weird with color management indeed.
Here we go:
darktable-cmstest version 4.2.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
eDP-1 the X atom and colord returned the same profile
X atom: _ICC_PROFILE (1180 bytes)
description: Latitude 5500
colord: "/home/leo/.local/share/icc/edid-ef1dab9a90d5816caf7e46d1d1bf1b63.icc"
description: Latitude 5500
Your system seems to be correctly configured
So after a bit of tests & tries, here are my experimentations:
No idea why firefox suddently join the other gang…
So can’t I find a setting where all programs kind of agree on the result? The goal is to include the image in some pdf, so I don’t expect people to have configured crazy color managed softwares…
Also, how could I fake the “screenshot” (to allow Gwenviewer to display the same version as darktable) ? I was execting rgb export setting to do the job, but apparently it is not working.
What are your Gwenview settings for the display profile?
When you take a screenshot, what you capture are values sent to the screen (altered using the display profile / LUT). However, if you open the screenshot without tagging it with the display profile, viewers and editors will assume it is in sRGB, leading to colour shifts.
A screenshot loaded into Gimp twice; one I left as ‘sRGB’, to the other I assigned the display profile, then converted to sRGB, and pasted it onto the same canvas as the other:
Since my display’s gamut is somewhat wider than sRGB, the same numbers represent more saturated colours; when interpreted as sRGB, it looks less saturated (like measuring in inches vs centimetres). That is what you can see above. Below is the version where I told Gimp to interpret it as colours in my display’s space (assigned the display profile to it), then converted it to sRGB (maintaining the colours as much as possible, altering the numbers).
Yeah, thanks a lot! I think I finally understood what are these ICC profiles… it’s super easy but I never got this explanation before: an ICC profile just takes a tuple (like RGB = 3 numbers, CMYK = 4 numbers) and turns it into an “absolute color representation” called PCS, that is typically CIEXYZ… or the other way around, i.e. turn an absolute color into a RGB tuple. So you always need 2 ICC profile to display a picture: the profile of the picture itself, that maps the RGB tupples into an absolute color in XYZ (sRGB, aRGB… are all different mappings from the RGB tupple to the XYZ color) , but then you need to turn it back into an RGB tupple since it is what screens understand : the system ICC profile is actually used for that. But contrary to what I was thinking, the system does not perform this conversion directly on the whole screen, as each application draws directly RGB values. It is therefore the rôle of each application to read the RGB tupple from the image, turn it into YXZ using the ICC from the image, turn it back into RGB tupple using the ICC from the system, and then draw on the canvas/screen this RGB tupple. This also explains why screenshots are affected by ICC, since they read the canvas that has already been through the ICC translation.
So I tried to read a bit the code of Gwenview, and indeed they support ICC… and I checked as you shown in the configuration, and indeed there is something to do here: just, I don’t know why, but I have a different last menu:
that translates into “Apply only the ICC profile integrated in the file image”, and the help menu is like “Assumes that the color correction for the whole system applies to the screen profile” (not sure what that means at all). Yet, if I disable it, it seems to fix the image, and now it is displayed like in Darktable! Do you know what is going on here?
Proof:
Before:
After:
(Arg… but now the screenshot is in firefox, I guess because the ICC profile is applied twice, once before taking the screenshot, and one after… I need to understand your trick to undo the ICC profile)
I also tried to find the same setting in Okular without success, I need to investigate.
If you are on Wayland, color management might be an issue. X11 currently works.
I come from Windows and it’s late in the day so I may have missed something in all your explanation… but the system profile is usually just the one set by the OS and all color managed software on your PC should use it unless you specify otherwise and specify an exact one. Generally non color matched software will just default to sRGB. I specify my calibrated display profile everywhere explicitly so I know this is the one being used. DT by default uses system and that should be fine if you have it set properly in the OS at least in Windows. Nevertheless I still add the profile in my config folder and set it manually…in DT and all apps including viewers that I use just to be certain the correct profile is in place…
Hum weird, I am running X11…
But I’ll try to upgrade, seems like new things recently happend here GIT_SILENT Sync po/docbooks with svn · KDE/gwenview@9a7f55d · GitHub
This is definitely a case of wrong/missing/mismatched color profiles.
To better understand all of that, I recommend you read the articles here (starting from the top):
Unrelated to that, I noticed that you use both base curve (courbe de base) and filmic rgb. Don’t do that. DT has three tone mappers: filmic rgb, sigmoid and base curve. You should only ever use one at a time. And if you do use base curve, it should be where filmic is in the pixelpipe. What you do now basically means you are using a (broken) display-referred workflow (without realising it).
Some more about that here:
I recommend you watch this tutorial, to make sure you understand the basics of scene-referred:
Thanks a lot, this is really helpful, I’ll study that. I’m really surprised to see that I got a display-referred workflow, i explitly configured it to use scene-refered workflows by default. Also, how can I know if a module is usable in a worflow? For instance LUT is hidden if i display only scene-refered modules, does it mean that I cannot use it?
The workflow configuration in the settings determines which modules are automatically activated when you open an unedited raw file. But selecting a scene-referred workflow there does not prevent you from using display-referred modules (including basecurve).
Then there are some module layouts provided, accessible through the hamburger menu at the top of the module pane (just below the histogram). Those give you various preconfigured selections of modules, but you still have access to all modules (with a bit more effort).
In short, you can use all modules in all workflows(*).
*: certain combinations of modules may not make sense, like using more than one from [filmic, sigmoid, basecurve]. That said, some use none of those three… There are also some technical limitations, explained in the manual under the module concerned.
That just sets various defaults to be correct for scene-referred editing. You are still free to do whatever you want, darktable won’t stop you.
All modules are usable in scene-referred, as long as you put them in the right part of the pixelpipe. Broadly speaking, modules that are only display-referred must come after the tone mapper (filmic, sigmoid or base curve), while scene-referred modules will generally be placed before, but can also be placed after. There should be more on this topic in the manual.
All modules have a tooltip that will tell you some important technical details:
Just to add to what all the others have shared you will also note bottom right three options for the pipeline… Raw 3.0, legacy and jpg… a forth custom will appear if you move modules around… It can be a visual cue esp if you are working with older edits… I think going back jpg often were not detected and used the raw module order… this is now fixed but old edits might retain that. Also legacy had the base curve early for a true display referred workflow whereas now with the current defaults if you do use it then you should find it later in the pipeline where you would now find sigmoid or filmic… Just one little nuance to go with all the nice explanations provided above…
Thanks a lot for all these advices, it is much clearer.
Ok, so I tried to upgrade Gwenview, and now it is indeed correctly handled out of the box, thanks!
I also tried to open it in Gimp: it was not handled correctly, but it was because it had no monitor profile loaded. So I tried to go to Edit > Preferences > Color management > Monitor profile > Try to use the system monitor profile, and now it works also in Gimp! Similarly, for Krita I needed to go to the parameter, then Color management > Display (second tab, maybe other translation) > Use the monitor profile.
So now, all my softwares can basically print it correctly, except for PDF readers. I don’t know why, but https://www.color.org/version4pdf.pdf seems to be properly read by Okular, but I can’t manage how to load my pictures in Okular. I tried:
to use this image (created via GIMP Image > Color management > Convert to color profile, using the profile listed below):
(that internally uses this profile:
gbr.icc (9.2 KB) )
I then tried to generate a PDF using LaTeX
\documentclass[a4paper]{article}
\usepackage{graphicx}
\usepackage{etoolbox}
\makeatletter
\let\GPT@colorspacefile\ltx@empty
\define@key{Gin}{colorspacefile}{\def\GPT@colorspacefile{#1}}%
\patchcmd\Gread@@pdftex
{\pdfximage\GPT@RuleAttr}
{%
\ifx\GPT@colorspacefile\ltx@empty
\else
\immediate\pdfobj stream attr{/N 4} file{\GPT@colorspacefile}%
\@tempcnta\the\pdflastobj
\fi
\pdfximage\GPT@RuleAttr
\ifx\GPT@colorspacefile\ltx@empty
\else
colorspace \@tempcnta
\fi
}%
{}{}
\makeatother
\begin{document}
\noindent
\includegraphics[width=.5\linewidth]{should_be_blue.jpg}\includegraphics[width=.5\linewidth,colorspacefile={gbr.icc}]{./should_be_blue.jpg}
\end{document}
which gives me this:
testa.pdf (55.1 KB)
See also 192623 – add color management support to Okular while 363631 – ICC profiles not supported? suggests that it should work now… so maybe my pdf is just poorly generated? I followed advices here graphics - How to improve color consistency of bitmap pictures from native format to target pdf file? - TeX - LaTeX Stack Exchange
Ok, so I finally found how to deal with input ICC profiles in pdf (and they do work in okular, evince, acroread and ghostscript, but not in firefox and chromium)… but it seems like neither Okular/Evince or acroread read the monitor ICC profile, hence the image is slightly less saturated. I managed to get this working with ghoscript (if you use nix, you need the ghostscriptX package):
$ gs -sOutputICCProfile=/home/me/.local/share/icc/edid-ef1dab9a90d5816caf7e46d1d1bf1b63.icc demo.pdf
So I guess now it is mostly bug reports to do like here 192623 – add color management support to Okular
Thanks a lot everyone, I think I have no more questions, ICC profiles are much clearer for me now!