lens vignette removal with embedded-metadata produces curved RGB parade plots (bug?)

[TiredOfGuessing]

Describe the bug

Using lens correction only vignette with embedded-metadata rather than Lensfun-database produces curvature (a “smile” ) on the RGB parade not seen with the Lensfun-database correction.

I first observed this with a regular photo that had flat/uniform tones, but this simple cloud test image demonstrates the issue without distractions. The image was taken with a Sony A7RM3 and Sony FE 100-400mm F4.5-5.6 zoom at 400mm is most pronounced. I have not noticed this issue with my 24-70mm lens (lower magnification?).

I attached two screen grabs comparing Lensfun database (straight, good?) with embedded metadata (curved, bad?).

Steps to reproduce

1. Load a flat uniform raw file like attached and view in darkroom
2. Select RGB parade graph
3. Disable all modules except white-balance and lens correction
4. Set lens module corrections = only vignetting
5. Set lens module correction method = Lensfun-database (straight plots)
6. Set lens module correction method = embedded-metadata (curved plots)

Expected behavior

I would expect the embedded-metadata and Lensfun-database to at least be more similar. Really I would have thought the manufacturer supplied metadata to be better based on their skills, knowledge, tools. I would hope we can one day just rely on metadata? :)

Logfile | Screenshot | Screencast

Attached are screen shots showing the difference between correction method.

Not sure how to submit the ARW since it's 85GB? See exif dump below. 7R300394_ARW_xmp.zip

Commit

No response

Where did you obtain darktable from?

downloaded from www.darktable.org

darktable version

4.6.0

What OS are you using?

Mac

What is the version of your OS?

macOS Ventura 14.2.1

Describe your system?

Apple MacBook Pro M1 64GB

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

Apple M1

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

This was first observed/produced on 4.4.2 and replicated after upgrading to 4.6.0.

ExifTool dump of relevant vignette info https://exiftool.org/TagNames/Sony.html#Tag9405b Sony ISO : 100 Stops Above Base ISO : 0 Sony Exposure Time 2 : 1/644 Exposure Time : 1/640 Sony F Number : 6.3 Sony Max Aperture Value : 5.7 Release Mode 2 : Normal High ISO Noise Reduction : Off Long Exposure Noise Reduction : Off Picture Effect 2 : Off Exposure Program : Manual Creative Style : Standard Sharpness : Normal Distortion Corr Params Present : Yes Distortion Correction : Auto Lens Format : Full-frame Lens Mount : E-mount Lens Type 2 : Sony FE 100-400mm F4.5-5.6 GM OSS Lens Type : E-Mount, T-Mount, Other Lens or no lens Distortion Corr Params : 16 1 2 5 13 22 36 52 71 93 118 146 176 210 247 287 329 Lens Zoom Position : 99% Vignetting Corr Params : 16 0 32 32 128 352 896 1632 2496 3456 4480 5536 6560 7584 8544 9472 10336 Lens Zoom Position : 99% Vignetting Corr Params : 16 0 32 32 128 352 896 1632 2496 3456 4480 5536 6560 7584 8544 9472 10336 Lens Zoom Position : 99% Vignetting Corr Params : 16 0 32 32 128 352 896 1632 2496 3456 4480 5536 6560 7584 8544 9472 10336 Vignetting Corr Params : 16 0 32 32 128 352 896 1632 2496 3456 4480 5536 6560 7584 8544 9472 10336 Chromatic Aberration Corr Params: 32 -512 -640 -640 -640 -640 -640 -640 -512 -512 -512 -512 -384 -384 -256 -128 0 384 256 128 128 0 0 128 0 0 0 -128 -128 -256 -384 -512 -640

I'm glad to run further tests if helpful.

[ralfbrown]

The RGB parade is indicating that the embedded corrections are resulting in an over-correction - the corners are now too bright.... Possibly the code is mis-interpreting the correction information; maybe this model is using a different correction model, so that the stored coefficients result in a greater correction than intended when the darktable code applies them to the model it uses.

[TiredOfGuessing]

Based on LensFun method results, the metadata approach could work better, though I have no idea how. The dt code lens.cc has a special Sony code branch (CORRECTION_TYPE_SONY) so I assume Sony’s metadata/algo is somehow unique.

The actual image where this was first observed was taken on a hazy San Francisco afternoon, and with narrow dynamic range, so an image that likely aggravates the issue, per link below. https://www.dpreview.com/forums/thread/4567346

… At low contrast (fog, haze, very flat light) this is a typical problem when stretching very low contrast images quite a bit. This is common among telezooms from all brands so no unique Sony problem …

I will use the LensFun method for lens corrections for now.

I plotted the metadata with my other lens just to compare. Surprisingly the lens 100-400 producing the issue has a less aggressive slope than the 24-70 lens.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.