darktable
darktable copied to clipboard
darktable-org
raw over exposed indication broken
Describe the bug/issue The raw over exposed indication with its default settings does not mark the whole areas that are over exposed but its edges only.
To Reproduce See sample zipped arw file. nosky.zip
Screenshot with default settings
Expected behavior
Screenshot with threshold 0.99
Which commit introduced the error I saw it with 4.0 release first.
Platform
- darktable version : 4.0.0-1
- OS : 5.15.53-2-lts
- Linux - Distro : arch
- Memory : 8G
- Graphics card : GeForce GT 730
- Graphics driver : nvidia-470xx-dkms 470.129.06-1
- OpenCL installed : opencl-nvidia-470xx 470.129.06-1
- OpenCL activated : yes
- Xorg : xorg-server 21.1.3-7
- Desktop : plasma
I think this just wrong white point setting so probably no bug. Arw files are notorious for that...
Additional comment: The raw files include a 'white-point' defining the maximum processed value. That value is read from exif data by the rawspeed decoders.
If that value is wrong, clipped data are not calculated as clipped so the clipped visualizing is wrong. That's exactly what you see here, so for me not a bug in the mentioned part of the code. It might be reported as a rawspeed bug or as only some cameras / images are affected a sony firmware problem. (Sony raw are notorious for that, it also leads to problems handling highlights btw)
@jenshannoschwalm Thank you very much for the explanation. Actually it looks like the value is not read from exif but is the same as the default value in the cameras.xml from rawspeed.
find . -type f -name "*.ARW" -exec exiftool -WhiteLevel {} \; | sort | uniq -c
2380 White Level : 15360 15360 15360
The white point in the cameras.xml/that dt uses is 16383.
So - why not "dig into this" deeper and try to fix it. I have not seen pr's by you so far but this might be a starting point to contribute to the dt project :-) And - it would help many Sony users :-)
So - why not "dig into this" deeper and try to fix it. I have not seen pr's by you so far but this might be a starting point to contribute to the dt project :-) And - it would help many Sony users :-)
I am. I try to figure out how to make sure the proprietary values parsed by exiftools are reliable enough to fix it that way in rawspeed.
@TurboGit You want to close this issue? (Because you added it to the milestone)
A quick reminder, we will need to take care of old edits somehow. That might be a bit tricky as we have to make dt aware of other coeffs here. Don't know how to make sure about this but we will find a way :-) Good to see someone working on this nasty thing.
I hoped that dt would keep the settings of the raw b/wp module and sets the value only on import or history reset.
I skimmed over some issues from rawspeed and some code from other raw software. I think one needs to inspect a variety of raw files shot with different settings first. It smells like there are more factors than just ISO that influence the black and white points. E.g. as I mentioned in chat the other day, the A6400 likes to switch between 12 and 14 bit with different settings.
isn't whitelevel saved in rawprepare iop params for old edits?
Yes, you're right @parafin those are saved so we can safely change the value which will be used for new edits or if the history stack is reset.
@TurboGit You want to close this issue? (Because you added it to the milestone)
Not sure to understand. I did add a milestone to have a target release for the fix. The issue will be closed only if we decide to take no action or if a fix is merged.
@TurboGit @aurelienpierre and others. There is definitely a problem in current whitepoint setting, don't yet understand the issue exactly. So far we thought it was some sony stuff, here is a link to a canon image issue, same probem.
https://discuss.pixls.us/t/highlight-reconstruction-darktable-vs-rawtherapee/31790/7
I think this is an issue we have to fix asap.
can this be related to moving away from adobe coeffs?
EDIT: a first lookup shows colordata.cpp to contain a maximum value (whitepoint?) If we use that data, are we sure that rawprepare takes parameters in the same way as rawprepare uses them?
I further checked the mentioned cr2 file and also here the whitepoint is simply wrong. dt uses 15831 instead of what exiftool says
Normal White Level : 11767
Specular White Level : 12279
The uploaded Sony raw contains two different White Level tags :
exiftool -H -G -a nosky.ARW | grep "White Level"
[EXIF] 0xc61d White Level : 16383
[MakerNotes] 0x787f White Level : 15360 15360 15360
Using the value from the MakerNotes in raw black/white point the indicator is working as expected. The same applies for the image in the thread @jenshannoschwalm mentioned :
exiftool -H -G -a 2014-05-30_19-47-01.cr2 | grep "White Level"
[MakerNotes] 0x02cf Normal White Level : 11767
[MakerNotes] 0x02d0 Specular White Level : 12279
Edit: I checked a complete folder (129 images) of ARW files from my old Sony SLT-A77. For all files dt used a white point of 16596 in raw black/white point while the value reported by exiftool is 15360. These files do not contain the [EXIF] tag, only the [MakerNotes] as shown above.
I tested a NEF image with dt 3.4 & 4.0 :
3.4:
4.0:
An indeed I don't have the exact same area displayed. So something has changed, maybe the move to rawspeed adobe coefs indeed.
EDIT:
4.0 with https://github.com/darktable-org/darktable/commit/60a65ac17ab45f195ed55862d4e69029e58983ec reverted:
(close to what we had in 3.4).
The uploaded Sony raw contains two different White Level tags :
exiftool -H -G -a nosky.ARW | grep "White Level" [EXIF] 0xc61d White Level : 16383 [MakerNotes] 0x787f White Level : 15360 15360 15360
Indeed. I compared a bunch of ARWs from my 6400. In 14bit mode 0xC61D is always 16383 (14bit int max), but in 12bit mode it's always 16380. Anyway, the Sony specific value in 0x787F is always 15360, even in high ISO modes. For the moment 15360 looks more correct than maxint. But I don't know how to proof this is the absolute correct white level to use.
Other findings: The black level switches from 512 to 2048 (all four) on ISO 64000 and above. Though "64000" is read from exif data and not the actual camera setting.
can this be related to moving away from adobe coeffs?
I'm not sure about this, my understanding is that would have also made a visible change on images. This has happened for some cameras (very limited number as far as I know) where there was discrepancies between the old coefs recorded in dt and the ones now used from rawprepare.
Just some random thoughts from a non-coder...
I learned, the wrong whitepoint is set already since long time, just the effect is more clearly visible recently.
Can that be due to so "door openings" during libraw integration?
This thought wouldn't finally solve the correct pick up, but maybe helps something for analysis or comprehensive understanding?
Can that be due to so "door openings" during libraw integration?
I don't think so since the API for this library is only called when no rawspeed support is found for a specific image format. You can check which module to load the RAW has been used by looking at the flags value in image information module. The last character is r for rawspeed and l for libraw (tooltip tell you about this).
I'm not sure about this, my understanding is that would have also made a visible change on images.
I checked a bit further. My current understanding is like:
- The raw overexposed visualizing is absolutely correct as we have it now if we define overexposure as values above a certain value and that value is defined as
threshold*whitepoint - Old and new code take the whitepoint from rawspeed / libraw (from my tests these settings did not change at all) but the values seem to be constant (dng work fine here btw as they have defined exif data)
- For some images there are makernotes that would give correct values but we can't/don't currently read them. This results in incorrect whitepoints. All
dsc.processed_maximum[k] = 1.0fare set this way.
Questions for me now:
- Could we check for existing range-of-data and normalize in rawprepare?
- Any chance to read more makernotes
donno it is interesting: @TurboGit mentioned above, similar trend for NEF files.
I have checked NEF and ORF files on my PC and diff. cameras, I do not find any white level at all in them... strange
I have checked NEF and ORF files on my PC and diff. cameras, I do not find any white level at all in them... strange
They use the constant values we also use which seem to be correct.
I have checked NEF and ORF files on my PC and diff. cameras, I do not find any white level at all in them... strange
They use the constant values we also use which seem to be correct.
but see Pascal's result above with NEF...
@thecb1 helped me to find this where I understand from, it is hardcoded (but who says, it remains untouched?)
but see Pascal's result above with NEF...
That's what @jandren changed and i think that's correct. The visualizing is not the issue for me ...
That's what @jandren changed and i think that's correct.
I'm not saying that it is not correct, just that it may explain the difference we see between 3.8 & 4.0.
4.0 with https://github.com/darktable-org/darktable/commit/60a65ac17ab45f195ed55862d4e69029e58983ec reverted:
(close to what we had in 3.4).
And the OP picture with https://github.com/darktable-org/darktable/commit/60a65ac17ab45f195ed55862d4e69029e58983ec reverted:
