Hi,
I have a problem with the clipping indicator. With darktable version 3.3.0~git2068.f4196e9bc (and 3.3.0~git2055.73c5fda61) when I enable the clipping indicator the whole image is “blue”.
It’s not normal and I don’t reproduce so I suspect it’s hardware/platform-related. What is your OS and how did you get dt ? Also, what is your working RGB profile (setting in input color profile) ?
I’m on Manjaro with kernel “5.4.80-2-MANJARO”. I installed dt from git, the issue occurs also with OpenCl disabled.
The input color profile is “enhanced color matrix”, histogram profile “system display profile”
Might this issue be related to my icc profile?
In the shell, where I start dt I get the message:
" dt_ioppr_set_pipe_output_profile_info] unsupported output profile 0 /home/marco/.config/darktable/color/out/CS230 #1 2020-11-25 18-20 2.2 M XYZLUT+MTX.icc, it will be replaced with sRGB" several times…
Same here, if I run DT from shell I get this message:
“unsupported output profile 0 /home/pippo/.config/darktable/color/out/UP2716D #1 2020-06-13 16-54 100cdm² D6500 S XYZLUT+MTX.icc, it will be replaced with sRGB”
darktable can’t use LUT-based profiles internally. Also there is no reason to use them outside of display profiles. Working profile and histogram profile should either be standard RGB space (built-in), or matrix + gamma or matrix + 3D TRC profiles.
Also, XYZ LUT profiles are a bad idea generally. They are theoretically more accurate, but also more prone to artifacts (like banding and losses of gradients), and need to be used for the exact same backlighting intensity as the one used during profile generation, or they will fail. Let me tell you that, in practice, they harm more than they cure.
Just use matrix + 3 curves, it’s more than enough.
The message is new but the fact has been there forever: LUT-based profiles have never been supported in the pipeline. They are handled through LCMS2 only for display and export in output color profile module, which is super slow. In the pipeline, for intermediate computations, profiles are handled internally using OpenCL if available but LUT are not supported because we simply don’t have code for that.
Thanks @anon41087856!
I think you just answered my question that I had not yet asked
Color of my prints differ to colors of the screen. But I could not figure out why, as everything seemed to be installed correctly…
Even darktable_cmtest stated “Your system seems to be correctly configured”
I’m still a bit confused… I have “use LCMS” ticked in preferences, so from what you’ve said, it sounds like a LUT profile should be ok providing it’s used only in the output module. (I don’t know whether the profile has a LUT or not, I’m assuming for now it does)
I started using the profile from the ICC website because I had doubts about the output processing. If I remember ok, I couldn’t get to see any difference between perceptual rendering and relative c. for example, with LCMS, when using sRGB websafe. But the “ICC preference perceptual” DID give a difference between the intents.
Also the “unsupported profile” message is a little suspect - it’s being produced merely by being present in history. That is, the offending profile was set, then I put output profile to “sRGB websafe”, but I still get the message.
Anyway, onto more exciting things i.e. your colour checker feature!
@anon41087856, dt has been supporting my use of the ICC’s “preference perceptual intent” profile in the output color profile module, this is confirmed by loading jpegs into GIMP which then shows the embedded profile and asks if you want to change it.
Recent dt builds now produce the error message (in Terminal window) noted above, but having just done the GIMP test, these jpegs are also showing that the “preference perceptual intent” profile is present, despite the error message.
So it looks like the message is surplus to requirements.
There are a couple of places where darktable uses the display profile to adapt some GUI colors without a LittleCMS fallback, for performance. LUT profiles are not supported. So these GUI color-managed widgets will default to sRGB and launch a warning about the profile not being supported. That’s not blocking and the output file will have the right profile no matter what.