Repository navigation
lens: use lanczos taps for lanczos3 in the OpenCL metadata correction - #22848
Merged
TurboGit merged 1 commit intoOct 31, 2026
Merged
Conversation
Collaborator
|
I agree with the usage of lanczos3 it that is found in conf. But as we don't want to be supported due to overshoots which is bad for distorting i would avoid the release note as that might give an unwanted hint. |
Member
|
I agree with the fix, and yes we don't need a release notes entry for such very improbably case. |
compute_upsampling_taps() picks the taps by the dt_interpolation_type it is given, and handled bicubic (1) and lanczos2 (2) but sent everything else to the bilinear taps. With lanczos3 (3) as the warp interpolator, the embedded metadata correction on OpenCL therefore weighted a 6x6 window with bilinear taps, while the CPU, through dt_interpolation_compute_sample(), uses the lanczos taps that lanczos2 and lanczos3 share. In integration tests 0145 and 0146 rendered with lanczos3, every pixel of the OpenCL export differed from the CPU one, by an average dE of 31. Use the lanczos taps for both lanczos widths.
nicknezis
force-pushed
the
lens-opencl-lanczos3-taps
branch
from
October 30, 2026 23:51
5c79822 to
87481bd
Compare
Contributor
Author
|
Agreed, release note removed. |
nicknezis
pushed a commit
to nicknezis/darktable
that referenced
this pull request
Oct 31, 2026
The Slang compute_upsampling_taps() copied the OpenCL bug fixed in the previous commit (darktable-org#22848): lanczos3 got bilinear taps. Give it the lanczos taps on both paths, and drop the parity test comment that explained the larger lanczos3 error by that bug.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The OpenCL path of lens correction from embedded metadata picks its interpolation taps in
compute_upsampling_taps()(data/kernels/basic.cl). That function handles bicubic and lanczos2, but sends every other mode to the bilinear taps. With lanczos3 as the warp interpolator, OpenCL therefore weighted a 6x6 window with bilinear taps and produced a badly wrong image. The CPU path uses the lanczos taps that lanczos2 and lanczos3 share (src/common/interpolation.c). This PR sends lanczos3 to the lanczos taps too. The code dates from 2bcc293 (4.6).The preferences dialog only offers bilinear, bicubic and lanczos2 for the warp interpolator, so the bug is reached by setting
plugins/lighttable/export/pixel_interpolator_warp=lanczos3in darktablerc or with--conf. The preferences UI doesn't offer lanczos3 for warping, so maintainers may say the release note isn't needed. If they do, I can drop that commit.Checklist
_(), and new preferences are registered indata/darktableconfig.xml.in(this PR adds none).RELEASE_NOTES.mdentry was added, in its own commit.Test instructions
Run on an Apple M4 Pro under macOS, with the integration test options,
--conf plugins/lighttable/export/pixel_interpolator_warp=lanczos3and OpenCL forced on. OpenCL vs CPU export:AI assistance
Written with Claude Code, which found the fall-through while porting the kernel and ran the tests above. I reviewed the change.