Windows 10, Darktable 4.4.2
PC: Intel® Core™ i7-4510U CPU @ 2.00GHz 2.60 GHz with 8,00 GB RAM
GPU: NVIDIA GeForce GTX 850M
I removed the darktablerc, so that darktable created a new one. Now the problem changed in the sense that the clipping indication is the same whether OpenCl is on or off. But the clipping indication seems to be wrong since a completely black chest of drawers should not have clipped highlights. See screen shot below.
According to the documentation darktable’s default setting for “opencl_device_priority” is */!0,*/*/*
but darktable created: opencl_device_priority=*/!0,*/*/*/!0,*.
What is your histogram profile set to?? This controls the result to an extent…Your display profile also can in some cases… There are ways to walk through that to see if it plays a role…
The histogram profile is set to sRGB(web-safe) but the result is the same if it’s set to system display profile. The display profile is set to system display profile.
@kofa Is right. The clipping indication is caused by out-of-gamut colors.
DT has a problem… the display profile is in the wrong place and can clip the data before it gets to the histogram profile where clipping is assessed… you can see this by just changing your display profile …of course the image will look bad on the screen but clipping should not change ie data should not be run through it … you can see that it does impact it…just change the display profile and to varying degrees depending on the profile the clipping will change… the real test of clipping is to set the display profile as wide as possible and to be the same as the histogram profile… so something like linear rec2020 for display, working and histogram… the image will not look good on the screen but clipping will be more accurate… if you have no clipping in this space then there is no lost data going to the output profile and it will be mapped to the capabilities and colorspace of that profile… for DT the default is perceptual srgb. The default DT srgb profile cannot do relative rendering… I replaced it with a profile from color.org to allow me to do relative renders when I so choose…
I guess its hard to say but best to start with the ground truth and then tweak that setting… So for us as well that all have different display adapters setting it as noted above will have us all working on the same math with the same xmp. At least that would be my thought. Then, I think most modules have a cpu and opencl pathway so it might not even 100% be opencl vs no but what modules… So repeating with different modules might change the result. In the example provided by the OP they also chose to use sRGB for the histogram profile so it would show that there is some gamut clipping as well as exposure… changing to rec2020 shows the gamut intact before processing and only some under and overexposure which was mostly added by the processing modules chosen and I didn’t see much difference between opencl and no on my system. Then you get into what DT will show on the screen which will be different perhaps than the exported result which uses a different pipeline… So do you export with and without opencl and then bring them back in and check for differences or dif blend them in GIMP??
Though not related to your original issue: opencl_device_priority defines for which pipelines (processing sequences) darktable will use the GPU (or which GPU it will use, in case there are more than one). For details, see darktable uses CPU instead of GPU - #12 by kofa.
I have never changed the histogram profile, so why is it not set to rec2020?
If the information is stored in darktablerc then the default histogram profile is wrong since I just removed the darktablerc and a new one was created. If it’s stored somewhere else then past upgrades of darktable has not corrected the histogram profile to the new standard.
Yes I did mean that… I don’t think DT offers rec2020…you can get rec709 and linear 709 in the default install I think but only linear rec2020 unless you add that non linear profile yourself…
As for the setting people do switch it around… one use is to set it to linear rec2020 and monitor the data in that space. The idea being that you are working in the wide space and monitoring how your edit is distributed in that space. You might choose an output in a smaller gamut but that is handled and mapped by the output profile to complete color management. There maybe be times when you want to see how the gamut is looking in a lower color space. With all the profiles DT uses it could be easy to toggle one and not notice which one you did… unless its the display profile as nothing will usually change visually… so no idea if it is set to something different than expected??
Yep as I clarified a couple of comments above… I have meant linear when I said that… I had not originally said that explicitly as "linear: rec2020 as it is the only profile provided in that color space by default unless you go out and add a gamma version of rec2020 yourself… so I think it was pretty clear and not sure what your screen shot adds unless I am missing something??
