Skip to content

Fix interpolators lens#20891

Merged
TurboGit merged 2 commits intodarktable-org:masterfrom
jenshannoschwalm:fix_interpolators_lens
Apr 28, 2026
Merged

Fix interpolators lens#20891
TurboGit merged 2 commits intodarktable-org:masterfrom
jenshannoschwalm:fix_interpolators_lens

Conversation

@jenshannoschwalm
Copy link
Copy Markdown
Collaborator

  1. Make sure the lens interpolation does not restrict output data to be at least zero. 7486c4c
  2. Some code maintenance in 978843c with some very subtle fixes

@TurboGit

  1. no testsuite regressions
  2. About the performance testing, i think we might want a disable switch for this as it makes it very difficult to spot content-regressions while comparing logs. It might also be worthwhile to subtract the noop-test runtime from measured timing ???
  3. The lens related commit is the first (and safe) part of other "interpolating code parts" like scaling, ashift ... We currently do a avoid-negatives-in-output but a) we can have interpolator overshoots as well b) we might possibly operate on data with valid negatives in input and thus output should be negative too. "Fixing" this will lead to very subtle but measurable diffs in CPU vs CPU tests. Any opinion?

1. make sure the passthrough demosaicers work identical and simplify passthrough color CPU mode.
2. removed "clip_and_zoom" OpenCL kernel as it's not used.
3. use clamp in many cases instead of range checks.
4. more use of readpixel(), readsingle() and readalpha variants in OpenCL code.
5. use the Areadpixel/single() variants where checking for valid coordinates is done in caller.
6. A few more simplifications and formatting
While correcting for lens distortion, vignette and cfa correction we should not
restrict output data to be at least zero, as we can have have valid negative input
while correcting.
Made sure that masks are restricted to 0->1 whenever we use interpolate sample.
@jenshannoschwalm jenshannoschwalm added this to the 5.6 milestone Apr 28, 2026
@jenshannoschwalm jenshannoschwalm added scope: image processing correcting pixels scope: codebase making darktable source code easier to manage OpenCL Related to darktable OpenCL code labels Apr 28, 2026
@TurboGit
Copy link
Copy Markdown
Member

2. About the performance testing, i think we might want a disable switch for this as it makes it very difficult to spot content-regressions while comparing logs. It might also be worthwhile to subtract the noop-test runtime from measured timing ???

I'll add the option --disable-timing. I think we want to keep the 0000-nop test as it measures the default module and so the pixel pipes.

@TurboGit
Copy link
Copy Markdown
Member

3. a) we can have interpolator overshoots as well b) we might possibly operate on data with valid negatives in input and thus output should be negative too.

For a this could be fixed in the interpolator, no? I'm not sure in the "valid negatives" in this context. Can you give more details? TIA.

Copy link
Copy Markdown
Member

@TurboGit TurboGit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@TurboGit TurboGit merged commit 1e2cf01 into darktable-org:master Apr 28, 2026
5 checks passed
@TurboGit
Copy link
Copy Markdown
Member

Option --disable-timing added.

@jenshannoschwalm jenshannoschwalm deleted the fix_interpolators_lens branch April 29, 2026 04:17
@jenshannoschwalm
Copy link
Copy Markdown
Collaborator Author

@TurboGit i will do a pr about the interpolating stuff so we can discuss and test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

OpenCL Related to darktable OpenCL code scope: codebase making darktable source code easier to manage scope: image processing correcting pixels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants