LanczosResize vs. SplineResize

[manolito]

AviSynth 2.56 introduced two new resizers GaussResize and SplineResize. The AviSynth documentation is quite vague about them, and a forum search only came up with some posts saying that Spline36Resize delivers a better quality than LanczosResize, especially when you are upsizing by a high factor.

I would like to hear some opinions about the strengths and weaknesses of these two resizers. Normally I use Bilinear for downscaling and Lanczos or Lanczos4 for upscaling. Is it a good idea to replace Lanczos by Spline36 in all my scripts, or are there situations where Lanczos beats Spline36 in quality?

Mostly I have to resize 480x576 TV captures to 720x576, and a quick comparison between Lanczos4 and Spline36 did not show any visible improvement for Spline36. But maybe this is due to the already limited source quality (analog cable), or to my standard CRT TV set.

Cheers
manolito

[*.mp4 guy]

Spline36 is only very slightly better then lanczos, the difference is not usually vissible with small resizing factors. In your case there would be no real benefit to using Spline36 over lanczos, especially when you consider that you will be encoding to a lossy format that will in all likelyhood get rid of what little differences there would be.

[foxyshadis]

The spline kernels are so much more complex that they're quite a bit slower, so if you have fast scripts don't bother. If they're crazy Didée-ish manifestations, or inside something like LimitedSharpen, you might be able to pull a little more sharpness from a good source without ringing (haloing) and softening that way, but you'd only notice a difference on a sharp source going at least 1.5x-2x up or down.

[MrTroy]

From my post in the MultiSWAR thread:

