SincResize and odd/even tap behavior?

[`Orum]

I've been down scaling some 8k RGB images to 2k, experimenting with different resize filters in the process, and noticed some strange behavior with SincResize and it's taps parameter. It appears that using an odd value (1, 3, 5...) for taps produces an overly blurred image, and an even number produces an overly sharpened image. Also, the luma of the clip appears to fluctuate a lot just going between these odd/even values.

Anyway, to demonstrate, load up a large image (e.g. 8000x3333, a few examples to use here (https://secure.flickr.com/photos/k_putt/sets/72157644191959442/)) and downscale it like so, then step through frame-by-frame:
ImageSource("8k.jpg", 0, 19, pixel_type="rgb24")

Animate(0, 19, "SincResize", \
1920, 800, 0, 0, 0, 0, 1, \
1920, 800, 0, 0, 0, 0, 20)

It's most apparent at small values, e.g. taps <= 6, but it's even noticeable up to the 17/18 tap range. The fluctuations definitely reduce as the taps increase, like a position graph of lightly damped oscillation, but this is completely different behavior compared to other resizers, such as Lanczos/Blackman (just replace "SincResize" with "BlackmanResize" in the script). Is this expected behavior, and if so, why is it like that? It seems to get a good result you really need to maximize the taps, which isn't as needed for the other resizers.

Edit: Finally stumbled across the resampling page (http://avisynth.nl/index.php/Resampling) on the wiki, which has a good explanation of the various algos.

[geometer]

Sinc is a very idealized formula to handle the "Gibb" phenomenon. It's a matter of DSP math.
The purpose is to make the picture as sharp as possible, and use up nyquist bandwidth to the last.
But the principle is the computation with as many taps as possible. That's why. (like the Fourier transformation has an endless row of coefficients)
Gibb means the ringing and overshooting, when we try to process a rectangular (=ideally sharp) signal but have only limited bandwidth. We have to attenuate the bandwith of that signal beforehand.
The cost of that kind of filtering is also "dispersion".
(Modern digital signal technology works with oversampling and "reconstruction filters". This means the paradigm with transmitting pixel-sharp rectangles is not valid. It uses technology without reconstruction filter, that creates serious moiree and "steps".)

[`Orum]

Hrm, okay. So if I understand correctly, the SincResize should basically always be used with taps=20 (the maximum), as long as speed isn't a concern. It's just quite a surprise as the other filters like Lanczos and Blackman don't really benefit from taps > 3 (and even 2 is usually enough) on down-scaling, while Sinc seems to require as many as possible to avoid over-shapening. It still seems bizarre how it blurs so much with odd values, but as you said, it's supposed to be an infinite sequence, so that explains the oscillatory behavior.

It gives quite an interesting, and often very pleasing, result, so I think I'll probably opt for it over the others in most instances. (Edit: Actually it seems to introduce some halos without noticeable additional details in many cases, so maybe I'll stick with blackman.) Thanks!

[feisty2]

Hrm, okay. So if I understand correctly, the SincResize should basically always be used with taps=20 (the maximum), as long as speed isn't a concern. It's just quite a surprise as the other filters like Lanczos and Blackman don't really benefit from taps > 3 (and even 2 is usually enough) on down-scaling, while Sinc seems to require as many as possible to avoid over-shapening. It still seems bizarre how it blurs so much with odd values, but as you said, it's supposed to be an infinite sequence, so that explains the oscillatory behavior.

It gives quite an interesting, and often very pleasing, result, so I think I'll probably opt for it over the others in most instances. (Edit: Actually it seems to introduce some halos without noticeable additional details in many cases, so maybe I'll stick with blackman.) Thanks!

because they are not truncated with a rectangular window like sinc in practical use, a smaller tap gives softer result with less ringing to these kernels

[geometer]

Yes,
and after the basics had been understood, the more modern formulas introduced the "windowing", adaptible to the particular application, as workarounds to the problem of expensive computation, and conflict with practical needs. So, all that has its costs, pitfalls, and its benefits.