[WIP] Remove Gaussian blur code alternatives that are exotic or didn't work very well#159
Draft
[WIP] Remove Gaussian blur code alternatives that are exotic or didn't work very well#159
Conversation
c94da94 to
9a20c15
Compare
Member
Author
|
PR #162 has been merged because latest CUDA for Linux can no longer run without it. |
33ca53d to
b192cdb
Compare
b192cdb to
5768dd1
Compare
added 2 commits
October 21, 2025 07:39
work very well. Remove the config param ScalingMode (always use default). Remove fixed scaling code. Remove code to downscale everything directly from input image. Remove the narrower gauss filter width called "OpenCV mode". Remove functions to interpolate from first image plane. Remove specialized version to create very first level from input image. Remove Gauss filter tables for direct downscaling using absolute tables. Removed deprecated scaling mode "OpenCV". OpenCV was buggy when this code was written. It has improved since then. Also downscaling by interpolation, which could not be called with any parameter, is removed. Restructure the calling code for the last 2 pyramid building functions Move host code for normalized source kernel into kernel's file. Normalized source mode is only used for the input image. It uses the normalization feature of CUDA textures to scale the input image while creating the first octave. Simplify the solution with absolute sources. Return to a solution without shuffle and identical code structure for horizontal and vertical Gaussian filtering. Host functions to call Gaussian filtering from point textures moved in kernels' code file. Host functions to call Gaussian filtering from interpolated textures moved in kernels' code file. Simplified and unified code for absolute source interpolated Gaussian filtering. Use horiz_from_input_image exclusively for octave 0. Direct downscaling is not only use for the input image. Note that initial blur is assumed for every input image, even when it is later interpreted as initially unblurred. That does make a difference, but is apparently recommended. Extrema refinement modes have more intuitive names and are no longer tied to PopSift vs VLFeat. (except that the command line parameters of the test code retains the old terms so far)
5768dd1 to
e5deef0
Compare
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.
Description
PopSift had a wide variety of downscaling and Gaussian filtering modes. These were written to increase the potential parallelism of PopSift, explore the trade-off between sequential operation and wider Gaussian filters, the impact of various filter width on quality, etc.
In practice, it seems that users stay with the default. The less successful downscaling/filtering options have therefore been removed.
Two options have been retained from the original PopSift code. Both implement the classical sequence that starts by scaling the input image and performing Gaussian filtering incrementally through the levels of an octave, and downscaling the following octave from the 3rd last level of the previous octave. These are the non-interpolating and the interpolating approaches.
The classical "non-interpolating" approach
It takes the neighbouring pixels and multiplies them with the weights from the pre-computed Gaussian filter. The width of this filter varies for each level to ensure a regular scale space.
The alternative "interpolating" approach
It starts with the same Gaussian filters, although their width is rounded up to a multiple of 2. The weight of two neighbouring cells g[n] and g[n+1] is then reformulated as a relative weight between these two cells, ie.:
g[n]I + g[n+1]J = abI + (1-a)bJ = b*(a*I + (1-a)J) where b=g[n]+g[n+1] and a=g[n]/(g[n]+g[n+1])
The appropriate values for b can then be read from an array, while the neighboring pixels I and J can be read with linear interpolation with a weight of A through the texture engine. This means that the term a*I + (1-a)J is handled by the texture hardware, leaving only one multiplication per 2 pixels.
Features list
Implementation remarks
Handled in other PRs