Original image (1920x816) (http://img124.imageshack.us/my.php?image=original0nf.png)
MultiSWAR(2560,1088) - Lanczos (http://img124.imageshack.us/my.php?image=lanczos5go.png)
MultiSWAR(2560,1088) - Spline36 (http://img124.imageshack.us/my.php?image=spline367nn.png)

Spline36 is a tiny bit more precise.

[manolito]

Thanks guys! :)

Cheers
manolito

[loro]

Which filter do you guys suggest for downsizing? Lanczos, Natural Bicubic, Bilinear is too soft for my taste.

[Daodan]

Well, usually they say for downsizing use a fast one. Still, I usually use spline16resize or 36. Most people use lanczos.

[IanB]

There is no difference in speed between equivalent order Lanczos and Spline resizers, the Gauss Resizer is currently the same speed as Lanczos4.

All resizers use the same lookup table based MMX/SSE code. Speed is directly proportional to the number of taps.

[foxyshadis]

Yes but lanczos uses 4 taps (unless resizing way down), spline16/36 16 & 36 respectively. So there's the speed difference. Unless I'm wrong and you mean spline16=lanczos4 and spline36=lanczos(taps=6) speedwise?

Oh, and out of curiosity, why is there a Mitchell-Netravali filter in the source but unexposed? Just for testing? In other image software it looks about halfway between lanczos and bicubic (presumably it's quite configurable though, being a family of filters).

[IanB]

@foxyshadis, No! The overloadable function ResamplingFunction::support() determines the range for a given resizer. The code samples symetrically left and right upto the value returned.Filter Support Taps
Point 0.0001 1
Bilinear 1 2
Bicubic 2 4
Spline16 2 4
Lanczos 3 6
Spline36 3 6
Lanczos4 4 8
Gauss 4 8The Mitchell-Netravali is used to implement the Bicubic resizer.

[manolito]

Just did a few real world tests using Bicubic(b=0,c=0.6), Lanczos, Lanczos4 and Spline36. I used CCE 2.67 in OPV mode with the standard matrix and tested speed and Q factor. My source was a 115 min PAL TV capture from analog cable (progressive). Capture size was 464 x 576 using Picvideo MJPEG codec. My script was:

AviSource("MyCapture.avi")
AddBorders(8,0,8,0)
xxxResize(720,576)

No filters, no color conversion. I used DVD2SVCD with the D2SRoBa plugin to determine the Q factor. I watched the resulting DVDs with my 28" standard 4:3 CRT TV set (100Hz flicker free).

For quality I have to say that I was completely unable to tell any difference between the resizers. All resizers looked the same to me.


Q factor Speed

Spline36 39 0.54
Lanczos4 40 0.55
Lanczos 39 0.57
Bicubic(b=0,c=0.6) 38 0.58


Conclusion:

There is a difference in speed, but it is not too significant. When more filters are present in the script, the speed difference will be even less.

The Q factor can be used to determine how compressible a clip is. A sharper clip will result in a higher Q factor. It seems that Lanczos4 is sharper than Spline 36, Lanczos is about the same as Spline36, and Bicubic(b=0,c=0.6) is a little less sharp. Of course this does not say anything about the precison of the interpolation.


Cheers
manolito

[sh0dan]

As Ian pointed out, the speed difference is not in the resizer. You are most probably seeing small differences due to CCE having to choose different motion estimation.

Regarding "precision of interpolation". There is no such thing, there are "softer" and "sharper" interpolation methods.

[manolito]

Regarding "precision of interpolation". There is no such thing, there are "softer" and "sharper" interpolation methods.I was referring to something like "visual quality". BilinearResize with a high value for c is extremely sharp, but it is more "crispness" than sharpness, and Lanczos has much fewer artifacts. So I would say that Lanczos has a higher quality and is "more precise".

Anyone about GaussResize? Analyzing resizer algorithms is way over my head, so I would like to hear some opinions from people who are actually using Gauss. How does it compare to Lanczos4 and Spline36?

Cheers
manolito

[Chainmax]

I've compared GaussResize(H,V,p=100) to Lanczos4Resize on several projects and in my opinion p=100 looks sharper than Lanczos4 but artificially so. Bear in mind that my projects all included low detail, severely filtered video though, I have no idea how they compare on more usual scenarios.

[IanB]

Digital sampling theory is best left to the Mathemagicians of this world. The premise "I don't know art, but I know what I like" serves best here.

The rational for Spline is to be as sharp as possible without the ringing Lanczos implies. Lanczos wants to be as sharp as possible without being visually displeasing. Gauss? Hmm, is a strange beast, but it can look very nice sometimes.class GaussianFilter : public ResamplingFunction
...
double support() { return 4.0; };
...
GaussianFilter::GaussianFilter(double p = 30.0) {
param = min(100.0,max(0.1,p));
}

double GaussianFilter::f(double value) {
value = fabs(value);
double p = param*0.1;
return pow(2.0, - p*value*value);
}Above is the guts from the GaussResize() filter. Support dictates 4 tap sampling. P the blur/sharpness parameter can be between 0.1 and 100 (Chainmax want us to play with P=100).

As the lookup table for the resamler is being evaluated, the function f() will be sampled with -4 < value < 4. Here is a table of typical returned valuesvalue f(value)
0.0 1.0
0.25 0.648
0.5 0.177
0.95 0.002 = (1/521)
1.0 0.001
2.0 9.1e-13
3.0 8.1e-28
4.0 0As can be seen only the taps in the -0.95 < T < 0.95 range can contribute usefull weight to the output pixel. At maximum sharpness this filter is almost a point resizer.

An obvious performance enhancment here could be to limit support() based on P and also possibly increase it for low values of P.

[Chainmax]

That looks interesting, if you implement it I'll compare Lanczos4 to Gauss again.

[IanB]

@Chainmax,

Twidling the Support() value based on P won't change the look of the filter (well maybe for very small P, i.e. lots of blur, it might) it might however boost performance significantly.

[Ð.Sp!dér]

Sorry to dig up old threads, but I do have a few questions. Hope you don't mind. :) Also I would like to say Hi since this is my first post on Doom9 and complain about waiting 5 days till I could post... :o I forgot most of my inquiries. Damn.

Recently, MeGUI added support for Gauss, Point, Spline16 and Spline36 even though these were added in AviSynth a long time ago. June according to the first post here :). I know Spline36 is more advanced, so I was wondering what to use for downscaling anime content.

Up untill now, I used "Lanczos (Sharp)" and not Lanczos4. Lanczos4 is a bit too sharp for my taste... Or was I wrong ?

The other thing I was wondering about is why do I need to resize at all. My source is 704x396 and I was told you need to resize to a mod16 resolution for a better compression. At least that's what MeGUI (x264) said. So I was like Ok and choose "Clever anamorphic... blablabla" at a width of 640 so the height was instanlty choosen at 352.

Did I do something wrong ? Is more bitrate allocated on a smaller resolution video stream ? Is there any 'visual' improvement achieved from downscaling animated video content, apart from the height being too small and getting blocky ? I would say 352 pixels are quite acceptable... Anything near 240 is plain horrible.

Also, please note I'm using x264.

I've got a perfect memory so any advice is thoroughly noted, and I will not ask these questions again. :) Sorry for being a n00b. We all gotta start somewhere.

[*.mp4 guy]

Spline36 is very good for downsizing (imo the best downscalar) it has less artifacts than anything else, better aliasing avoidance then bilinear, sharper then bicubic, 99% as sharp as lanczos without the ringing.

reasons to downscale are
-better sharpness/artifacts tradeoff at low bitrates (very low for avc)
-more efficient storage of low spatial resolution content (ie better storage of blurry sources)
-keeping mod 16 resolutions to aid compresion (you can also upscale, if you really don't want to lose pixels)
-keeping a 1:1 pixel aspect ratio for better compatibility and compresion (you can also upscale, if you really don't want to lose pixels)

[Ð.Sp!dér]

Hmm... Thanks for the info.

What about Spline64 ?

[*.mp4 guy]

Well if there is a spline 64 (last time I checked it only went up to spline 36) it would be like the difference between lanczos3 and lanczos4-6, but instead of more pronounced lanczos effects you would get more pronounced spline effects. That said spline36 is completely sufficient for downsizing, higher orders might help a bit with upsizing though.

[Alain2]

Is more bitrate allocated on a smaller resolution video stream ?
You choose the bitrate you want, depending on the file size you want. bitrate = kilo bits per second. So if for the same bitrate you encode at a lower resolution, then it's easier for the codec as there is less pixels (end therefore information) to encode.

It's all a trade-off.. bitrate determines the final size of your encode (knowing the time length of your clip and the bitrate gives you the size). The bitrate being what you give to the codec, depending on its performances and the compressibility of your source (a clean source is easier to encode than one with losts of temporal noise for instance), you can estimate the resolution the codec will be able to handle at the given bitrate. For the case of x264, increasing resolution may not appear very bad initially but you may loose lots of details compared to a lower resolution encode even if it's not blocky. You'll have to do some tests to get more experience...

[HeadBangeR77]

I've just discoverd I had subscribed to this thread once. :D

Here are my semi-amatuer observations; I've just digged up some old samples with screenshots and made some new ones in addition. The comparison was/is between Lanczos3 (default taps), Lanczos4, Gausse 30/60/100, as well as Spline16 and 32.

To my eyes they seem almost the same while watching, with the exception of Gausse30 and 60, that are way too soft for my real movie content. Soft as they are, they could be of use for some other sources, but I ruled them out almost at the beginning. There's a small difference in the filesize, which tends to repeat itself. It goes like:

Gausse100 < Spline36 < Lanczos4 < Lanczos3.

Gausse100 (I had to take a closer look at screenshots to discover this) seems a bit softer, so that would explain a tad smaller filesize. Spline36 has probably less artifacts, but staring for a long time at the screen I wasn't able to confirm that. Why a theoretically sharper Lanczos4 differs from theoretically softer Lanczo3, I haven't got the faintest idea. The differene, although small, was there in every encode.

And the last remark: Gausse100 distorts the image, believe me or not!!! Since it's an AviSynth resizer I've tried many older versions, and now I'm using 2.5.7 final, though the effect remains. You may not notice while just watching, but comparing screenshots the distortions are easy to mark. If you want me to post screenshots, no problem.

cheers,
HDBR77

PS. Spline36 is slower than both Lanczos3 and Lanczos4 - I don't know the internal routines of those resizers, and I don't want to, since I'm just a user, but the difference is noticeable, though rather small (I've given up my plans to replace Lanczos3 with Spline36 in Didee's functions :p).

[HeadBangeR77]

Old and new screenshots are mixed together, so to rule out false samples or bugs in software. On some of them the mentioned distortions are almost invisible, on the other however they get me a headache (easily spotted at fullscreen).

http://xasonline.info/headbanger/ResizingComp.rar

cheers.

[Ð.Sp!dér]

...for the same bitrate you encode at a lower resolution, then it's easier for the codec as there are less pixels (end therefore information) to encode.
I thought it was something like that. That's why I asked. :) Thanks for clearing it up.

I found this very interesting guide:
http://www.path.unimelb.edu.au/~dersch/interpolator/interpolator.html
I will definitely be using Spline36 for downscaling.

There's a small difference in the filesize, which tends to repeat itself. It goes like:

Gausse100 < Spline36 < Lanczos4 < Lanczos3.

Gausse100 (I had to take a closer look at screenshots to discover this) seems a bit softer, so that would explain a tad smaller filesize.
No, I think you saved the screenshots in JPEG format. Wich adds compression. So if the image was more 'compressable', then it's obvious the filesize will be small. Next time save it as Bitmap for a better comparision. ;)

[HeadBangeR77]

No, [b]I think[b] you saved the screenshots in JPEG format. Wich adds compression. So if the image was more 'compressable', then it's obvious the filesize will be small. Next time save it as Bitmap for a better comparision. ;)
Plz, before you even think, check first next time (gosh!)

1) I was talking about my sample-encodes at constant quantizer mode, and I've done hundreds of those. Think that's enough to mark the difference, especially when the pattern repeats itself every time, like described above.

2) My screenshots are in png format, so they're lossless (see my first sentence).

3) You've mentioned sth by accident, which is not entirely true. Actually, while converting from a lossless format like e.g. bmp into another lossless format like e.g. png (think of it as zip used on a graphic format), you could judge on the amount of information on the given screenshot. When one comes from a sample/movie done with exaclty the same avs, apart from denoising, then the denoised one will contain less info and the final png will be a tad smaller. It's the other way round while sharpening.

4) I always use png-plugin for conversion, usually 4-passes, so the image is as packed as possible.

