Lensfun unnecessary scale when there's no geometry correction.

[frivoal]

I like to auto-apply lensfun based autocorrections on all my pictures. Depending what's available, it'll correct more or less things (TCA, vignette, geometry), and that's great, that's what I expect.

However, I'm finding that for a number of lenses I have, lensfun doesn't have geometry information, but still applies a "safety" scale of 1.002, or sometimes a little more. I get it that this comes from the lensfun database, and that they do that to avoid dealing with missing out-of-frame data when doing geometry corrections, but when there is no geometry being corrected, that serves no purpose, and needlessly scales/crop the images (by a tiny amount).

As far as I can tell, it is not possible to set up darktable to auto-apply lens correction, with all corrections available, except that it should not apply scale if there's no actual geometry correction being performed.

Would it be possible to make that the behavior available (likely through some kind of opt-in check box), and even possibly be the default setting? I suppose we cannot make it an always-on thing, as that would be a rendering change for previously processed images, but as long as the old behavior is available, we can have better defaults for new pictures.

[da-phil]

I have a very similar workflow and that's a very good point I also noticed a couple of times for images where there is no lensfun profile for.
However it is a no-issue, as the value 1.002 is not even applied if the given camera+lens combination is not found, or no EXIF data is available, see here in the code:
https://github.com/darktable-org/darktable/blob/master/src/iop/lens.cc#L1061

  if(!d->lens || !d->lens->Maker || d->crop <= 0.0f)
  {
    dt_iop_image_copy_by_size((float*)ovoid, (float*)ivoid,
                              roi_out->width, roi_out->height, ch);
    return;
  }

dt_iop_image_copy_by_size() ensures a pixel-perfect passthrough, so no scale will be applied.

I think the issue can be closed.

[frivoal]

I may be missing something, but if the lens is found in the database, but has no geometry information (but for instance, has vignetting information only), isn't the 1.002 still applied? That's the case I'd like to deal with.

[da-phil]

Apologies, then I didn't read or understand you correctly.

But now I do!

This is a quick analysis by copilot:

The factor 1.002 seems to comes from two separate 1.001 factors stacked within lensfun:

• subpixel_scale = 1.001 applied whenever TCA correction is active. TCA shifts the red/blue channels by sub-pixel amounts; without a tiny crop, the shifted channels could reveal a hairline border at the edge of the frame.

• scale *= 1.001 is an accuracy hedge on the numerical sampling: lensfun only samples 8 boundary points to find the worst-case distortion crop, and this margin covers the gaps between those samples. This only applies when geometry/distortion is actually corrected.

So when there's no geometric / distortion data but TCA is being corrected, CoordCallbacks is empty → the function returns just subpixel_scale = 1.001. The value 1.002 which is observed would appear when both are active (1.001 × 1.001 ≈ 1.002).

But this shouldn't be the case if no geometric data is available?

Also, I think there might be a little flaw in the darktable lensfun interaction logic, the scale parameter is not automatically updated when different corrections are chosen, however there is a button which resets the scale to the pre-determined value from lensfun, see screencast:

Screencast.from.2026-04-17.14-32-31.mp4

I wonder how you got a 1.002 there? Can you share a video and/or an example RAW file?

[wpferguson]

I wonder how you got a 1.002 there?

I vaguely remember a discussion about this years (>6) ago. Unfortunately I don't remember the specifics. You may want to go back and read the git log for the module (or do it with gitk) and see if anything is there. You could also ask a question on the lensfun repository.

EDIT:

iop/lens.c got moved to iop/lens.cc in 2019, so if you need to go back farther go a few commits past the change and check out that commit, which will then let you look at the history of iop/lens.c