[ARW] Fix incorrect white levels and black levels on high iso

[koolfy]

While trying to debug this: darktable-org/darktable#11323
I realized black level values change starting from ISO-102400 until max ISO, applying 1024 prevents blowing out all channels and restores a proper image interpretation as far as I can tell.

While checking the "Black level" and "White level" fields extracted from exiftool on all my raw files, I also noticed metadata always mentions white level values of 15360 instead of the current 16283 value, so I added another commit to address this.
Feel free to discard that second commit if there was a good reason to use 16283 instead ;)

[LebedevRI]

Can we instead just read it from the EXIF?

raw.pixls.us/Sony/ILCE-7M4$ EXIV2 _DSC0117_14bit_raw.ARW |  grep WhiteLevel
0xc61d Exif.SubImage1.WhiteLevel                    Short       1   2  16383  16383

[kmilos]

The WhiteLevel yes (and it is also the same value the DNG conversion provides, so I wouldn't change it), and rawspeed could read it directly in the decoder.

OTOH, BlackLevel (and white balance) is hidden in the ARW both under the non-standard tag 0x7310 under the raw IFD, and in the private SR2Data IFD (pointed to by the DNGPrivateData tag) as well under the same tag. Currently rawspeed tries to get WB from decoding/decrypting this private IFD only AFAICT.

Exif.SubImage1.0x7310                        Short       4  512 512 512 512
Exif.SubImage1.0x7313                        SShort      4  2480 1024 1024 1645

[koolfy]

Reading the white level from metadata, if possible, would certainly be better as I get a different value and haven't yet found why mine differs from yours (some obscure setting somewhere?)

I went for the easy PR by editing the xml, as it was well documented, do you have an example of how rawspeed can extract it from the EXIF?

I'm guessing the library it uses cannot directly pull from the other non-standard fields?

[LebedevRI]

This might be as simple as copying

rawspeed/src/librawspeed/decoders/DngDecoder.cpp

Lines 288 to 290 in 1a1b723

	const TiffEntry* whitelevel = raw->getEntry(TiffTag::WHITELEVEL);
	if (whitelevel->isInt())
	mRaw->whitePoint = whitelevel->getU32();

into

rawspeed/src/librawspeed/decoders/ArwDecoder.cpp

Line 348 in 1a1b723

and removing the <Sensor> entries for this camera.

[koolfy]

@LebedevRI and what about the black level value that's harder to retreive? (and the original request for this PR)

[kmilos]

and what about the black level value

Either try if raw->hasEntry(0x7310) exists (you can also define this as e.g. TiffTag::SONYBLACKLEVEL for later use) and read that (dunno if that duplication is specific to 7M4 or "newer" Sony cameras), and/or try decrypting the SR2Private IFD (see the white balance example) and look for tags 0x7310 as well, and/or 0x7300.

[koolfy]

Hello I'm struggling with spare time to implement and test the "right" approach, could this PR be merged and a separate issue be opened (and assigned to me) for the more elegant fix done later on?

Or would you really rather wait possibly longer for me to get around to doing it right?

[AxelG-DE]

I connected dt's issue to here (see above) and guys on pixls are struggling

[artemist]

Can a maintainer please merge this? If @koolfy is no longer interested in implementing getting white point and black level from EXIF then I can also try after this is merged

[AxelG-DE]

@artemist I am also only "test pilot", but do you know, you can actually inject code into master by our self?
You need to execute the following commands at your local repo (the following example is based on darktable so you gotta modify):
git remote add upstream git://github.com/darktable-org/darktable.git
git fetch upstream pull/349/head:rawspeed-test_test
git checkout rawspeed-test

I know rawspeed is a submodule so it will be a bit more tricky, but here or at #darktable (OFTC) you find help
Besides, Roman occasionally hang-out at libera-chat #pixls.us

I hope I could help a little. If you run into troubtle here, I am afraid, my competences are way too limited 😊

[jorismak]

Often getting the white point from exif is not enough, the correct white point is stored in the maker notes for some models (Sony often reports wrong white point in exif but correct one jn maker notes for example ).

I've also seen Nikon nef files that open with a (slightly) wrong white point , but exiftool can't read any white point value from the file, no matter the source group .
Looking at the rawtherapee camconst.json reveals a whole group of rules for black and white levels , depending on iso .

[LebedevRI]

Thank you all!
This has now been resolved via #385.

[jorismak]

Awesome to see work on this, and I guess this fixes a lot of the Sony problems.

But I encounter CR2 and NEF files that also have a different white-level set in Darktable vs what exiftool reports.
(or, there are visually clearly clipped highlights showing up as magenta patches, and it requires lowering of the white-level in Darktable for them to show up in the raw-clipping indicator).

So it fixes it for certain models / brands.. Which is 🎉 . Now I hope others are not left out :).

[LebedevRI]

Yup, many other similar changes are needed.

[artemist]

The code I wrote grabs the sony-specific values from the makernote. Honestly I mostly did this because I was considering getting an ILCE-7M4 but similar methods for grabbing white/black point should hopefully work on other manufacturers' cameras

[kmilos]

While it might be doable for Canons, I see no known tag for white level in Nikon makernotes unfortunately, only black (but that might be a good enough improvement anyway #388): https://exiftool.org/TagNames/Nikon.html