implementations of resizers

[d'Oursse]

Hello,

i would like to know if there exist faster implementations of bicubic and lanczos resizers than those provided by avisynth (in RGB mode).

thank you

[sh0dan]

SwScaler in mplayer/mencoder should be faster, but it should also be less precise. I haven't seriously looked at it, but the code is VERY cryptic - even compared to AviSynth. The resizer in Virtual Dub is much more readable, but I haven't compared it to AviSynth, but IIRC you'll have to use the float point resizer to get good quality.

I don't think you'll be able to get much faster code than the resizer in AviSynth.

[scharfis_brain]

TrBarry has implemented a very fast resizer called
bicublin-resize, or so.

[d'Oursse]

Shodan : the asm code of the resizers in Avisynth are currently generated by softwire, right ? (Manao told me that). Are the old asm codes the same ? I want to test them with another implementation, and I don't know Softwire at all.

Thank you both for your answers

[Dark-Cracker]

i think the bicublin resizer was made by MarcFD and the resize filter made by trBarry was SimpleResize is i right remember.

[Wilbert]

Yup, with the former being closed source of course ...

[Soulhunter]

Maybe a dumb question, but...

Whats with ffdshow's numerous resizers?


Bye

[Didée]

Originally posted by Soulhunter
Whats with ffdshow's numerous resizers?
Ah, finally the question was spoken!

Would be nice to port some gauss-, sinc- and spline-resizing from ffdshow to AviSynth. (Spline being my favourite) ;)

There is ffavisynth, okay ... but for basic functions like resizing, that's like screwing a bulb in by turning the table you're standing on :rolleyes: - Plus, custom parametrization from the side of Avisynth is not possible.

[Bidoche]

Originally posted by Didée
Would be nice to port some gauss-, sinc- and spline-resizing from ffdshow to AviSynth. (Spline being my favourite) ;) If they fit in the avs model, ie using the filter to predefine a pattern, it's a piece of cake.
Else it probably won't happen.

[Kurosu]

FFDShow uses SwScaler afaik:
http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/src/convert/Tswscale.cpp?rev=1.9&view=markup
http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/src/mplayer/postproc/swscale.h?rev=1.17&view=markup

Softwire is available under Linux, I even provided a patch to fix its compilation for the CVS version - dunno if it made it to the CVS though.
And some avs2.5x code using it did compile (under Linux), so... You could probably reuse the code directly, provided no heavy design seems required.

I'd suggest to go with avisynth code, while SwScaler would be a plugin if its need arises.

[Mug Funky]

shouldn't "sinc" and "lanczos" be very similar? IIRC the only difference is a windowing function, as they both use a sinc function.

[d'Oursse]

Kurosu: yes, i've seen that. writing resizers would cost nothing.

MugFunky: afaik, lanzos resizers are based on splines

[sh0dan]

lanczos == sinc interpolation

I found a spline algorithm:

Spline16 of Panorama Tools is a cubic-spline, with derivative set to 0 at the edges (4x4 pixels). The weight function thus becomes:
weight = ( ( x - 9.0/5.0 ) * x - 1.0/5.0 ) * x + 1.0; 0<x<1
weight = ( ( -1.0/3.0 * (x-1) + 4.0/5.0 ) * (x-1) - 7.0/15.0 ) * (x-1) ; 1<x<2
Spline36 is like Spline16, except that it uses 6x6=36 pixels. The weight function becomes
weight = ( ( 13.0/11.0 * x - 453.0/ 209.0 ) * x - 3.0/ 209.0 ) * x + 1.0; 0<x<1
weight = ( ( - 6.0/11.0 * (x-1) + 270.0/ 209.0 ) * (x-1) - 156.0/ 209.0 ) *(x-1); 1<x<2
weight = ( ( 1.0/11.0 * (x-2) - 45.0/ 209.0 ) * (x-2) + 26.0/ 209.0 ) *(x-2); 2<x<3

Both should be very easy to integrate into the avisynth resizer.

From this page (http://www.path.unimelb.edu.au/~dersch/interpolator/interpolator.html).

[sh0dan]

Both were added to CVS as Spline16Resize and Spline36Resize. Should be in next version.

[Backwoods]

Originally posted by sh0dan
Both were added to CVS as Spline16Resize and Spline36Resize. Should be in next version.

What would be the exact difference? Greater speed but less precise as Lanczos4Resize?

[IanB]

Sh0dan,

Cool! :cool:

Backwoods,

Similar number of sample points => similar speed.

More points => slower BUT more control of the compromise.

Different interpolation coefficients => different sharpness vrs ringing compromise. A user preference choice

Point => Fast!, aliasing! Chunky graphics.

Bilinear => Quick, blurred and smooth (compresses very well)

Bicubic => Accuracy, control of blur vrs ringing, visually pleasing.

Lanczos(sinc) => High accuarcy, strong sharpening, some but controlled ringing.

Spline => Let the Jury retire to deliberate :D

IanB

[sh0dan]

Spline16 = bicubic speed.
Spline36 = lanczos speed.

I also found the coefficients for "Gaussian" resize. I added it as Gaussresize(). Addidional parameter 'p' = 0.1->100.0, default 30.0 is a sharpness parameter, where p=0.1 is very blurry and p=100.0 is very sharp.

GaussResize speed should be equal to Lanczos4Resize.

Edit: Furthermore I added a 'taps' parameter to LanczosResize, allowing users to have a selectable number of taps, So now you can use:

LanczosResize(320,240, taps=10)
LanczosResize(320,240, taps=3) # Default setting
LanczosResize(320,240, taps=4) # Same as Lanczos4Resize.

Taps is an int from 1 to 100. However settings beyong 4 or 5 is still not recommended.

[IanB]

Shodan is back with a vengence :D

Dude!

IanB

[morsa]

WOW, amazing!! (as always :) )

[gavo]

What does tap mean exactly, How sharp it is?

[IanB]

gavo,

What does tap mean exactly, How sharp it is?

No, taps are how many input points are sampled for each output point, sort of;) (for enlarging it is true, for reducing the relationship is the reciprocal). It effects the accuracy and amount of aliasing. More points also potentially cause more ring ripples.

Sharpness has more to do with the coefficients used with each sampled input point.

IanB