[IanB]

And the last remark: Gausse100 distorts the image, believe me or not!!! Since it's an AviSynth resizer I've tried many older versions, and now I'm using 2.5.7 final, though the effect remains. You may not notice while just watching, but comparing screenshots the distortions are easy to mark....At maximum sharpness this filter (Gauss) is almost a point resizer.Gauss is a pure averaging filter, so lacks negative coefficients in any sampling, hence you don't get any antialiasing. Compare it to PointResize, the effect is related.

Reread this post (http://forum.doom9.org/showthread.php?p=844748#post844748) for some more insight.

PS. Spline36 is slower than both Lanczos3 and Lanczos4 - ... but the difference is noticeable, though rather smallHmmm I find this strange, Spline36 should be the same speed as Lanczos3. Lanczos4 should be the same speed as Gauss and slightly slower. Speed should only be related to the number of Taps.

[HeadBangeR77]

Gauss is a pure averaging filter, so lacks negative coefficients in any sampling, hence you don't get any antialiasing. Compare it to PointResize, the effect is related.

Reread this post (http://forum.doom9.org/showthread.php?p=844748#post844748) for some more insight.
I'm neither mathemagician (;)) nor skilled at the easiest functions, but I will never use Gausse. They distortions look awfully - looking at the same frame some elements are squeezed horizontally and some vertically, so the proportions are **** up. Being a quality freak I have no other possibility but to rule such a resizer out (and I had hoped it might be useful).

Hmmm I find this strange, Spline36 should be the same speed as Lanczos3. Lanczos4 should be the same speed as Gauss and slightly slower. Speed should only be related to the number of Taps.
I've marked so mariginal difference between Lanczos3 and Lanczos4, that it's even not worth mentioning. Yet Spline36 was slower than the mentioned two (I'm sure I used the same avs - it was done for testing of the resizers).

cheers,
HDBR77

[Piper]

4) I always use png-plugin for conversion, usually 4-passes, so the image is as packed as possible.

Kindly, which png-plugin are you referring to?

[HeadBangeR77]

Kindly, which png-plugin are you referring to?
There's a pngout.dll, that comes with IrfanView plugins package, dated May 2005, by Ken Silverman. The default is "unlimited passes", but it isn't worth the time spent, 3-4 are enough.

Btw. The plugin is slooow, but does its job. :)

[Terranigma]

bicubicresize, imo is the best resizer. If you want sharp, you can adjust the c parameter.

Lanczosresize can be configured to be sharper than spline36resize by increasing the number of taps. Max number of taps is 100,
But increasing the number of taps that high can have negative effects, like smudging on the left and right sides of a frame.

You can make bicubic sharper than taps=100 without the smudging. So My vote's for bicubic. :angry:

[Chainmax]

Unless you are talking about subjective personal preferences, you are wrong. According to Wikipedia:

Spline interpolation is preferred over polynomial interpolation because the interpolation error can be made small even when using low degree polynomials for the spline. Thus, spline interpolation avoids the problem of Runge's phenomenon which occurs when using high degree polynomials.

Which, if I understand correctly, means that from a theoretical standpoint Spline-based resizing should be better than any bicubic flavor.

[Terranigma]

OK, Thanks for the analogy. I tried looking up splineresize over at wikipedia not too long ago but did'nt find an article, (I did'nt do a thorough enough search perhaps?) so I never knew the mathematics that was involved in that resizer. I started off using spline16, but then switched over to bicubic. I guess that was a bad move. :D

