Re: Cheaper sinc computation for resize.c
yes I noticed this with Resize. It 'clamps up' as you put it when magnification becomes involved. As such the same filter is used for both magnification and minification. I think the terms used in research papers was decimation, and reconstruction filters.NicolasRobidoux wrote:Filters generally have a "normalized scaling most appropriate for translations/rotations" which basically is the "support" variable.
If you use the "convolution" as opposed to the "interpolation" approach when enlarging (more specifically, when locally the Jacobian matrix of the geometrical transformation has at least one singular value larger than 1) you should clamp UP the width/height of the "convolution mask" so it is AT LEAST twice the support. If you do that, you do not need to "switch" between EWA and Interpolation (unless, of course, you find that interpolation is better).
This being said, for many methods (at least those for which the weights are normalized, either before or during the "interpolation"), this clamping is exactly equivalent to using the kernel as if it was the cardinal basis function for an interpolatory method. So, maybe you are already doing the above.
In EWA filtering Distort it is a little harder as a direct implantation could generate very long thin ellipses that just 'miss' every source pixel! The solution to that was to ensure ellipses have a minimum thickness.
That same technique however was expanded by Paul Heckbert in a 'High Quality EWA'.
What he did was modify the ellipse so it has a minimal size, with a supposedly smooth transition between the two 'modes' .
The problem is I think I may have implemented it wrong, resulting in a bad ellipse size when magnification becomes involved. At the time I did not understand filtering properly enough to fix it (it was before my research for resize filters that started soon after), and the problem was being hidden by a coping of code from another badly implemented EWA, and hidden by that same codes over blurry Gaussian filter.
Basically the result was the two wrongs cancelled each other out to an extent, and it has only appeared not that I attempted to fix the over-blurriness of distorts, and provided a method to turn off the switch to interpolation for areas of image enlargements. Untill I get this fix I am holding off updating distorts.
Enlarging an image is a good way of checking how well the filter is working as you can directly see the convolution effects of the filter in extreme enlargements. (Ringing, blocking, filter support clipping, etc).
As is demonstrated in the the IM Examples, Resize page.
Code: Select all
convert -size 1x1 xc: -bordercolor '#444' -border 4x4 \ -set option:filter:filter Sinc -resize 100x100\! \ dot_sinc.gif
Clearly shows the 'ringing effects of a raw Sinc on a enlargement of a single pixel.
Repeating this with distort (before my changes)
Code: Select all
convert -size 1x1 xc: -bordercolor '#444' -border 4x4 \ -set option:filter:filter Sinc +distort SRT 12,0 \ dot_distort.gif
shows the result of a bilinear repeating this however with interpolation turned off to force EWA filtering
however results in...
which is clearly WRONG! I Tracking down the problem.
UPDATE: The problem was figured out and fixed. See