Uniform Pink hue in exthemely high ISO profile for ILCE-7m4

[koolfy]

Producing noise profiling in https://github.com/darktable-org/darktable/issues/11319 I noticed the 4 highest iso profiles were interpreted by darktable as having a very strong pink veil over the entire image. (I hope it didn't throw off the NR profiling)

This happenned with 3.9.0~git716.e00836f030-1 on ubuntu linux 21.10 It could be reproduced with 3.8.1 stable as well

It looks like something is throwing off darktable, as in-body-generated-jpgs and thumbnails appear to be correct.

https://drop.infini.fr/r/T65Mw_azAC#0W1GViyqiLHTMeNFAOQc3il2S1gwv1b0JrDIp61KzVE=

The first file in the bunch is the last high-iso level that is not affected by the issue, while the 4 others all show the issue on the 4 next ISO levels. The issue did not present itself on any lower ISO values, but consistently does at these 4 highest values.

[MStraeten]

you might switch on the raw overexposure warning (https://docs.darktable.org/usermanual/3.8/en/module-reference/utility-modules/darkroom/raw-overexposed/) to see if there’s clipping in the raw channels. pink highlights are usually a result of clipping. Then you need to spend some effort to deal with highlight reconstruction

[kmilos]

https://www.photonstophotos.net/Charts/PDR.htm#Sony%20ILCE-7M4

At some point this camera switches on its internal noise reduction, so perhaps the raw data in this mode is somehow different... Can you maybe try converting both of these modes w/ Adobe DNG Converter and comparing the black level tags? (Could also try on ARW / exiv2/exifool as well, don't remember now if black levels are reported there...)

[wpferguson]

All the raw channels are clipped, which is what causes the pink hue.

[koolfy]

@wpferguson indeed, but something appears to have shifted all the raw values for some reason only on those files, meaning there is zero pure black anymore. Looks like a symptom of the root cause. (Again, jpegs produced by the body do not have this issue and have proper blacks, albeit noisy)

@kmilos possibly but the issue starts at around 100k ISO while this mechanism seems to kick in around 64k ISO so it doesn't match very well. How can I do this conversion on Linux? (without resorting to wine if possible haha)

@MStraeten raw overexposure warning only highlights the center of the frame (which was overexposed on purpose, it's sort of the point of the iso noise profiling experiment in the first place)

[wpferguson]

You can use 1024, 2703, 1024, 1698 for black values 0, 1, 2, 3 in raw black/white point. I got them using exiftool. But, the highlights are still overexposed and the channel values are blown.

EDIT: remember that the jpeg is done using the camera maker's proprietary knowledge. If it's anything like CANON's jpegs, on noisy images the darks are crushed to get rid of the noise.

[koolfy]

Closing as I am fairly confident I cracked the mystery:

In all "reasonable ISO" unaffected pictures, exif show: Black Level : 512 512 512 512

Which so happens to be the raw black point used by rawspeed/darktable to interpret the image

In all "unreasonable ISO" pictures displaying the blown out channels issue, the same field has a different value: Black Level : 1024 1024 1024 1024

On all pictures rawspeed uses 512 as raw black point for all channels. Manually setting 1024 for all channels on the pictures whose exif suggest 1024 results in exactly the picture I would expect to have :)

I'll open an issue over at rawspeed :)

Thanks for your help!

[kmilos]

I'll open an issue over at rawspeed :)

Better yet, open a PR ;)

Should be matter of per-ISO setting in data/cameras.xml you can even test locally

[koolfy]

@kmilos very good idea, but is there a reason why we don't simply read the value off the exif field? maybe not needing to rely on exiftool on libs to interepret an image?

[kmilos]

What Exif field? ;)

This is Sony ARW proprietary/hidden information we're talking about, no?

[koolfy]

exiftool extracts two fields called "Black level" and "White level" whose values seem to be the right ones, which lead me to believe these values can be simply extracted and used. But seeing cameras.xml I'm starting to see how rawspeed might not have the piping to use dynamic values gotten from the metadata itself

Maybe exiftool interprets proprietary/hidden information and I'm confused :)

[kmilos]

When you run exiftool w/ some more options like -a -u -s -g1 you will see the BlackLevel is buried in the SR2SubIFD section, which is deep inside the Sony's proprietary MakerNotes, i.e. it is not part of standard Exif, so this is not so trivial.

It is not impossible for rawspeed to try to get to this in the Sony decoder (it does attempt to read some other MakerNotes for other vendors; for Sony it only tires to get to white balance info), so you could indeed open a feature request.

Going through the XML file is less effort though for the moment...

Edit: This is why I suggested the DNG route at first, as BlackLevel is a field known to exist in DNGs and Adobe fills it for you during the conversion; for Sony ARWs I wasn't sure at the time (didn't have access to a sample and exiftool), as I know some other formats don't expose it (or hasn't been figured out how to extract it yet.)