[Piper]

There's a pngout.dll, that comes with IrfanView plugins package, dated May 2005, by Ken Silverman. The default is "unlimited passes", but it isn't worth the time spent, 3-4 are enough.

Btw. The plugin is slooow, but does its job. :)

Thanks!

[Ð.Sp!dér]

Just look at the pretty pictures: http://www.path.unimelb.edu.au/~dersch/interpolator/interpolator.html

You'll see why Spline36 is better. ;) The last resizer used in the test was using 265 pixels wich is considered cheating. :) It does indeed provide MUCH better results, but at what speed cost ? I would say 10-15 times more slower then Spline16 wich could be a real PITA encoding 150999 frames, don't you think ?

Spline36 is better then Lanczos. This also varys from source to source... Spline36 is my favorite.

[IanB]

People, you seem to be missing a point here.

All of the Tap based resizers are a compromise! You the user must choose which resizers works best for you with a given image. Note! 2 variables here a) The person, b) The image.

E.g HeadBangeR77 (sorry not picking on you, just an example) didn't like the artifacts from Gauss(p=100) and blindly states he will never use Gauss. I really can't blame him, as a general purpose resizer Gauss has problems, particularly with large P. But the issue is there are a small number of cases where Gauss will be the ideal resizer. So by dismissing it out of hand forever, you loose something.

