I read this in the manual and honestly I have never scene something like this in any other software,
From the manual >histogram profile>Set the color profile of the histogram.**
“None of the available options are ideal, however, “system display profile” is probably the least bad setting, since all other profiles are derived from the display color space and at least the values will conform to what you see on screen”.
Is there a question here or is this a general comment?
I don’t know, it seems rather obvious to me. Why does the manual suggest using system display profile profile as the best option?
@paperdigits Below is what I wrote to Mike in a private conversation – I am a long-time darktable user, but I don’t know what the current status of the histogram and the colour picker are. Are they influenced by the output and display profile, for example? I think they are influenced by the soft-proofing profile, if the mode is active, but I’m not sure.
What I know is that in darktable, at least at some point in time, the histogram and the colour picker were not quite valid; I do not know if this has been resolved. The reason is that (as far as I know, but I’m not sure) you have the following transformation:
working space (e.g. Rec2020) → output space (e.g. sRGB) → display space (display specific)
This is then complicated further by the soft proofing. If I remember correctly, the colour picker and the histogram used to depend on what was actually sent to the display – so, if your output/display profile was smaller than your histogram space, it would show the ranges as not fully utilised.
Because it’s what you’re looking at… ??
There are a couple of other threads but this is one of the base ones that has quite a bit of the original issue with the pipeline…
I think you can see if your display profile is an issue if you set everything to linear rec 2020 so you have a pass through … you can use this to check gamut and to check picker values…
If you toggle your display profile with rec2020 for a display profile and the values change then it is problematic for gamut and picker values due to the pixel pipe… if not you are okay for the most part…
I think when you hit soft proofing the colorspace of the softproofing profile is substituted for the histogram profile for the histogram and picker values… THis is why you can see the histogram change and not the display often…
The gamut warnings are different depending on these profiles as well in the case where you set them differently… If you use the gamut warning tool it will use the current softproofing profile to calculate gamut. If you use the gamut by setting the overexposure to full gamut it uses the histogram profile.
I believe AP has attacked this issue in his fork as part of his slash and burn…
I think there may still be issues I am like you not 100% sure it has been addressed … I think as long as your display profile is well behaved you are okay. I think the DT profiles are unbounded and so they don’t cause issues but other ones introduced might so you have to check…
But why should I care how my display profile mangles the data that will be in my output file?
I think it makes sense to be able to display the histogram from before the output profile (so I can check what’s in my pipeline), and also from after the output profile (so I can check what is sent to my output), but involving the display is just weird, I think.
I agree, I prefer to see the histograms of intermediate results, lets me gauge the extent of damage occurring in a particular operation.
Thing is, if all one is concerned about is the final render, or the software doesn’t want to implement the complexity of moving the histogram around in the workflow, hard-coding it to the final render is the least confusing thing to do…
