[FR] Lens shading map (DNG GainMap) support

[paolodepetrillo]

Some smartphone RAW DNGs contain a lens shading map, which is like a generalization of vignetting correction. Unlike the existing vignetting correction in lensfun, it can be an arbitrary shape rather than radially symmetric, and a separate map is applied to each raw color channel separately to correct spatially varying color casts. Also, it's generated for each individual raw image rather than being constant for a specific camera+lens module. I'm not sure how widely used this feature is across various phones and camera apps. The RAW DNGs from the Google Camera app on my Pixel 4a have it and the vignetting is pretty noticeable if the correction is not done.

The Android Camera2 API documentation has a detailed description of how the correction works. The Adobe DNG spec describes how the lens shading map is encoded as GainMap opcodes within the OpcodeList2 exif tag. There is a working implementation in ART - it is enabled by the "Flat-Field" module in the Raw category when "Embedded in metadata" is checked.

I have been trying to figure out how this could be implemented in Darktable. According to the DNG spec, as a stage opcode (in OpcodeList2) the gain map should be applied to linear raw data after black level subtraction but before demosaicing. For the typical case of a RGGB Bayer sensor where the GainMap for both of the G channels is identical (like from Pixel 4a) it would probably end up with the same result if the GainMaps were applied to the demosaiced RGB image prior to input color profile, but it probably makes more sense to apply it to the raw data according to the spec.

One possibility is to do the correction within RawSpeed. It already has the ability to parse DNG opcodes (other than GainMap), but currently this is only done for lossy DNGs. It could be modified to also apply black level subtraction and GainMaps to RAW DNGs that have the gain map, and then it would just output 0 for the black levels so that rawprepare does not perform any further black level subtraction. I'm not sure how the UI would work if there was a need to make this correction optional, since it wouldn't be part of any module.

Another possibility is to do the correction within the pipeline. I think this would be more complicated to implement. It could be its own module that comes after rawprepare, or maybe it could be added to rawprepare. Similarly to #7092 it would need to access the additional info from the exif which is not currently stored in dt_image_t or the image database. It could be awkward to add there because it can be quite large (20kb from the Pixel 4a) and there is not an explicit upper bound on the size defined by the file format. Maybe it could be managed similarly to dt_image_t.profile - it's not stored in the structure or the sql database, there is only a pointer to it. The colorin module loads it from the image file, allocates memory for it dynamically, and it's freed when it is removed from the image cache. The module implementing the gainmap could do something similar - if it hasn't been loaded into dt_image_t already, read it out of the exif, allocate memory, and store a pointer to it in dt_image_t.

[github-actions]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[paolodepetrillo]

I have started working on this at https://github.com/paolodepetrillo/darktable/tree/flatfield-dng-gain-map. There is a lot left to do before it's ready for use but it has been able to successfully apply GainMaps to a smartphone DNG. Beware that this branch does make a change to the module parameters of the rawprepare module so will cause a database migration breaking existing edits.

[benklop]

@paolodepetrillo thank you for this work - I look forward to using it when it is eventually merged!

[github-actions]

This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[johnny-bit]

Fixed in #10289 :)