All I am saying is each resizing algorithm favours a set of parameters, try to learn the visual appearance and consequence of each and make an informed choice for the image you are currently processing.

[Chainmax]

Just look at the pretty pictures: http://www.path.unimelb.edu.au/~dersch/interpolator/interpolator.html

You'll see why Spline36 is better. ;)
...

I think that test is flawed as IMO they should have used lossless or uncompressed image formats, not JPEG+GIF.

[foxyshadis]

I think that test is flawed as IMO they should have used lossless or uncompressed image formats, not JPEG+GIF.

I think that's actually an awesome test. What's important isn't what they used, but simply how well what they put in matches what they got out, whether details or artifacts, and the differences are so obvious that no detailed analysis is needed of the individual pixels, so saving as jpeg doesn't invalidate it. (Agreed png never hurts, but still.) I think it's a very novel sort of test, especially the concentric rings ones, and I wonder how mp4 guy's recent investigations into fft-based resize would look, pressed into such service.

[check]

All of the Tap based resizers are a compromise!

Is this implying there's a Better Way to Do It(tm)? I saw the review above, I'm guessing it's something along the lines of the sine transform they exhibited?

[HeadBangeR77]

All of the Tap based resizers are a compromise! You the user must choose which resizers works best for you with a given image. Note! 2 variables here a) The person, b) The image.

E.g HeadBangeR77 (sorry not picking on you, just an example) didn't like the artifacts from Gauss(p=100) and blindly states he will never use Gauss. I really can't blame him, as a general purpose resizer Gauss has problems, particularly with large P. But the issue is there are a small number of cases where Gauss will be the ideal resizer. So by dismissing it out of hand forever, you loose something.
I don't feel offended in any way. :D ;)
But I've done what you seem to describe here:
a) I'm a quality freak, as I have stated, so I would like the image to be as sharp as possible and free of distortions.
b) I only encode regular movies, sometimes videoclips.

