Looking for samples - smartphone DNGs with embedded GainMap

Software
#1

I am experimenting with adding support for flat field correction using embedded DNG GainMaps to darktable. This can be quite important; for some phones the colors will be way off if the GainMap is not applied, for example see the image in this thread from a Xiaomi Poco X2.

I am not trying to make something that’s fully conforming to the Adobe DNG spec - the “opcode list processing” that includes the GainMap is flexible and complex and doesn’t really fit well into the darktable pipeline model. I am just trying to efficiently support the typical GainMaps that commonly appear in smartphone DNGs for lens shading correction. So I’m looking for some samples to figure out what needs to be supported. I have a Pixel 4a with the Google Camera app and I found a few other samples on RPU, but would like to see some more from different brands and apps. I have also found a couple (Samsung Galaxy s20 Ultra, and a Huawei) that contain a no-op GainMap that should be ignored.

The GainMap is embedded in the exif tag “Exif.Image.OpcodeList2” or “Exif.SubImage1.OpcodeList2”, depending on whether or not there is also an embedded jpeg preview.

I am looking for any dng containing the OpcodeList2 tag, for which the exiftool command shows:

$ exiftool image.dng | grep GainMap
Opcode List 2                   : GainMap, GainMap, GainMap, GainMap

These might appear in dngs from a smartphone, GoPro, drone, or any other camera that outputs dngs natively.

Thanks!

1 Like
#2

I’ll send a couple from my Pixel 3a …seems like it works nicely in ART so maybe that code could be leveraged

EDIT Just to show…esp note the strong vignette that gets removed when you apply flatfield using the embedded gain map in ART…

Loaded with default profile from an old Lumia 640XL

image
image1549×980 494 KB

Corrected

image
image1537×965 529 KB

Pixel 3a Default

image
image1588×990 399 KB

Corrected

image
image1548×983 429 KB

PXL_20210623_172544488.dng (13.2 MB)
WP_20200807_11_15_05_Raw__highres.dng (18.0 MB)

#3

Samsung seems to have them but ART doesn’t seem to read those ones…
samsung_galaxy_note_20_ultra_10.dng (23.2 MB)

#4

Thanks! I have been using the ART implementation as an example.
The Galaxy Note 20 file only contains a 1x1 GainMap that does nothing and can be ignored. So maybe that camera doesn’t need the correction, or the correction has already been applied by the hardware or app before writing the raw dng.

#5

I had a Huawei P40 sample too but it was 90 odd MB and it also didn’t seem to use the gain map in ART …so maybe similar to Samsung??

#6

It looks like that the GoPro Raw files (GPR) from https://raw.pixls.us/ have GainMaps inside. My Firefox changed the file ending to tif. You need to change it back to “.gpr”.

I used the command line tool from GoPro to extract the meta data:

gpr_tools -i “GoPro - HERO5 Black - 16bit (4 3).gpr” -d 1 > PARAMETERS_GoPro5.TXT

PARAMETERS_GoPro5.TXT (114.0 KB)

#7

When you said it got changed to a tiff I suspected they were really DNG and GoPro just was using their own extension…Well seems I am sort of correct…likely converting to a real DNG would be the best way to work with them in DT ART and RT…

#8

IMG_20211009_135011.7z (12.2 MB)
poco x2 / Redmi k30 - miui camera application.

#9

Darktable/librawspeed can read GoPro files directly. For ART and RT you are right, you need to convert them. GoPro has it’s own compression algorithm.

#10

Not a great test image but it does seem to use the gain maps in ART…

#11

Thanks for the samples! I finally got the implementation working and submitted the PR.

2 Likes
#12

https://raw.pixls.us/getfile.php/4785/nice/DJI%20-%20FC7303%20-%2016bit%20(4:3).DNG
My sample from Mavic Mini2 that looks weird (color vignette) in RawTterapee but ok in Camera Raw.
DJI_mini2_has_OpcodeList3.zip (15.6 MB)

#13

This one is different than the other files I have seen so far… instead of handling all of the vignetting correction with the GainMap like the smartphone dngs, there are two separate opcodes in OpcodeList3:
FixVignetteRadial is a simple vignetting correction that just affects brightness and is applied equally to all color channels, and then the GainMap is only used to correct uneven color cast.

Having the GainMap in OpcodeList3 instead of OpcodeList2 means that it’s supposed to be applied after demosaic instead of before, but I would assume that applying it before demosaic (as if it had been in OpcodeList2) would have the same effect.

The FixVignetteRadial opcode also appears in iPhone DNGs. I haven’t tested it but it looks like ART supports it, but not RawTherapee or darktable.

#14

This assumption is only correct under certain assumptions. Demosaicers don’t like “introduced patterns” at all so you might be lucky but maybe not.

#15

Here is a Huawei P10 Plus image.
IMG_20211024_131137.dng (22.6 MB)

#16

The Huawei P10 Plus image contains a no-op GainMap (all gains are 1 so it has no effect). So there is no need to apply any correction. Probably just an oversight in their camera app including it when it’s not needed…

#17

Thank you for checking.

#18

The lens correction in DT for the P10 does a nice job if your dng have strong vignette. I used it on my pixel images and it worked fantastic even though it is not the same camera…it was actually hard to tell it from the gain mapped conversion…just some differences in extreme highlights I did notice…

#19

On my OnePlus Nord, the standard camera app does not add a GainMap; GCam does, but I wonder if it’s reliable at all (I assume since it’s a hack, it’ll probably just have an empty or incorrect GainMap).

#20

Provide a dng. Then we can have a look, wether the gainmap is valid or a nop :wink: