Алгоритмы масштабирования изображений для AviSynth (ресайзеры)

This plugin contrains two kinds of spline based resizers:
The first ones are the (cubic) spline based resizers from Panorama tools that fit a spline through the sample points and then derives the filter kernel from the resulting blending polynomials. See this thread for the details. Spline100Resize (using 10 sample points) and Spline144Resize (using 12 sample points) are added here. Other ones are available in AviSynth itself.
The second ones are natural cubic splines that use the kernel itself as a spline. The theory can be found here.

Here is a pack containing useful functions for resizing.
LinearResize()
It revolves around the resizing functions in the Dither Tools but made as easy as a one-liner.
-It resizes in 32 bit, with lsb_in/lsb_out options.
-It automatically changes matrix when switching from SD to HD or viceversa. (You could skip resizing and use it only for matrix change in 32bit as well)
-Allows to resize in a linear fashion.
-Automatically detects colorspace (RGB or YV12)
Yes, you can easily call it the best resizer out there. Thanks cretindesalpes!
RatioResize()
OK, I already know the Pixel Aspect Ratio of my source, how can I preview it quickly? with RatoResize() of course : P
RatioResize(0.911,"PAR")
Ratio Resize is a simple preview purpose resizer based only on single figures, like PAR, DAR, % of original size, and 2 interesting modes for snapping a source width (or height) to a certain value with proportional overall scaling.
Some other options and insights in the script, check them out.
SpliceResize()
Not the best of these 3 of course, but anyways is there. This one is not really mine, it's only my take on the one found in this post.
The idea is to resize in bicubic (catmull-rom) for high contrast features, and spline64 for the rest. So you get a ringing free good quality resize. Test it out!

madResize.avsi
Fast SeparateResize as madVR
nrLSResize.avsi
Non-ringing Lanczos/Spline Resize
Algorithm is here: http://forum.doom9.org/showthread.php?t=145358
SoftCubicResize.avsi
SoftCubic Resize from madVR
SeparateResize_v1.4.avsi

http://forum.doom9.org/showthread.php?p=1655611#post1655611

This comparison table was created using AviSynth 2.5.7. The Zone Plate test pattern was created by Ken Turkowsky. It has been processed by AVISynth. Each filter was called by his default preferences. The one-frame-video was then converted to png by IrfanView.

This Zone Plate was used.
Magnification
The square was magnified by two in eight steps 32 pixels each.

magnified using a bicubic filter (standard preferences)

magnified using the bilinear filter

magnified using the gaussian filter

magnified using the lanczos filter

magnified using the lanczos4 filter

magnified using the point filter

magnified using the spline16 filter

magnified using the spline36 filter
Minimation
The square was downsized to it's half in eight steps 16 pixels each.

downsized using a bicubic filter (standard preferences)

downsized using the bilinear filter
[img]http://hermidownloads.craqstar.de/videoresizefiltercomparasion/downsized/avs_gauss.png"[/img]
downsized using the gaussian filter

downsized using the lanczos filter

downsized using the lanczos4 filter

downsized using the point filter

downsized using the spline16 filter

downsized using the spline36 filter
Modified 2007-07-26 by Hermann Höhne hoehermann(swirly thing)gmx(small square)de

What we can see, looking at the numbers, is that the higher the resolution of your source (or better, the more details the source has) the better upscaling works. If your source is too blurry, upscaling won’t work as good as it could. All scalers perform quite good (except for point and sinc, but that was to be expected). Spline16 performs worse than spline36 and spline64, for upscaling spline36 performs better than spline64. Lanczos and spline are quite similar the difference is very minimal, according to the numbers, lanczos performs better than spline; overall best resizer for upscaling is nnedi3. Another thing which you can see in the visual results above is that the nnedi3 image doesn’t have the stairs-effect.
If you have to decide which resizer (in avisynth) to use for upscaling, go this route:
nnedi3 > lanczos/lanczos4 > spline36 > everything else

Оригинал.

---

Проведён downsize 1280х1024 → 720х576.
Bicubic - Bilinear - Blackman - Lanczos4 - Lanczos - Spline36 - Spline64 - Spline100 - Spline144

Размер выходного изображения в байтах в порядке возрастания:
[*]BilinearResize - 459 284 байт
[*]Spline100Resize - 499 301 байт
[*]BicubicResize - 532 979 байт
[*]Spline144Resize - 561 401 байт
[*]Spline36Resize - 603 807 байт
[*]BlackmanResize - 606 463 байт
[*]LanczosResize - 611 641 байт
[*]Spline64Resize - 646 661 байт
[*]Lanczos4Resize - 699 001 байт
* Применение группы ресайзеров, выделенных зелёным цветом, в большинстве случаев, думаю, можно считать оптимальным с точки зрения соотношения вес/шарп. Но выбирать, естественно, вам самим.

Downsize by half:
Bicubic - Bilinear - Blackman - Lanczos - Lanczos4 - Sinc - Spline36 - Spline64 - Gauss - Point

Upscale x2:
Bicubic - Bilinear - Blackman - Lanczos - Lanczos4 - Sinc - Spline36 - Spline64 - Gauss - Point

Spline100/144 изображение не прожевали.

This page attempts to visualize various resampling kernels in a way that will help to you choose which one is right for you. There is no "best" kernel — they all have their uses and the right one for will depend greatly on both the source and personal preference.

Any signal-processing filter has "taps" which are the discrete input values that are used to calculate each output value. In audio processing it's pretty straightforward - a 20-tap FIR resampling filter takes 20 audio samples, multiplies each by one value in a 20-element filter "kernel," adds all the results together, and spits out a single output sample. Lather, rinse, repeat. In video it's a little different, but that's the rough idea.
When a filter is based on a windowed sinc function (sinc is (sin(x)/x)), it's convenient to talk about the number of lobes of the sinc function that are being used. X=0 to X=pi is one lobe. X=pi to X=2pi is another lobe. X=2pi to X=3pi is another lobe and so forth. Because all windowed FIR sinc filters are symmetrical around 0, we only talk about the number of lobes on one side of 0. There are an equal number of lobes on the the other side.
So when people talk about Lanczos2, they mean a 2-lobe Lanczos-windowed sinc function. There are actually 4 lobes -- 2 on each side. The function, graphed in the range -2pi to 2pi looks kinda like a sombrero. I've attached a graph of Lanczos2. Catmull-Rom looks almost identical, but is not a windowed sinc filter, or in fact any kind of sinc filter. The fact that two resizing filters created using completely different mathematical principles look almost identical is not a coincidence, but understanding why it turned out that way was certainly a big ah-ha! moment for me. And way too complicated to explain here, sadly.

For upsampling (making the image larger), the filter is sized such that the entire equation falls across 4 input samples, making it a 4-tap filter. It doesn't matter how big the output image is going to be - it's still just 4 taps. For downsampling (making the image smaller), the equation is sized so it will fall across 4 *destination* samples, which obviously are spaced at wider intervals than the source samples. So for downsampling by a factor of 2 (making the image half as big), the filter covers 8 input samples, and thus 8 taps. For 3X downsampling, you need 12 taps, and so forth.
The total number of taps you need for downsampling is the downsampling ratio times the number of lobes, times 2. And practically, one needs to round that up to the next even integer. For upsampling, it's always 4 taps.
So a 2-lobe (which is really a 4-lobe) Lanczos filter could require any number of taps. To downsample a 1080p image down to 108 pixels high would require 40 taps.
All of these numbers are, of course, just in one dimension. To get the full number of taps required for an output pixel, you would theoretically calculate the number of taps required in each dimension (height & width) and then multiply them together. So upsampling would require 4x4=16 taps. By convention, though, we still call that a 4-tap filter (unless we're in marketing, and then we call it a 48-tap filter: 16 taps times 3 components R, G, and B ).
Practically speaking, for performance you would always scale the image in two passes, which is perfectly kosher (or at least it is with these filters, which are *separable*, meaning that we can apply them separately in X and Y and get the same result as applying the combined filter). Conceptually you scale just in the width dimension into a new buffer that is as wide as the target image and as high as the original. Then you scale that intermediate image just in the height dimension into a final target buffer. Thus in the upsampling case you are applying two 4-tap filters instead of a single 16-tap filter.
Again, there are a huge number of practical considerations. You end up pipelining things very differently than the "conceptual" algorithm, mainly to maximize cache coherency. In order to do any kind of arbitrary scaling, you need to calculate a large number of filter kernels, as the phase between the input and output samples changes as you work your way across the image.
Man, if that's the short version I hope I never have to write the long version. Again, the thing to do if you want to understand practical scaling algorithms is to read the Turkowski paper I referenced earlier in the thread and read the code for Paul Heckbert's "Zoom" (it's not the cleanest code in the world, but understanding why he does various things is a real education). Start there and then branch out.
And if you have questions, you can always email me. My email address is not hard to find. I can't always promise I can answer every question, as among other things some of the stuff I'm doing right now with scaling is about to be patented, but I'm happy to steer folks in the right direction.
As for the questions about the best ways to use ffdshow, I have to admit that I don't know. At home I use the scaler built into the VW10HT, which looks to me like a basic bicubic, which is perfectly fine. At work I use my own scaler. I don't really have time to evaluate ffdshow extensively.
I will say that I am adamantly against filters with more than 2 lobes when scaling images. Their advantage is extra sharpness, but they ring like crazy. In my own scaler, I adjust sharpness by combining a modified sharpening kernel with the basic scaling kernel. It makes the image just as sharp as a multi-lobe Lanczos, but without the multi-lobe ringing.
Here's Lanczos3.

Here's Lanczos10. The extra-deep first negative lobe (from 1 tp 2 and -1 to -2) gives you the extra sharpness, but all the other lobes (beyond 2 and -2) produce annoying fringes around sharp edge transitions. Bleah.
The perception of sharpness in an image scaling filter is almost entirely related to the depth of the first negative lobe. The more lobes you put on a Lanczos (or any other windowed sinc) the deeper the first negative lobe gets. But that's an incredibly pricey way to deepen the negative lobe, and has ugly side effects. There are lots of other ways.

Обычно алгоритм ресайза исходника не сказывается на проигрываниями проигрывателями. Но мне любопытно, откуда такие у вас идеи. Подозреваю кашу в голове. Но вот как сформировались такие комочки и подгорелости?

---