I have raw landscape image taken just after sunset. When opened in Linux version of dt 3.6.1 the ‘land’ part of the landscape is really dark. The histogram extends to about 70% (missing the right hand end). I cannot alter the exposure value to anything higher then -0.1 EV without the clipping indicator showing a lot of red. Transferring the RAF.xmp file to my Windows install of dt 3.6.1 allows me to increase the exposure to at least 0.95 EV without any clipping, at which point it looks about right for an image taken at that time.
you can’t clip by raising exposure… at least in scene referred … just a nitpick
it might very well be that the clipping settings are different . You can right-click the clipping toggles to get a little menu with settings and thresholds . I would first check that these are the same .
indeed, color management in play. A default color profile on your display (you might not even know about , they are preinstalled on laptops sometimes for instance). I don’t know if this actually affects the read out (or if it should ) but it might be an explanation .
you can’t clip by raising exposure… at least in scene referred … just a nitpick
[/quote/
Nobody told my Linux install about this rule, so it is ignored/
Identical.
This can make such a big difference? See following (1st image is Windows version)
Exposure on Windows version can be increased to 1.74 EV without clipping; it must be decreased to -1.04EV on Linux version to prevent clipping, at which point most of the image is black. Can a colour profile make that much difference (2.8EV) ?
I don’t believe so: there are no styles defined for the Windows installation. None have been applied - that I know of - to the Linux install. How do I check ‘automatic’ application of modules or styles?
Further information: the clipping is essentially removed in the Linux install if I reset the exposure module. After this I can increase the exposure setting to 1.26EV without clipping showing, by which point the image is clearly viewable and is basis for detailed editing of the image.
So what has been going on here, in the Linux install? i.e. what did the reset actually reset?
It seems to me in the Linux instance there are more modules applied (in particular, color calibration).
It may well be that some modules in the settings are applied by default.
As noted above, the clipping is due to other modules, not by the exposure alone.
One setting difference I’d check between the two: go in the preferences (e.g. click on the gear in the lighttable view), then under “processing” tab, check the “auto-apply chromatic adaptation defaults”. It could be that in Windows it’s set to “legacy” and in Linux to “modern”, for instance.
The histogram is the same in both images, but in the Windows screenshot it is stretched so it looks different. The exposure looks similar, the black clipping indicator is different.
I would
check if the input color profile is the same for both, maybe even reset the module
check all the toggles on the bottom-right for their settings. Not just clipping settings, but also soft-proofing, gamut warning etc. Are they the same for both?
check if the system display profile is the same (although it shouldn’t cause this)
Try setting your display profile to srgb for both or be sure to use the same icc for both…DT has an issue that doesn’t really appear if profiles are unbounded but it runs data from the working profile through the display profile then to the histogram and this is used for the clipping…so if you have an issue with a display profile it can affect things ie the data going to the histogram…usually its minor but since you are in different OS maybe the display drivers are quite different??
Otherwise, create a xmp file drom both Linux and windows and share them so we can have a look.
In your screenshots you are searching for modules in the one, and showing active modules in the other. So I can’t see if the processing is the same in both .
From the info I have, I am stumped :). But I hope it’s something simple .
To see “true” clipping in DT it must be tweaked …there are other threads and some discussion on the Git forum but not for some time…it is explained in one way here… @LateJunction try setting both OS with this configuration and see where you stand… https://github.com/darktable-org/darktable/pull/8051
Thanks for this link. In my usual fashion my inability to sensibly parse complex documents means that I have understood at least 5% of it, happily enough for me to discern one important clue - a revelation almost: that the clipping indicator is invoked by both luminance and gamut conditions. Up to now I had thought that the indicator was linked to solely to luminance issues. However, indeed, the user manual corrects my mis-conception: “…From darktable 3.4 onwards, the clipping warning indicator has some additional modes to help you to differentiate between luminance and gamut clipping, so that you can make better decisions about how to address any issues…”
Sadly, my acknowledged condition, of being unable to adequately parse sentences which have been crafted in a certain style, leaves me unable to appreciate the significance of this statement. What is a ‘mode’? Where are these modes exhibited? What precisely do they signify, such that I can deduce some appropriate corrective editing actions? None of this is explicitly stated, in the user guide, for us intellectual ‘slow developers’.
Anyway, the clue is that the clipping indicator doesn’t just show issues with luminance - which goes a very long way to explaining to me why my image, when viewed under Linux, was extremely dark, but at the same time was (supposedly) luminance clipped. Subsequently, my proven method of problem solving (stumble around, click buttons at random, rage at the world, use intemperate language, make unsubstantiated allegations about the documented relationship between the parents of the code creators or the manual authors - etc. You know - the typical unsuitable user reaction stuff) answered most of these not-so-difficult questions. I now know that all the red was caused by saturation clipping - almost certainly caused by my decision to set my camera to use Velvia film simulation The mere act of opening the color balance rgb module fixed it…
Now the only problem I am left with is: why? Why does the problem show in the linux version but not in the Windows version, when they are set to the same clipping indicator mode and the same pixel pipe line? And I guess that the answer must lie in the above responses to my original post
Well, that opened up another opportunity for embarrassment: my first reaction to this advice was to ask how the same icc can be used for these two install when they are using vastly different monitors, from different manufacturers, using very different technology (one designed in about 2003, the other about 2013). I decided to demonstrate this by just checking which iccs were in use: they WERE the same, both set to use the icc for the very old monitor. I corrected that (on the Windows machine) and, of course, it made no difference, since the problem was on the linux machine.
Both are set to use Linear Rec2020. I tried SRGB on the linux machine; the images looked awful so I reverted to Linear REC2020.
