I guess today’s bug day :-). I just noticed that some old photos look quite different in terms of color when seen within darktable and exported in jpg. Here’s an example (left side: darktable view, right side: exported jpg):
I haven’t seen this before, and I have been using dt for a few years now. I am on an Intel MacBook Pro (Sonoma 14.3.1), using the latest stable dt binary (4.6.1). The monitor is a BenQ, not calibrated but has always given me good results and good match with the macbook screen.
So, right-clicking on the softproof icon, I get this:
In the MacBook display setting, I set the color profile for the laptop screen as “Display P3”, because that’s what Apple specifies for this laptop; I also set the color profile for the external display (a BenQ SW240), again as “Display P3” from the same MacOs settings.
On the BenQ hardware itself, however, using its own hardware keys, I set the “Color Mode” as “Adobe RGB” instead of “DCI-P3”, as this combination is the one that produces a visually identical output color-wise on the laptop screen and on the external BenQ.
Do you see anything wrong with this? I add that if I set the Color Mode of the BenQ to sRGB, using its hardware keys, I still don’t see within darktable the same colors that I see in the exported jpegs (and furthermore colors will then look different on the BenQ and on the laptop screen).
That’s what I found to produce identical (to my eye) color rendering:
on the MacOs settings dialog box: “Display P3” for both the laptop screen and the BenQ
using the BenQ hardware keys: select “Adobe RGB”
However, I was a bit puzzled as to why I shouldn’t select “DCI-P3” with the BenQ hardware keys: is it because DCI-P3 is actually not the same as “Display P3”?
No, it’s because every screen has it’s own color profile - either use the one coming from the manufacturer, or calibrate it and make one yourself.
Just because the spec say “supports 99.9% of Display P3” doesn’t mean it actually is exactly Display P3 - it could e.g. be even larger in two corners and just miss that 0.1% in a third one…
So, the issue seems to be again opencl related. If I disable opencl, the colors of the exported jpeg look fine (but exporting takes a much longer time).
I am attaching here the logs of -d common, with and without opencl enabled, in case that may be useful in spotting the bug.
What would be useful is to find the module that is causing this. Just disable modules one by one until you find the culprit. If any modules does this, it may be an issue with the OpenCL driver. But we’ll see. When you have gathered the information please open an issue in the project’s GitHub here:
Indeed, the culprit is the Diffuse or Sharpen module, specifically the “local contrast” preset. Removing it makes the colors right. Interestingly enough, that seems to be also the cause of the other exporting issue I posted in the other thread, namely the jpeg resulting in a striped image.
I will open an issue on GitHub, thanks for the advice.
Not to be contrarian, but I’ve used that module quite a bit, including the local contrast preset and I’ve always found the exported JPEG to render to the identical colors from the file under edit, when viewed from within Darktable.
I have had a problem where Firefox displays JPEGs as darker and more saturated than the same file in DT, but that seems to be an color management issue within Firefox that I may have finally resolved.
Maybe you could share the file from your screenshot above along with your XMP?
I can’t reproduce this or the other issue noted by the Macos user either…personally I always found the local contrast preset very subtle and I often even bumped it with more iterations
When I upgraded from 4.4.2 to 4.6.1, I encountered a very noticeable delay when going into culling mode. It took 1-2 seconds before the images were displayed where previously it was almost instantaneous.
On a hunch that it was rendering-related, I deleted the precompiled OpenCL binaries in my cache and relaunched darktable so it would recompile them. There was no longer any delay in culling mode rendering after that.
I’d recommend first backing up your dt cache directory ( $HOME/.cache/darktable/), deleting the OpenCL cache directory (on my M2 system it’s named cached_v3_kernels_for_AppleAppleM2Pro_1210) and relaunching dt and see if your issue still persists.
Hi, I have pretty much the same problem (not as pronounced though) and it seems to be the Haze removal module that causes issues for me (negative strength, drawn and parametric mask).
The module does not behave well with OpenCL either (there are often artifacts on the bottom long edge), although OpenCL is not an issue here.