And I went from Gausse30 through various middle values up till p=100, just to come to conclusion that this resizer ain't for me. However ... I saw a primitive, yet funny videoclip once, png video, very small resolution, which looked best at full screen with the nearest neighbour resizing. :D

As to Spline - I did some sample encodes yesterday, Lanczo3, Lanczos4, Spline36 and Bicubic (0,0.6) and was really pleased with Spline at the first look. I must yet examine the samples more thoroughly.

cheers,
HDBR77

[foxyshadis]

Is this implying there's a Better Way to Do It(tm)? I saw the review above, I'm guessing it's something along the lines of the sine transform they exhibited?

Lanczos(taps=8) is a Sinc256. I haven't experimented very much with the excessively higher order filters for simple resizing, although for a single operation it's most likely total overkill.

The only good way with anything subjective like this is to just stack them all, and pick your favorite. Comparing how they look by then viewing fullscreen via a media player is even better.

However ... I saw a primitive, yet funny videoclip once, png video, very small resolution, which looked best at full screen with the nearest neighbour resizing. :D

That's the funny thing, 3-4x up of a very sharp source looks so bad on tap-based resizers that point is a worthwhile solution - at least until we can get EEDI2 running in realtime. =p

[*.mp4 guy]

Well I can't rotate with the function I'm working on (I have no clue how to implement it either, so unless someone else knows how to do it, it ain't gonna happen). However I used that image in some upsizing tests, which showed the differences between resizers pretty well. Its important to keep in mind that the concentric rings test doesn't show the amount of haloing and ringing a resizer causes, it only shows how well they avoid aliasing and how well they keep detail just below the nyquist limit, results can be a little skewed, but still quite interesting.

2taps-2reps (http://file.pixilis.com/upload/20070208/10093.png)
2taps-4reps (http://file.pixilis.com/upload/20070208/10087.png)
4taps-4reps (http://file.pixilis.com/upload/20070208/10086.png)
4taps-8reps (http://file.pixilis.com/upload/20070208/10088.png)
(note, more then 3 reps on real world content looks horrible)
(also note that the 4tap-8rep sample was enlarged 2x with dctlimit, then 2x with spline36 do to ram limitations on my machine)

lanczos-3taps (http://file.pixilis.com/upload/20070208/10089.png)
lanczos-4taps (http://file.pixilis.com/upload/20070208/10090.png)
lanczos-48taps (http://file.pixilis.com/upload/20070208/10091.png)
spline-3taps(aka spline36) (http://file.pixilis.com/upload/20070208/10092.png)

[edit] The 2taps-2reps sample was incorrect, its fixed now, the old version didn't have dehaloing aplied, which made it sharper, but not usefull for more realistic situations.

[DeathTheSheep]

Lanczos(taps=8) is a Sinc256.
So, if someone resized a 640x480 source to 320x240 with lanczos(taps=8), it would be the "most accurate" or "best" resize, according to that test.

How can this possibly be?! :)

[IanB]

@DeathTheSheep,

No, I doubt you could see the difference on almost any real world image. For a 2:1 downsize almost any resizer will do an "acceptable" job. Each resizer will have a characteristic distortion that each person will classify as being more pleasing or less pleasing for a given image.

As a rule of thumb most people prefer a sharp image, to the point of having the dark to light gradients sharper than they would be in real life, often even right up to the point of obvious ringing.

The mind set for BiCubic, Spline and Lanczos is to exploit this with differing limits on the sharpness/ringing compromise.

Lanczos makes a choice for you to be as sharp as possible with a small amount of, hopefully unnoticable, ringing. The assumption is real life images are band limited and do not have step changes of brightness so the ringing won't be noticable allowing the sharpness compromise to be pushed even harder. The base Lanczos3 uses 6 sampling points, the general case uses 2*N sampling points. With more sampling points comes theoretically more accurate resampling but also more ringing ripples.

Spline makes a choice for you to be as sharp as possible without actually ringing. Spline36 uses 6 sampling points, Spline16 uses 4 sampling points.

Bicubic exposes the B and C coefficients in a polynomial expression to the users so the favourite choice of sampling formula can be made when using 4 sampling points. For each resize ratio there will be a particular value of B and C that will give the same resampling results as Spline16.

To see the effect for each resizer try this test scriptBlankclip(1, 39, 39, color=$101010)
Addborder(1,1,1,1, $E0E0E0)
Addborder(24,24,24,24, $101010)
Last+Invert()
A=BilinearResize(128, 128)
B=BicubicResize(128, 128)
C=Spline16Resize(128, 128)
D=Spline36Resize(128, 128)
E=LanczosResize(128, 128)
F=Lanczos4Resize(128, 128)
G1=GaussResize(128, 128, p=0.1)
G2=GaussResize(128, 128)
G3=GaussResize(128, 128, p=100)
H=LanczosResize(128, 128, Taps=8)
I=BicubicResize(128, 128, 0, 1)
J=BicubicResize(128, 128, 1, 0)
Interleave(A,B,C,D,E,F,G1,G2,G3,H,I,J)For the enthusiastic also try the script with a larger input Blankclip(1, 231, 231, color=$101010) to test the effect in downsizing.

[foxyshadis]

Not best for resizing, but best for rotating, which is a different beast. And note the image used is not the sort you'll encounter in video, it's just a test pattern to experiment on.

I think higher-order lanczos actually looks pretty decent, mild haloing and all, it's just slow. Really liking how DCTlimit deals with the 4x+ domain, though, right now it has a sort of super-lanczos look to it instead of the more crystally EDI/GFI/PZoom2 look, though that can be obtained as well.

(Also note that when Ian mentions # of pixels sampled, he means in each direction, because it's run once in each direction.)

[HeadBangeR77]

@ IanB:
Since you seem to know whole lot more than I do in these matters, I'm gonna "torture" ;) you with few questions, if you don't mind. ;)

So basically by small downsizing, like in my screenshots somewhere on the previous page (NTSC, 16:9 anamorphic widescreen, from 853/873x368 to 720x304), I shouldn't see much difference, if at all, between e.g Spline36, Lanczos3 and Lanczos4? I mean if we take some extreme examples, like Gauss with low p-values and Lanczos4, the difference was easily noticed. However between those three mentioned first I couldn't notice any difference even from still frames, no to mention watching.

Then what is a threshold, after reaching which we could spot potential differences rather easily, providing we're dealing with real films and sharp image? According to your words by 2:1 downsize it shouldn't matter much, and what about an upsize with similar proportions?

Thanks for your patience in explaining things. :)
cheers,
HDBR77

[IanB]

Yes as you have noticed the difference between the different resizers can indeed be very subtle. In many cases you will need to use the Subtract filter with a large amount of Levels adjustment to find these differences. And even when you know where the differences are they can be quite hard to find when just looking at one image. This is not surprising, apart from PointResize the aim is to provide the most accurate interpolation value possible. Gauss and BiCubic with extreme tuning parameters expectadly violate this concept, one assumes sensible values are in use.

As for a numerical threshold value, I can't give you one. I know if you have a large step change in brightness over 1 pixel, like in my test script, you will easily see the different artifacts for each different resizer. As you soften the step in either amplitude or range of pixels the artifacts will become less noticable, when they vanish depends on the persons vision.

Fortunatly real life images do not have this characteristic, the most severe brightness change will always take place over a few pixels. In extreme cases you might notice an artifact and need to revise your choice of resizer.

When downsizing an image you are discarding information, the compromise is which information to discard. i.e. keeping sharp boundaries at the expense of accurate position of edges.

When upsizing there is no such information discarding. The compromise is how best to interpolate each gradient to simulate the missing new information.

[HeadBangeR77]

:thanks: for clarifying.

[Caroliano]

Changing a bit the focus of the topic, what is the best upsizer when considering the compressability and ringing production at the encoder? The bilinear resize is generaly regarded as the better one when downsizing, at the expense of sharpness, but improving the quality at an fixed low bitrate. Though, it is not recomended at all for upsizing, so the answer is probably another one.

[HeadBangeR77]

Do you mean up-sizing by using a resizer or some of them Didee's magic scripts? ;) To stay in the topic, I usually use Lanczos (Lanczos3), because other scripts/functions I use are full of Lanczos. Hence using anything else could lead to ... yeah, the question is, what would it cause? I just want to stay compatible. ;)