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. ;)

[foxyshadis]

Well, bilinear just plain looks terrible beyond 20-50% upsize. Diagonal/curve breakup everywhere, even besides the fuzziness; a little higher and it breaks up into nothing but cute little stars of light. :D

So that's out, but the other ones hold up pretty well. Once you get near 100% spline and lanczos are the only ones that look pretty decent, and they can actually look acceptible at 4:1 and beyond. Under 100%, any of them look decent, even bicubic, and it just depends on how you want the sharpness/artifacts to look.

Compressibility is related almost entirely to visual sharpness. Abnormally high bicubic/gauss are the worst, then lanczos->spline->bicubic->bilinear as you'd expect. The encoding rarely cares about edge-ringing, in fact the total lack of it will be harder to compress, but very minimally.

[DeathTheSheep]

Ah, so from a compressibility standpoint, spline36's lack of substantial visible edge-ringing doesn't, in the end, positively affect compressibility.

Well, I tried a simple 2:1 sinc resize (which looks quite different from lanczos(taps=8) actually...), and the ringing was so terrible that the compressed filesize was substantially bigger than lanczos8 but still managed to look like trash afterwards (worse than the source, since it seemed to preserve ringing only in very annoying places...)

[*.mp4 guy]

Its important to keep in mind that there are several things that effect an interpolators compressability.

-detail preservation
-aliasing
-haloing
-excessive ringing (it has to be very bad before it makes any difference)

All lower compressability.

-bluring
-detail removal (not the same as bluring, look at nedi for an example)
-accuracy (in the bitdepth sense, basically keeping gradients well)
-high ability to remove/avoid enhancing source artifacts

All raise compressability.

In the end you are almost always best served by simply using the best interpolator you can and then using something like frfun7+degrainmedian to boost compressability if its necessary.

@DeathTheSheep: spline does ring, its just 1- at 3taps almost nothing rings, and 2- splines ringing degrades very quickly the further it is from the sample point that caused the ringing, so it is always in very small localised spots, and doesn't travel away from the line the way polynomial interpolation like lanczos would.

[Caroliano]

Lets see what I understod:

- There is not much diference at all between them (perhaps excluding bilinear) for small (10~20%) upsizes?

- An "soft bicubic" would be the best for compressability? If it is, what setting would be good, without smooth too much? I never tweaked any resizer.

- Or an spline36resize would have better quality in the end, being more precise but less compressible? Lanczos seems to be the worst choice for compressability.

And for minimal resizes, like getting back to mod16 after an crop(4,0,-4,-2) or so? All, inclusive bilinear, behaves equally good? There is any diference between anime or realife fotage when comparing these simple resizers?

[foxyshadis]

Anime makes mild haloing much more obvious, so spline36 is even more preferred. Otherwise it doesn't change much.

For really tiny resizes, you're right that they're nearly indistinguishable, any other processing you do will completely overpower it.

If you want to see how bicubic's parameters change things, try using this with AvsP:

BicubicResize(1024,480,[<"b", 0.00, 1.00, 0.33>],[<"c", 0.00, 1.00, 0.33>])

Lower b and higher c is sharper, and vice versa. Both 1.0 is roughly nearest neighbor, both 0.0 is bilinear. It's hard to see how they work together to change the character without a really huge upsize, though.

[IanB]

High brighness gradients (visual sharpness) are the worst enemy of compression for DCT based codecs. It takes lots of bits to accurately represent a sharp gradient.

This is at odds with what the original authors of most resizing algorithms had in mind when they created their progeny. They want a high degree of sharpness because that looks nicest.

From an intent point of view the approximate sharpness order of resizeing algorithms would be :- Lanczos(taps >=4)
Spline64 (Not implemented)
Lanczos3
Blackman (Not implemented)
Spline36
BiCubic(Large C)
Spline16
BiCubic(Large B)
BiLinear
Gauss(small P)Of course things like 8 bit arithmetic, personel preference and original image quality effect what happens in reality.

[foxyshadis]

Spline64 (Not implemented)

*sidle sidle nudge*

Is it hard to generate the constants for higher-order splines? Is it possible at all to generate them on the fly, for multitap like lanczos? (Translating higher math into code and vice versa is beyond me.)

[IanB]

I have a set of coefficients, supposedly for Spine64, but the resulting filter does not conform to the expected performance of a spline interpolation. In short the filter rings noticably, hence I assume the coefficients I have are wrong. Spline is supposed to be as sharp as possible but have no overshoot or ring.

If someone has references on how to do Spline64 I'm listening.

[Didée]

Spline is supposed to be as sharp as possible but have no overshoot or ring.
With "no", do you mean "no" or "almost no"?

Check:
version()
stackvertical(last,last.invert())
spline36resize(width*2,height*2)

It is not "no", it's only "little":

Ringing is really veryvery little (better to see with x8 upsizing instead x2), but the overshoot is obvious.

[IanB]

@Didée,

Yes the overshoot is obvious and present but less with Spline16 as well.

From my research Spline is supposed to be ....

Sh0dan implemented Spline[13]6 and the formulae he has used corresponds with what I have found in my quest for Spline64.

I suspect reality does not match the sales broshure.

I guess it is fairly forgivable seeing the razor sharp edges concerned have frequency components well in excess of the nyquist frequency.

[*.mp4 guy]

The main benefit of splines is that the error rapidly decreases away from the data point that caused the error, which allows for large tapsizes without large increases in ringing. Since I have never seen an image interpolated with high tap splines I'm not sure how well they work in "real" conditions, but in synthetic data point interpolation examples that I have seen they have always performed much better then polynomial interpolation.

[Chainmax]

So which one of these:

http://xs312.xs.to/xs312/07082/rszsttgs.png (http://xs.to)

would you use for resizing on playback then?

[*.mp4 guy]

I would use 4tap lanczos with awarpsharp as a post processor, spline is uncomfortably slow for realtime playback.

[DeathTheSheep]

Since the speed of the avisynth implementation of spline36 seems on par with the lanczos4, I would simply insert a spline36resize() in the script and play the script back in a compatible player (any DS player seems to work).

About spline64, is it harder to implement than spline16 or 36 (from a technical standpoint)?

PS: What is blackman? It sounds kinda racy :)

[foxyshadis]

Blackman (or Blackman/Hanning) is just yet another algorithm, pretty similar to Bicubic b=.9 c=.75. Very, very blocky, but consequently very sharp for downsizes.

[*.mp4 guy]

Extra information for the inquisative: Blackman/Hanning (and a slew of others) are general purpose frequency seperation methods that can be aplied to a variety of different situations, they are also used, for example in audio processing to remove, reduce or enhance certain frequency ranges. Infact most "tap" based interpolators are really all based on the same methadology, the implementation is the interesting part. In audio processing such algorithms are called "finite impulse response" filters, or lowpass/highpass/bandlimiting filters, whereas in video they are usually just reffered to as interpolators, since their other functions are infrequently directly used in video applications.

[psme]

I'm setting up my new HTPC with a Core Duo E6600 overclocked to 3.2G.

In the past I always used lanczos4 with Andy's preview version of FFDShow.

Last night with the new PC I tried spline36 in avisynth. It seems a bit better picture quality in realtime DVD playback.

I'm upscaling to 1920x1080 to my new Sony VW50 1080p projector.

More test later.

Btw, *.mp4 guy, I tried your "MultiSWAR" for upscale but it's very very SLOW. I seems to get a frame for a few seconds!

regards,

Li On

[DeathTheSheep]

He's making an "upgrade" to MultiSWAR perhaps, according to a certain hint (http://forum.doom9.org/showthread.php?p=950985#post950985) earlier in this thread. :)

Are there any plans to implement spline64 in avisynth, or is there simply no need to do so (meaning spline36 is as sharp as it goes with least tradeoffs)?

[Caroliano]

:thanks:

[HeadBangeR77]

@ Chainmax:
I haven't got the faintest idea how they implemented it in ffdshow directly, nor whether it's Spline36 or some other version, but in my case it seems to work almost as fast as Lanczos4 (very negligible difference of 0-5% of CPU usage, at first look at least). And it looks well. :)

[IanB]

I have checked into CVS a (new) Blackman and a Spline64 experiment.

The Blackman is another algorithm Blackman came up as opposed to the more common Blackman/Hanning. It is a modification to Lanczos that has better control of ringing artifacts for high numbers of taps. w = sinc(x) / (0.42 + 0.5*cos(x/taps) + 0.08*cos(2*x/taps))As opposed to the standard lanczos' w = sinc(x) * sinc(x/taps)

The Spline64 rings a lot more than I was expecting so I suspect the coefficients I found are wrong.
if (value < 1.0) {
return (( 49.0/41.0 * (value ) - 6387.0/2911.0) * (value ) - 3.0/2911.0) * (value ) + 1.0;
} else if (value < 2.0) {
return ((-24.0/41.0 * (value-1.0) + 4032.0/2911.0) * (value-1.0) - 2328.0/2911.0) * (value-1.0);
} else if (value < 3.0) {
return (( 6.0/41.0 * (value-2.0) - 1008.0/2911.0) * (value-2.0) + 582.0/2911.0) * (value-2.0);
} else if (value < 4.0) {
return ((- 1.0/41.0 * (value-3.0) + 168.0/2911.0) * (value-3.0) - 97.0/2911.0) * (value-3.0);
}If anyone has a further information....

[*.mp4 guy]

It would be easier to tell if anything was wrong with the spline 64 interpolation (and what it might be) if you made a version with it available for testing. I found some fortran code for spline interpolation on google a while ago, I don't know if it would be usefull or if I could find it again, but I'll look for it and see what I find.

[foxyshadis]

Sorry, I was going to have one earlier, but a movie called... >.>

http://foxyshadis.slightlydark.com/random/newresizers.zip

The extent of my testing was "it compiled and didn't crash", but it seems to do what it's supposed to. (There's some butchered avisynth guts inside it, but it'll only add Spline64Resize and BlackmanResize as new functions.) Blackman takes the same taps parameter as lanczos.

[Terranigma]

foxyshadis thanks for the new resizers. You've definately earned your stripes as a team member. Just curious, what version of vs.net do you use when compiling these filters, 2005?

[Terranigma]

The Spline64 rings a lot more than I was expecting so I suspect the coefficients I found are wrong.

I'll do some experiments using foxyshadis's resizers on sources where the ringing would be very noticeable and let you know how it goes.

Edit:
Ok, Here are the screenshots:

Bicubic (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/Bicubic.jpg)
Bicubic Sharp (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/BicubicSharp.jpg)
Bilinear (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/Bilinear.jpg)
Blackman (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/Blackman.jpg)
Gauss (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/Gauss.jpg)
GaussP0 (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/GaussP0.jpg)
GaussP100 (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/GaussP100.jpg)
Lanczos (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/Lanczos.jpg)
Lanczos4 (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/Lanczos4.jpg)
Lanczos8Taps (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/Lanczos8Taps.jpg)
Lanczos100Taps (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/Lanczos100Taps.jpg)
Point (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/Point.jpg)
Spline16 (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/Spline16.jpg)
Spline36 (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/Spline36.jpg)
Spline64 (http://i162.photobucket.com/albums/t269/Terranigma26/Doom9Stuff/Spline64.jpg)

I haven't noticed any ringing with foxyshadis's Spline64 and Blackman resizers. Perhaps I should do another test on a real life source, preferably HD.

You guys can judge the results above for yourself. The "Source" was from the Anime Series "Noir" (DVD)

Edit 2:
Wow! Today I decided to change the blksize in mvdegrain2 from 8 to 4, and use Spline64Resize instead of 36, and I've noticed a speed increase in my processing as well. These are some really fast resizers. So looks like i'll be sticking to spline64 and mvdegrain2 with a blksize of 4 :D

[*.mp4 guy]

Spline64 looks like its working to me, didn't ring noticibly, but didn't really look any better then spline36. Blackman looks about the same as lanczos.

[foxyshadis]

Wow! Today I decided to change the blksize in mvdegrain2 from 8 to 4, and use Spline64Resize instead of 36, and I've noticed a speed increase in my processing as well. These are some really fast resizers. So looks like i'll be sticking to spline64 and mvdegrain2 with a blksize of 4 :D

A speed increase? That's odd. tsp compiles his with 2003, and I don't see what'd make a difference compared to 2005 (SP1), but compilers are strange, cranky little beasts. Oh well, glad it worked.

mp4 guy, did you try something crazy, like 10 taps? Or 100? =p

[*.mp4 guy]

I tried the default taps, and 8 taps with blackman, it looked about the same as lanczos with similar settings.

[Wilbert]

@IanB,
The Spline64 rings a lot more than I was expecting so I suspect the coefficients I found are wrong.
Could you tell me how these Spline16/36/64 coefficients are derived? I was looking on wikipedia, but apparently you have a lot of choices. I guess they are all cubic here and you should take a kxk grid (k=4 for Spline16) and match the 0th, 1st and 2nd derivatives?

[Terranigma]

@IanB,

Could you tell me how these Spline16/36/64 coefficients are derived?
I think I found something here (http://csourcesearch.net/data/package/enblend/enblend-2.2/include/vigra_ext/Interpolators.h) :)

[Wilbert]

I think I found something here
That link only gives the coefficients, it doesn't tell how they are derived.

[Terranigma]

That link only gives the coefficients, it doesn't tell how they are derived.

Is This (http://www.reference.com/browse/wiki/Spline_%28mathematics%29) better? :)
Also, a Link (http://www.reference.com/browse/wiki/Interpolation) of interpolations including Spline.

[Wilbert]

I appreciate you are willing to help, but i have studied math and know a bit about splines. As you might know there are different kinds of splines, each with its own assumptions/restrictions. I would like to known what restrictions are posed on the cubic polynomials as used in SplineXX in order to derive the used weights. That information is not given in your links.

[DeathTheSheep]

I wonder if there are technical papers about the polynomial derivations themselves. If so, they might not be so easily found online. At a university math library, perhaps?

Regardless, the spline64 plugin does indeed have the characteristic "spline" look, little ringing, and a sharper image than spline36. It seems roughly the same speed as spline36, if not slightly slower on my system, but this is to be expected.

I have yet to evaluate Blackman/Lanczos filter, though...

[IanB]

The "...include/vigra_ext/Interpolators.h" was one of the places I found these coefficients. I was hoping to avoid colouring the discussion by not revealing that as the values used are unreferenced and unproven.

What I have found for a Spline64 implementation.
There are 4 polynomials each symetically used in the intervals [0,1], [1,2], [2,3] & [3,4].
f(x), f'(x)=dx/dy and f''(x)=d'x/dy are all equal at the crossover points 1, 2 & 3 for the respective pairs of polynomials.
f(0)=1, f'(0)=0, f''(0)=0
f(4)=0, f'(4)=0, f''(4)=0
These are not enough constraints. There is an infinite family of sets of polynomials that satisfy the above.

More please.

[Terranigma]

IanB, what're your thoughts on the Spline64 and Blackman filters foxyshadis contrived? Do you get any noticeable ringing that you've mentioned earlier from the Spline64 resizer?

[foxyshadis]

Ian has his own avisynth compiles, he doesn't need me to compile his code for him. =ppp

[IanB]

@Terranigma, To clarify I added the code to the standard internal resizers and dropped it into the CVS, foxyshadis harvested that, deleted all the existing old resizers and produced a freestanding plugin.

My personal opinion:-
PointResize doesn't count here.
GaussResize is a usefull special effect.
BilinearResize is good for shrinking.
In most cases all the rest of the resizers look the same!
In extreme cases for Anime I lean towards Spline16.
In extreme cases for "Live content" I leaned towards Lanczos3, current flavour of the month is Blackman(taps=4 or 5)As I said my preference for my images.

[DeathTheSheep]

I find they look largely the same too, and in fact share the very same opinion as IanB in terms of resizer applications.

However, I must add that for compression purposes (especially for mobile devices), these filters have drastic effect (even on a simple 2:1 downsize). The tiny increases in sharpness or differing artifacting, even though it may be perceptually unnoticeable, may have drastic impacts on compression, especially at low bitrates and low resolutions.

Which is why, of course, the different implementations of interpolation technology are infinitely to me as a compressor of very low-bitrate, low resolution content for mobile devices (and not-so-mobile devices as well). :)

[IanB]

Well compressibility is a whole extra trickey thing. Very (very, very) approximatly for a DCT based codec you want the fourier transform of the block to be sparse (i.e. have lots of zeros).

Sharpness sort of corresponds to high frequencies, images are going to have low frequencies, so ditching the high frequencies is a good thing for compressibility.

Firetrucks are red, your car is red, therefore is a firetruck type of thinking.

Mapping generalizations between the spacial and frequency domains is fraught.

So I probably should add a 3rd variable to my very original statement. You!
The image.
The application

[*.mp4 guy]

Bilinear resize is compressable becuase it removes many frequencies below the nyquist limit for any given input resolution and and any given output resolution that doesn't equal the input resolution, however it also is worse at removing frequencies above the nyquist limit, which makes using a high quality frequency domain resizer or discrete vector based resizer a better substitute for the resizing step, as I have said before there isn't any reason you couldn't make the result as compressable as bilinear after resizing has been acomplished, and doing that should let you keep more detail and have less aliasing. If however you are using bilinear becuase of its speed, there will never be a faster resizer that can equal bilinear for compressability.

[Wilbert]

The "...include/vigra_ext/Interpolators.h" was one of the places I found these coefficients. I was hoping to avoid colouring the discussion by not revealing that as the values used are unreferenced and unproven.

What I have found for a Spline64 implementation.
There are 4 polynomials each symetically used in the intervals [0,1], [1,2], [2,3] & [3,4].
f(x), f'(x)=dx/dy and f''(x)=d'x/dy are all equal at the crossover points 1, 2 & 3 for the respective pairs of polynomials.
f(0)=1, f'(0)=0, f''(0)=0
f(4)=0, f'(4)=0, f''(4)=0
These are not enough constraints. There is an infinite family of sets of polynomials that satisfy the above.
Are you sure about that? Let's consider Spline16 and throw in some math:

fj(x) = aj*x^3 + bj*x^2 + cj*x + dj; j=0,1,2,3 (in [0,1], [1,2], [2,3] & [3,4])
fj'(x) = 3*aj*x^2 + 2*bj*x + cj
fj''(x) = 6*aj*x + 2*bj


f0(0)=1 => d0 = 1
f0'(0)=0 => c0 = 0
f0''(0)=0 => b0 = 0

thus f0(x) = a0*x^3 + 1 (1)

f3(4)=0 => a3*64 + b3*16 + c3*4 + d3 = 0
f3'(4)=0 => 3*a3*16 + 2*b3*4 + c3 = 0
f3''(4)=0 => 6*a3*4 + 2*b3 = 0

b3 = -12*a3^2
c3 = -48*a3 - 8*b3 = -48*a3 + 96*a3^2
d3 = -64*a3 - 16*b3 - 4*c3 = -64*a3 + 192*a3^2 -4*(-48*a3 + 96*a3^2) = 128*a3 - 192*a3^2

thus f3(x) = a3*x^3 - 12*a3^2*x^2 + (-48*a3 + 96*a3^2)*x + 128*a3 - 192*a3^2 (2)


So for f0 and f3 we have two unknowns: a0 and a3.

Let's have a look at the first crossover:


f0(1)=f1(1) => a0 + b0 + c0 + d0 = a1 + b1 + c1 + d1 => a0 + 1 = a1 + b1 + c1 + d1
f0'(1)=f1'(1) => 3*a0 + 2*b0 + c0 = 3*a1 + 2*b1 + c1 => 3*a0 = 3*a1 + 2*b1 + c1
f0''(1)=f1''(1) => 6*a0 + 2*b0 = 6*a1 + 2*b1 => 6*a0 = 6*a1 + 2*b1


These can be solved for (b1,c1,d1), keeping one linear equation in (a0,a1). So a0 and a1 are undetermined here. The second crossover can be expressed as linear equation in (a1,a2) and the last one in (a2,a3). So you end up with three linear equations in four unknowns.

So in the end, if you choose a0, all other coefficients are fixed and can be determined.

If i have some more time i will do this.

Btw, if i look at
http://csourcesearch.net/data/package/enblend/enblend-2.2/include/vigra_ext/Interpolators.h
i see that for example w[0](x=0)=0, w[3](x=3)=6.8. It's not exactly the same as what we are doing above. Will check this later.

[MfA]

That's an awful lot of text to end up agreeing with him Wilbert ;)

BTW just to point out the obvious, there is a big difference between interpolation and resizing ... especially for reducing resolution. Assuming you have a good interpolator you should really blur your image before using the interpolator to reduce the resolution.

[IanB]

An infinite family of curves, which is about where I got to. And yes, I am not really sure about anything. Perhaps if I step back and explain what I am seeing you may be able to fill in some blanks.

Spline16 has 2 equations [0,1] & [1,2]
Spline36 has 3 equations [0,1], [1,2] & [2,3]
Spline64 has 4 equations [0,1], [1,2], [2,3] & [3,4]
Each cubic segment is "normalized" from [0,1] into it's respective segment [j, j+1].
Each segment must join seemlessly to the next, hence the 1st and 2nd derivative matching constraints.
The 1st segment has to join to a reflection about x=0 of itself. Thus the f0(0)=1 and f0'(0)=0 are certain, the f0''(0) is not.
The last segment joins to a y=0 segment. Thus the fn(n+1)=0 and fn'(n+1)=0, not so sure about the fn''(n+1).
The logic seams to be to replace an infinite series of sinc(x) with small set of splines choosen to supply the missing "weight" from the truncated terms of sinc(x)


So probably you should start with the equation in this form :-
fj(x) = aj*(x-j)^3 + bj*(x-j)^2 + cj*(x-j) + dj; j=0,1,2,3

@MfA, Snap!

All resizing is all about interpolation. The fundamental is what is the value of the point between 2 others.

[Terranigma]

I find they look largely the same too
Yes, they look very similar, but they're not. Take a look at the screenshots here (http://photocreations.ca/interpolator/index.html) and compare. Also take a look Here (http://www.uni-koblenz.de/~puma/dox-main/puma/html/SamplingSpline_8cc.html) as well. ;)

[MfA]

All resizing is all about interpolation. The fundamental is what is the value of the point between 2 others.
I disagree ... all samples have footprints in the original continuous 2D image you are sampling, interpolators will try to approximate samples at different locations than in the original image but with the same footprint (or in frequency domain terms, which I don't think are appropriate, you want the spectrum of the of the image to stay the same). When you are resizing you also want to change the footprints of the samples (or in frequency domain terms, which I don't think are appropriate, you want to limit/extend the spectrum).

Now that is not to say an algorithm can't try at the same time to interpolate and to blur or sharpen, but it's not really a pure interpolator anymore at that point.

Interpolators are often tested by iterative rotation (which I don't think is entirely appropriate either, but regardles ...) if your algorithm blurs or sharpens that will quickly become a mess.

[MfA]

Looked around a bit and AFAICS the coefficient values are all just ad-hoc and all trail their lineage from the panorama tools source code. There are sets of coefficients which are provable optimal for approximating a signal upto it's 2nd order Taylor expansion (maximum possible) but those aren't it.

[DeathTheSheep]

...I recall that De Boor's algorithm can be used to evaluate B-spline curves (values in the intervals of interest) from combining base splines, but how that would be useful for this filter...

Wikipedia gives an interesting list of references, but needless to say, I haven't checked them out http://en.wikipedia.org/wiki/Spline_%28mathematics%29.

[Wilbert]

Looked around a bit and AFAICS the coefficient values are all just ad-hoc and all trail their lineage from the panorama tools source code.
I figured out how they are derived and will post about it tomorrow! I can't say I agree with the way they did it though.

[MfA]

You have to be rather tricky to use b-splines for interpolation, because they don't go through their control points (you end up having to do IIR filtering before you can interpolate). The spline16-64 filters do not use b-splines.

If anyone feels like trying the "optimal" coefficients (in the Taylor expansion sense) this paper (http://karton.student.utwente.nl/00560787.pdf) has them for an arbitrary number of taps.

[DeathTheSheep]

The paper states that monotonically decreasing coefficient magnitutes with larger kernel lengths (tending to infinity!) gives less nth degree error.

So then what does "kernel" mean in this sense?

[Henrikx]

Perhaps this is also interesting for you.
ResizeTest : Upsize/Downsize by Selur
http://gleitz.info/wiki/index.php/Welcher_Resize-Filter_%3F
(German)
Testpicture (Downsize)
http://www.heise.de/ct/ftp/testbilder/kameras_0621/

[MfA]

So then what does "kernel" mean in this sense?
For each increase in length you add one extra cubic section on both sides of the kernel, an extra lobe so you will.

[DeathTheSheep]

Henrikx: Wow, these tests (especially upsizing the 'O') have managed to reaffirm my preference towards high splines.

MfA: I see...! Is this how you found the coefficients for your spline64 experimental plugin?

[MfA]

No, it's Wilbert who said he found out how they were calculated ... as I said before, the ones in the splineX filters are not these ones.

[DeathTheSheep]

Ah, sorry--must have missed that :o

[Wilbert]

No, it's Wilbert who said he found out how they were calculated ... as I said before, the ones in the splineX filters are not these ones.
That statement was a bit premature :(

My approach was to work backwards, see what conditions those polynomials satisfied and to recompute the weights of these polynomials.

As everyone can check (by differentiating the polynomials), for Spline16/36/64 the following conditions are satisfied (Spline_k^2):

wj(x) = aj* + bj*x + cj*x^2 + dj*x^3; x in [0,1] (for all x in [0,1] and j=0,..,k-1):

w0(0) = 0, w0(1) = 0, w1(0) = 0, w1(1) = 1, w2(0) = 1, w2(1) = 0, w3(0) = 0, w3(1) = 0 (a)

w0'(0) = -w3'(1), w0'(1) = -w3'(0), w1'(0) = -w2'(1), w1'(1) = -w2'(0) (b)

w0''(0) = w3''(1), w0''(1) = w3''(0), w1''(0) = w2''(1), w1''(1) = w2''(0) (c)

The equations above are for k=4 (Spline16), but the extension to arbitrary k is obvious.

As you can see these are 8 + 4 + 4 = 16 equations, and since we have 16 unknowns (aj,bj,cj,dj for j=0,1,2,3), the system should be solvable. At least that's what i thought yesterday, but i guess these equations are dependent, since i wasn't able to solve for the unknowns.

So we need some additional constraints, but i have no clue which ones. I guess i need to ask my colleagues on sci.math about this.

Two remarks about the constraints above:

1) As you can see the constraints don't connect all the equations. The constrains connect w0(x) and w3(x), and also w1(x) and w2(x), BUT strangely NOT w0(x) and w1(x). I think this is very bad, but i'm not sure what the consequences are.

2) The first derivative constraints: w0'(0) = -w3'(1). This is also very bad. The cubics have to be connected in a smooth way (which can be enforced by the constraints), but they are not. I bet that this causes the ringing that some people see.

Anyhow, on http://mathworld.wolfram.com/CubicSpline.html they give a correct derivation of cubic splines (they show how to solve for the bj coefficients). Solving for the remaining cj/dj coefficients shouldn't be that difficult. I will report about it very soon ...

[MfA]

The papers say making the sections C2 continuous is enough to get a unique solution (a non optimal one) and I'm inclined to believe them. I'm too lazy to actually do the math (they already give the solution, both for optimal kernels and C2 continuous ones ... I chose to just believe them on their word on those). I checked the continuity of the splineX kernels too though, since they aren't even C1 continuous I don't think this will get you anywhere as far as determining how the SplineX kernels were derived. I think I'll have to go back to my original statements, they are completely ad hoc.

Ringing is an integral part of any linear filter with negative taps, regardless of continuity.

[twolfe18]

i just jumped in on this thread like dspider, and i just wanted a bit more detail.

for me, i do mainly conversion of hdtv (mostly 1080i), and i usually downscale to 1024x576. i have noticed the ringing you talk about with lanczos and lanczos4, but do these hold an advantage at higher resolutions?

basically, what is the best hi-res downscaler?

[foxyshadis]

From earlier this thread...

http://forum.doom9.org/showthread.php?p=956474#post956474
http://forum.doom9.org/showthread.php?p=957735#post957735
and the most important of all,
http://forum.doom9.org/showthread.php?p=950801#post950801

Such issues are the same no matter what you resize, but the higher the output resolution, the less noticeable any artifacts are.

[DeathTheSheep]

I was thinking SplineX might be using coefficients chosen by visual trial and error, rather than mathematical nth degree derivative continuity ("optimal" method).

So either:
1. The developers simply don't know what they're doing
2. The developers genuinely thought their version produced better results
3. We're missing something-- perhaps there's a more complicated answer.

Either way, it would be very interesting to see how splineX's implementations match up with the mathematically optimal ones.

[IanB]

Yes the splines are not smooth. Sorry for the confusion in assuming the spline segments were 2nd order smooth.

My current guess is the splines are chosen to most strongly match the segments of a particular, as yet undiscovered, truncated sinc function. Although not identical to the Blackman sinc function, they are surprisingly very close, one would have to suspect the rational for each is related.

[Wilbert]

3. We're missing something-- perhaps there's a more complicated answer.
I think it is this one. I added the Spline resizers given at mathworld (http://mathworld.wolfram.com/CubicSpline.html) to the package of foxyshadis. Usage:

Spline16WResize()/Spline36WResize()/Spline64WResize()

Some early observations:

1) Spline16WResize blurs like hell. Which makes me really curious about Spline16Resize, because it is so much better.

2) Spline36WResize / Spline36Resize have about the same quality.

3) Spline64WResize / Spline64Resize have about the same quality, but both are less sharp as Spline36WResize / Spline36Resize.

Tell me what you think about it:

http://www.savefile.com/files/530858

[Terranigma]

thanks wilbert. checking them out now :goodpost:

[wonkey_monkey]

I'm just having a quick look at resample_functions.cpp, and I'm a little confused - shouldn't the number in the spline function correspond to the number of pixels in the window? For example, spline64filter considers values of value from -4 to 4, making an 8x8 window of 64 pixels - as I'd expect. But spline16wfilter also considers value from -4 to 4, which is still 64 pixels, not 16...

Spline36wfilter seems to be using a window size of 144... and so on. Sorry, I've probably missed something important earlier in the thread, but it's something of a pet subject for me.

David

[Wilbert]

I'm just having a quick look at resample_functions.cpp, and I'm a little confused - shouldn't the number in the spline function correspond to the number of pixels in the window?
Yup.

For example, spline64filter considers values of value from -4 to 4, making an 8x8 window of 64 pixels - as I'd expect.
I'm confused. I didn't notice it, but it only uses four equations and not eight! (As far as i can see, they are not symmetric around zero.)

IanB, foxyshadis what did you do with the other equations from this page (http://csourcesearch.net/data/package/enblend/enblend-2.2/include/vigra_ext/Interpolators.h)? Thus w2,w3 for Spline16, w3,w4,w5 for Spline36, etc ...

[wonkey_monkey]

They are symmetrical, and that's why there are only four equations, because you use the absolute value of value to choose an equation.

In resample_functions.h all four functions return a value for support of 4 - shouldn't that be 2 for the spline16s and 3 for the spline36s?

David

PS:

1) Spline16WResize blurs like hell. Which makes me really curious about Spline16Resize, because it is so much better.

I think I might know why that is - with the current equations, the spline shoots up to >1 at around ±3.8 (it should go to, and stay at, 0 once it gets to ±2).

[Wilbert]

They are symmetrical, and that's why there are only four equations, because you use the absolute value of value to choose an equation.
If you plot them you will see that they are not symmetrical, but perhaps i'm missing something.

In resample_functions.h all four functions return a value for support of 4 - shouldn't that be 2 for the spline16s and 3 for the spline36s?
Yup, thanks! That solves the blurring problem of Spline16W!

[DeathTheSheep]

Here are some screens downsized 2:1 and then upsized again with pointresize:

Spline16:
http://gabe.ezhostlive.uni.cc/spline16.PNG
Spline16w:
http://gabe.ezhostlive.uni.cc/spline16w.PNG

The visual evidence certainly does seem to support this conclusion :)

[DeathTheSheep]

Spline64WResize / Spline64Resize have about the same quality, but both are less sharp as Spline36WResize / Spline36Resize.
I'm not so sure about that--to my eyes, Spline64Resize definitely does seem sharper than Spline36Resize, and resulting filesizes (encodings) are bigger with it, which is a pretty good indication of sharpness, too.

PS: Any chance for re-uploading the "fixed" package? Thanks!

[wonkey_monkey]

If you plot them you will see that they are not symmetrical, but perhaps i'm missing something.

That's exactly what I did :) :

http://horman.net/graph.png

The dark blue line shows where spline16w shoots out of range. Red is the spline16 I use, taken from http://www.all-in-one.ee/~dersch/interpolator/interpolator.html

If you have a single parameter, and always use its absolute value, you'll always have a symmetrical graph (if the functions weren't symmetrical, you'd get different results applying the filter to mirrored image pairs).

David

[DeathTheSheep]

In that plot, am I correct to assume the steep, light-blue line represents spline64?

[DeathTheSheep]

Very interesting differences between spline64 and spline64w I found:
http://gabe.ej.am/compare.PNG
I resized to 128x128 via the splines, then resized up to 512x512 with pointresize.

[wonkey_monkey]

My current guess is the splines are chosen to most strongly match the segments of a particular, as yet undiscovered, truncated sinc function. Although not identical to the Blackman sinc function, they are surprisingly very close, one would have to suspect the rational for each is related.

At the bottom of the interpolator page I linked to above is an example of a sinc function truncated (windowed) to 16 pixels (±8 pixels). I've always assumed the spline functions were chosen to approximate sinc functions windowed to 4 (spline16) and 8 (spline64) pixels in order to speed up the calculations.

It's also stated on that page that the sinc function used there is the theoretical optimum.

In that plot, am I correct to assume the steep, light-blue line represents spline64?

Correctamundo... a word I have never used before and hopefully never will again.* What was the original image?

David

* 10 points if you can identify the quote ;)

[MfA]

It's also stated on that page that the sinc function used there is the theoretical optimum.
There are a lot of optimums.

Sinc is optimum if the signal was band limited and of infinite extent and you want to either resample that band limited signal (for translation/rotation/upsizing) or you want to further band limit that signal and resample the result (note that you have to adapt the period of the sinc function in this case, since it has to act as a brick wall filter too).

Problem is that in our case signals are neither of infinite extent, nor are we terribly interested in point sampling perfectly band limited signals (because they tend to ring).

[DeathTheSheep]

Image: http://www.all-in-one.ee/~dersch/interpolator/z256.GIF (on the page you linked to :)).
I also noticed that the splineW filters aren't accurate on the final pixel (the last pixel column in the image's width). Can anyone reproduce this?

* David Tennant. Doctor Who; season 2, episode 3: "School Reunion."

[*.mp4 guy]

The theoretical optimum sinc function does not ring, its the aproximations of it that ring, the ringing is caused by imperfect frequency separation, which is inevitable when using linear equations to aproximate sinc functions, there aren't any sinc functions that can be adequately modeled by linear equations, not even non-optimal ones.

[Wilbert]

@davidhorman,

Sorry, i was misunderstanding you. All i was asking is what happened with w2/w3 for Spline16? Four equations are listed in your link. I assumed it was for a value range 0..4 (w0 for [0,1], w1 for [1,2], w2 for [2,3] and w3 for [3,4]) and not for -2..2. Could you elaborate on this?

@DeathTheSheep,

Here: http://www.savefile.com/files/532402

Very interesting differences between spline64 and spline64w I found:
So, more details in Spline64w are visible right?

[wonkey_monkey]

Oh right, I didn't realise you'd scaled it down :rolleyes:. Strangely though, this is what I get when I use my implementation of spline16 (based on what's on that page):

http://horman.net/myspline.png

Looks quite a bit different... what you posted looks very similar to what I get if I gaussian blur before scaling down (again, using my own implementation, not AVS).

David

[wonkey_monkey]

@davidhorman,

Sorry, i was misunderstanding you. All i was asking is what happened with w2/w3 for Spline16? Four equations are listed in your link. I assumed it was for a value range 0..4 (w0 for [0,1], w1 for [1,2], w2 for [2,3] and w3 for [3,4]) and not for -2..2. Could you elaborate on this?

I'm not sure where you see four equations in that page - for spline 16, two equations are listed, one for the range [0,1] and one for the range [1,2]. Beyond that, all weights are 0. Between them, and taking the absolute values, they cover the range [-2,2] (that's five pixels, but at least one of the outer weights will always be 0, so you end up with a 4x4=16 pixel window).

David

[Wilbert]

I'm not sure where you see four equations in that page - for spline 16, two equations are listed, one for the range [0,1] and one for the range [1,2].
I should have checked your link before saying this. I was referring to this link:

http://csourcesearch.net/data/package/enblend/enblend-2.2/include/vigra_ext/Interpolators.h

equations:

/** spline16 interpolation */
struct interp_spline16
{
// size of neighbourhood
static const int size = 4;

/** initialize weights for given @p x */
void calc_coeff(double x, double * w) const
{
w[3] = ( ( 1.0/3.0 * x - 1.0/5.0 ) * x - 2.0/15.0 ) * x;
w[2] = ( ( 6.0/5.0 - x ) * x + 4.0/5.0 ) * x;
w[1] = ( ( x - 9.0/5.0 ) * x - 1.0/5.0 ) * x + 1.0;
w[0] = ( ( -1.0/3.0 * x + 4.0/5.0 ) * x - 7.0/15.0 ) * x;
}
};

[Terranigma]

Oh right, I didn't realise you'd scaled it down :rolleyes:. Strangely though, this is what I get when I use my implementation of spline16 (based on what's on that page):

http://horman.net/myspline.png

Looks quite a bit different... what you posted looks very similar to what I get if I gaussian blur before scaling down (again, using my own implementation, not AVS).

David

davidhorman, could you post a ddl link for the spline16 resizer you implemented? :D

[MfA]

The theoretical optimum sinc function does not ring, its the aproximations of it that ring, the ringing is caused by imperfect frequency separation, which is inevitable when using linear equations to aproximate sinc functions, there aren't any sinc functions that can be adequately modeled by linear equations, not even non-optimal ones.
A sinc filter works for resampling because it's also a brick wall filter ... do you know what happens when you apply a brick wall filter to a step function? (You can do this analytically, no need to approximate anything.)

[*.mp4 guy]

I know what happens when you apply a non optimal aproximation of a brick wall filter to a step function, and I know that the errors that causes are a result of the inaccuracies of the aproximation, hence why more accurate aproximations have less of them, but thats besides the point, sinc functions aren't aplicable to step functions,(depending upon how you define them, you could argue that an image matrix is a step function, but that isn't true, in reality images are made of varyingly sized gradients and they only resemble step functions when discretely sampled, in this case the use of a sinc function would be to reconstruct the gradients of the original image) step functions have no gradients, and so frequency domain representation would be pointless.

[IanB]

{
w[3] = ( ( 1.0/3.0 * x - 1.0/5.0 ) * x - 2.0/15.0 ) * x;
w[2] = ( ( 6.0/5.0 - x ) * x + 4.0/5.0 ) * x;
w[1] = ( ( x - 9.0/5.0 ) * x - 1.0/5.0 ) * x + 1.0;
w[0] = ( ( -1.0/3.0 * x + 4.0/5.0 ) * x - 7.0/15.0 ) * x;
}Note: for Interpolater.h the equations are symetrical, i.e. w[0] -> -w[3] and w[1] -> -w[0]

You need to reverse the segment bias from each equation to recover the original cubic spline like is done in the Avisynth implementation. if (value < 1.0) {
return ( ( value - 9.0/5.0 ) * value - 1.0/5.0 ) * value + 1.0;
} else if (value < 2.0) {
return ((-1.0/3.0*(value-1.0)+4.0/5.0)*(value-1.0)-7.0/15.0)*(value-1.0);
}substitute (1-x) for x in w[2]

w[2] = ( ( 6.0/5.0 - x ) * x + 4.0/5.0 ) * x;
= -x^3 + 6/5*x^2 + 4/5*x
= -(1-x)^3 + 6/5*(1-x)^2 + 4/5*(1-x)
= x^3-3*x^2+3*x-1 + 6/5*x^2-12/5*x+6/5 - 4/5*x+4/5
= x^3 + (-15/5+6/5)*x^2 + (15/5-12/5-4/5)*x +(-1+6/5+4/5)
= x^3 - 9/5*x^2 - 1/5*x + 1
w[1] = ( ( x - 9.0/5.0 ) * x - 1.0/5.0 ) * x + 1.0;

[MfA]

I know what happens when you apply a non optimal aproximation of a brick wall filter to a step function, and I know that the errors that causes are a result of the inaccuracies of the aproximation
Have you never done "approximate these functions with the first X elements of it's fourier series" type of assignments? (With step, block, saw functions etc) You can do these analytically, and they are examples of what happens when you brick wall filter signals.
step functions have no gradients, and so frequency domain representation would be pointless.
The fourier series is an infinite one, in the limit case it can represent steps perfectly well.

How about this. Is a discretely sampled image with a line at X = 0 (value = 1 at X = 0, value = 0 everywhere else) a valid image in your opinion? (IMO it's physically possible and as such valid.) If not, why not?

[wonkey_monkey]

davidhorman, could you post a ddl link for the spline16 resizer you implemented? :D

I doubt you'd be able (or want) to do much with it - it's a set of completely undocumented functions for the manipulation of TGAs. I just used the spline16 coefficients as described at http://www.all-in-one.ee/~dersch/interpolator/interpolator.html

I suspect the difference between my results and DTS's is that my interpolator considers coordinates of pixel centers, but the AVS interpolators may only consider the coordinates of pixel corners - that would explain a) why a lot of detail is gone (I get the same result if I translate by half a pixel before scaling) and b) why AVS may get the last row/column wrong (though I can't see anything wrong myself - it may reflect rather than go to black to mitigate such problems).

David

[MfA]

Are you sure it's not the other way around? AVS considers pixel centers ... but that tends to blur things since you never leave pixels intact.

[*.mp4 guy]

@mfa In my opinion that is not a real image, for one absolutely no one would be able to see the difference between black and black+1 on a computer monitor. Its a valid piece of data, but it is not an image in the sense I was using the word, I feel completely safe saying that no perfectly pixel aligned (as in a vertical line reprented by a perfectly vertical row of pixels, I have never seen such a represntation of a line in any image, ever, excluding cg images), noise free, perfectly focused image of a perfect line drawn by a perfectly frequency cohesive laser, in a vacum, has ever been taken, and if it was the operator would have had to have a relative velocity of 0 to the photographed target, which is impossible, even if everything else were not also impossible. If the line were not drawn by a laser (in a light free environment no less) then light difraction, ambient light, etc. would cause obvious problems.

[Wilbert]

Note: for Interpolater.h the equations are symetrical, i.e. w[0] -> -w[3] and w[1] -> -w[2]

You need to reverse the segment bias from each equation to recover the original cubic spline like is done in the Avisynth implementation.
Ah, thanks!

So my implementation is correct, but what i called Spline16w is actually Spline64 (but with different coefficients), as davidhorman said?

[IanB]

@davidhorman,

The AVS interpolator is designed to maintain the center of the image during resizing. You can use the croping arguments to override this.

The edge condition for the resizer is to repeat the edge pixel. This has been wrong in versions prior to 2.5.7 where the trash byte out the right and bottom were used (often black).

@Wilbert,

Do you have a URL for where you got your equations from Mathworld (or directions where to click) for the SplineW resizers.

[Wilbert]

@Wilbert,

Do you have a URL for where you got your equations from Mathworld (or directions where to click) for the SplineW resizers.
See the link in this post:

http://forum.doom9.org/showthread.php?p=965802#post965802

I calculated them from http://mathworld.wolfram.com/CubicSpline.html

[MfA]

as in a vertical line reprented by a perfectly vertical row of pixels, I have never seen such a represntation of a line in any image, ever, excluding cg images
Sigh, okay so lets take a vertical line at X = 0 with value 255 and 0 everywhere else and lets say it's a cg generated image ... are you willing to admit then that no matter how large you make the image (all the way upto infinite extent) and no matter how perfect the sinc filter you use the resampled image will always have ringing?

[*.mp4 guy]

Nope, with a line like that I would use a 2X2 windowed sinc function, which cannot ring on perfectly vertical lines (only halo). Anyway, with a sufficiently slow (precise) sinc function you could push the ringing error below the decimation error of the 8 bit colorspace of the output, using any window size. sinc functions that can actually be implemented will always cause ringing, but that ringing can be lost in decimation by using a sufficiently imprecise colorspace, or a sufficiently precise sinc function.

[wonkey_monkey]

Are you sure it's not the other way around? AVS considers pixel centers ... but that tends to blur things since you never leave pixels intact.

Duh, sorry, I don't know what happened but I now can't replicate that weird swirly pattern - I'm getting a similar result to AVS now!

See, this is why I don't think people should have my code - it only causes confusion and brainaches ;)

David

[MfA]

Nope
I'll just pretend you answered my question here rather than avoid it entirely.

You are wrong, if I resample the image with an ideal sinc filter the value I get at a given X will be the value of the original sinc function at -X multiplied by 255. Since the original sinc function rings, so will the resampled image.
with a line like that I would use a 2X2 windowed sinc function, which cannot ring on perfectly vertical lines (only halo).
Well good for you, you realize the sinc filter is far from ideal and you need to use something else in practice.
Anyway, with a sufficiently slow (precise) sinc function you could push the ringing error below the decimation error of the 8 bit colorspace of the output
For this to be true any value of the sinc function outside of the origin would have to be <1/512 with 8 bits color resolution. You can not accomplish that ... the sinc function you have to use for resampling doesn't have any free parameters. It's amplitude is fixed by the fact it has to be 1 at the origin, and its frequency is fixed by the distance between the new samples.

About decimation, that word doesn't mean what you think it means.

[IanB]

Decimation:- Roman era, to kill every tenth person. :D

[*.mp4 guy]

I'm begining to get the impression that you haven't got a clue what causes ringing when frequencies are removed and you have thus convinced yourself that its just an inevitable side effect of sinc functions in general. You also seem to be operating under the false impression that sinc functions all have the same amount of ringing.

[edit] I do know what decimation means, its discarding information in a keep, drop, keep, etc. pattern. When you drop frames, that can be reffered to as decimating, similarly when you take X+1 bits of information and fit it into X bits, thats decimation, since every other possible value from the original is kept.

[DeathTheSheep]

So, more details in Spline64w are visible right?
From the looks of things, yes.
So my implementation is correct, but what i called Spline16w is actually Spline64 (but with different coefficients)...?
That's an interesting question.

Doesn't AVISynth resize horizontal and vertical components of the image separately (i.e. resizes the longest dimension first, then resizes the other)?

[IanB]

Do you have a URL for where you got your equations from Mathworld (or directions where to click) for the SplineW resizers.See the link in this post:

http://forum.doom9.org/showthread.php?p=965802#post965802Yes this gives me your source code from http://www.savefile.com/files/532402 -> newresize_04032007-2.zip

Which has your code that is not driving the the generator correctly. I was hoping an original reference might allow me to understand your intent and fix the code. Currently you have double the number of equations needed and there is not enough information to work out which half is correct.
I calculated them from http://mathworld.wolfram.com/CubicSpline.htmlAnd this point to a page with text that startsA cubic spline is a spline constructed of piecewise third-order polynomials which pass through a set of control points. The second derivative of each polynomial is commonly set to zero at the endpoints, ...Which is a great explanation of how to join cubic splines for C2 smoothness, but doesn't explain how you chose your curves.

So how did you derive/where did you get the equation?

[foxyshadis]

Talking about image resamplers with pathological cases is not a useful discussion for practical uses. If you hand a resizer a known pathological case, you get a pathological result, that should be obvious. I assume that's why mp4 guy doesn't care to discuss it.

Nonetheless, it does come up in photography, as digital cameras can often have discrete transitions from smooth to a 1 or 2 pix solid line back to smooth, with no transition period. Naturally, it actually does ring when you attempt to resize, but how else are you going to do it?

It still isn't a terribly useful question, since the result is already known.

[MfA]

The sinc function is sin(x)/x, when used as a filter the only thing which can vary is it's period (ie. x is scaled). That period is uniquely determined by the distance between samples if you want to get a critically sampled image (ie. not aliased, and not unnecessarily low pass filtered). There is no variation possible. You can of course window it however you like ... but the result will never be a sinc filter.

Basically it's really simple, if you apply a linear filter with an impulse response which rings to a signal you get ringing around edges. It's that simple, ringing in -> ringing out. It's an unavoidable property of linear filtering.

Foxyshadis, how else? Non-linear filtering obviously.

[DeathTheSheep]

Some interesting (if irrelevant) filesize results with a CQ encode in AVC:
spline16w: 8162KB (!!!)
spline36w: 7825KB
spline64w: 7938KB

spline16: 7808KB
spline36: 7949KB
spline64: 7952KB

As expected, the sharper the image, the larger the encode at constant quantizer (no B-frames, exhaustive motion search).
However, there is a very strange outlier in this data: spline16w. I re-encoded all clips just to be sure of this phenomenon.

[*.mp4 guy]

The sinc function is sin(x)/x, when used as a filter the only thing which can vary is it's period (ie. x is scaled). That period is uniquely determined by the distance between samples if you want to get a critically sampled image (ie. not aliased, and not unnecessarily low pass filtered). There is no variation possible. You can of course window it however you like ... but the result will never be a sinc filter.

Basically it's really simple, if you apply a linear filter with an impulse response which rings to a signal you get ringing around edges. It's that simple, ringing in -> ringing out. It's an unavoidable property of linear filtering.

Foxyshadis, how else? Non-linear filtering obviously.
Before you can perform the sinc filtering you have to separate the frequencies, which is what I was getting at. The fourier series is commonly used to separate frequencies before performing a sinc function on them, but they are unoptimal and often cause lots of ringing, there are better ways to perform the seperation, the DCT performs mildly better then the fourier series, but is also much slower. The simple sinc function you refer to is not actually the optimal one (it is only optimal when fed perfect imput data), the optimal one is achieved by performing a KLT transform on every datapoint individually, adjusting the size of the transform to match the available data points, then performing a brickwall filter on the frequency coeficients of the KLT transform of each pixel, then performing the inverse KLT. Because the KLT transform has perfect frequency separation there will be no ringing, just a gradual loss of sharpness near the edges as the available transform size decreases. However the KLT transform is an NP class problem, so performing it at full accuracy is for all purposes impossible, instead you have to perform it at sufficient accuracy for your destination colorspace, which will still be insanely slow.

Talking about image resamplers with pathological cases is not a useful discussion for practical uses. If you hand a resizer a known pathological case, you get a pathological result, that should be obvious. I assume that's why mp4 guy doesn't care to discuss it.

Nonetheless, it does come up in photography, as digital cameras can often have discrete transitions from smooth to a 1 or 2 pix solid line back to smooth, with no transition period. Naturally, it actually does ring when you attempt to resize, but how else are you going to do it?

It still isn't a terribly useful question, since the result is already known.
Yep, but I am interested in pathalogical cases, just only when they are actuall images, not specialty data sets.

[MfA]

The fourier series is commonly used to separate frequencies before performing a sinc function on them
I have no idea what this even means ... but as long as it's common you should be able to give me a couple of citations to explain it.
Because the KLT transform has perfect frequency separation
No it doesn't. It has perfect decorrelation, but the basis functions it uses are not even necessarily all periodic and of increasing frequency.

Why are you doing this? Nothing good will come from just making stuff up on the spot.

[DeathTheSheep]

Why is this discussion even happening? Who cares about the sinc-function (or KLT transform) in this thread anyway? Take it to another thread, my friends :).

[*.mp4 guy]

Why is this discussion even happening? Who cares about the sinc-function (or KLT transform) in this thread anyway? Take it to another thread, my friends :).

Ok, fine by me.

Mfa, this isn't personal, don't try to change that.

[Wilbert]

Which is a great explanation of how to join cubic splines for C2 smoothness, but doesn't explain how you chose your curves.

So how did you derive/where did you get the equation?
Ok, here's the derivation from http://mathworld.wolfram.com/CubicSpline.html :
For now i just compute the numbers, but if you want a derivation of equation 18, i will give it to you.

I put (a0,a1,a2,a3) = (1,0,0,0). I'm not sure whether that's correct, but ok ...

1) Equation 18 says A*b = y with

A = [[2, 1, 0, 0], [1, 4, 1, 0], [0, 1, 4, 1], [0, 0, 1, 2]]

b = [[D0],[D1],[D2],[D3]] (with Di = bi, see equation 7)

and

y = 3*[[a1-a0],[a2-a0],[a3-a1],[a3-a2]] = 3*[[-1],[-1],[0],[0]]

Solving for Di in equation 18 gives (with yi = ai, see equation 6):

A^(-1) = ([[26, -7, 2, -1], [-7, 14, -4, 2], [2, -4, 14, -7], [-1, 2, -7, 26]])/45

b = A^(-1) * y = [[-19/15], [-7/15], [2/15], [-1/15]]

Equation 8 says:

c = y2 + C*b

with

C = [[-2, -1, 0, 0], [0, -2, -1, 0], [0, 0, -2, -1], [-1, 0, 0, -2]]

y2 = 3*[[a1-a0],[a2-a1],[a3-a2],[a0-a3]] = 3*[[-1], [0], [0], [1]]

and

c = [[c0],[c1],[c2],[c3]]

Substituting everything gives:

c = [[0], [4/5], [-1/5], [22/5]]

Equation 9 says:

d = - 2/3*y2 + C2*b

with

C2 = [[1, 1, 0, 0], [0, 1, 1, 0], [0, 0, 1, 1], [1, 0, 0, 1]]

and

d = [[d0],[d1],[d2],[d3]]

Substituting everything gives:

d = [[4/15], [-1/3], [1/15], [-10/3]]

Ok, so above we solved for (ai,bi,ci,di). Thus

Yi(t) = ai + bi*t + ci*t^2 + di*t^3

and thus

Y0(t) = 1 -19/15*t + 4/15*t^3
Y1(t) = -7/15*t + 4/5*t^2 - 1/3*t^3
Y2(t) = 2/15*t - 1/5*t^2 + 1/15*t^3
Y3(t) = -1/15*t + 22/5*t^2 - 10/3*t^3

Btw, in the code i use wi=Yi and x=t.

I hope it's a bit clear :)

[DeathTheSheep]

Spline16w produces--by far-- the sharpest image of all the included splines visually. It also produces the largest files under compression (see previous post).

All this leads me to ask whether spline16w is actually a 4-point spline at all, and if so, what makes it so obscenely different from the much-weaker normal spline16resize()?

[MfA]

Why does Wilbert's spline16w have support 2 when it can take values upto 4? (I know it was bugged with support upto 4, but it doesn't make much sense to keep the higher lobes in there now.)

Also it's rather strange that the 2nd lobes of the original spline16 and spline16w are identical.

[wonkey_monkey]

Why does Wilbert's spline16w have support 2 when it can take values upto 4? (I know it was bugged with support upto 4, but it doesn't make much sense to keep the higher lobes in there now.)

Those extra equations are now redundant - I'm sure Wilbert will get around to removing them from the source eventually :)

Also it's rather strange that the 2nd lobes of the original spline16 and spline16w are identical.

This makes me wonder if the "W" splines were only constructed as one-sided and then reflected instead of taking into account the necessary zeroes on the other (negative) side, which is why it meets at a point instead of flattening out at [0,1]. The straight lines make it practically bilinear for the nearest pixels.

As for why spline16 is sharper, I think it follows from these facts: the nearest two pixels will always have positive weights - this causes some softening. The furthest two pixels will have negative (though smaller) weights which causes sharpening. When you go up to spline64, you're adding another set of positively weighted pixels, and another pair of negatively weighted pixels. The new positively weighted pixels are weighted higher than the negatively weighted pixels, which overall will lead to more smoothing.

Don't forget, though, that "sharper" doesn't always objectively mean "better". Spline64 will still keep more detail through more transformations despite not looking as sharp.

David

[DeathTheSheep]

I understand this--but the data should be as follows:
http://forum.doom9.org/showpost.php?p=965947&postcount=153

According to this pattern, spline64 > spline64w > spline36 > spline36w > spline16 > (should be) spline16w. Meaning that the 64 is bigger than 64w, and all spline64 are bigger than spline36, of which 36 is bigger than 36w, and so on predictably. However, this is not the case with the anomalous spline16w, which is significantly bigger than everything else instead of smaller than everything else.

Also noteworthy is that in the compressed material, the spline16w kept--by far-- the most amount of detail as well, more than both spline64 implementations. This is something of a shock to me, as my testing indicated a patterned increase in spline# :: detail : filesize
with the huge exception of spline16w, which instead of producing the smallest filesize (like expected given the trend), produced not only the largest filesize, but also the most detailed encode!
So my implementation is correct, but what i called Spline16w is actually Spline64 (but with different coefficients)?
This might explain something.

[wonkey_monkey]

So my implementation is correct, but what i called Spline16w is actually Spline64 (but with different coefficients)?

This might explain something.

That was before Wilbert fixed his support values. Now that spline16w has support=2, it's definitely a spline16.

Also noteworthy is that in the compressed material, the spline16w kept--by far-- the most amount of detail as well

How are you judging that? Do you really mean that it kept detail, or that it's subjectively sharper?

I'm in the middle of running some tests, but I can tell you now that spline16w is oversharpening and losing a lot of fine detail.

David

[wonkey_monkey]

Here are some images to peruse. I resized up to 200%, then back down to the original size multiple times in order to emphasise the differences between the filters. On the left is the result of 8 pairs of resizes, on the right is the result of 32 pairs of resizes:

http://img15.imgspot.com/u/07/65/14/splinetest1173294903.jpg

As I think you'll agree, spline16w looks oversharp (though there's not much difference in the amount of fine detail between it and spline16 after all).

Spline64 seems worse than spline36. Spline36w looks positively broken. Spline64w doesn't look as sharp as spline64, which itself looks less sharp than AVS's spline36.

In order of best to worst, I'd place them like this:

spline36 > spline64 > spline64w > spline 36 > spline16w > spline36w

David

[Wilbert]

I don't know what to say. I'm not sure how to implement the equations which i listed in the previous page correctly. Perhaps IanB can help us out :)

[wonkey_monkey]

I don't know what to say. I'm not sure how to implement the equations which i listed in the previous page correctly. Perhaps IanB can help us out :)

Perhaps, but they may also be the wrong equations. I'm going to do some more graphing and see what I can determine.

David

[MfA]

The existing Spline16w is not C1 continuous around x = 0 BTW.

Anyway, lets do the math ... again :)

|x| < 1 : A1*x^3 + B1*x^2 + C1*X + D1
|x| < 2 : A2*(x-1)^3 + B2*(x-1)^2 + C2*(x-1) + D2

f1(0) = 1 : D1 = 1
f1(1) = 0 : A1 + B1 + C1 + D1 = 0
f2(1) = 0 : D2 = 0
f2(2) = 0 : A2 + B2 + C2 + D2 = 0
f1'(0) = 0 : C1 = 0
f1'(1) = f2'(1) : 3*A1 + 2*B1 + C1 = C2
f2'(2) = 0 : 3*A2 + 2*B2 + C2 = 0
f1''(1) = f2''(1) : 6*A1 + 2*B1 = 2*B2

Throw it all into Maple :) And you get :
A1 = 5/4, B1 = -9/4, C1 = 0, D1 = 1, A2 = -3/4, B2 = 3/2, C2 = -3/4, D2 = 0

So Spline16W which had been intended to be C2 continuous should be (simplified and using horner) :
|x| < 1 : (5/4*x -9/4)*x^2 + 1
|x| < 2 : ((-3/4*x + 15/4)*x - 6)*x + 3

PS. oops, it's only partly C2 continuous of course ... only at the 0 crossing, but that's the best you can do with cubics.

PPS. I also put Keys paper up (http://karton.student.utwente.nl/01163711.pdf) if you are interested, it gives the exact coefficients for spline16/36 optimized to match the first 3/4 terms of the Taylor expansion of the signal. It's simply the Catmull Rom spline, but the spline36 version might interest you (though I personally don't believe interpolation kernels with more than 2 lobes are a good idea).

[IanB]

@Wilbert,

The resizer generator evaluates the "f" function with [-support <= value <= +support]. Under normal circumstances the "f" function should be symetrical, hence most start with an value=fabs(value); and only provide the positive half of the relevant curve.

I think for your approach of Spline16W you should be starting with the following 7 control points [(-3,0), (-2,0), (-1,0), (0,1), (1,0), (2,0), (3,0)] and then using 2 of the resulting spline equations for [(0,1), (1,0)] and [(1,0), (2,0)].

The resultanting curve should be symetrical. Adding the [-3, -2]=0 and [2, 3]=0 segments to the ends might not be necessary as I think the end conditions already imply such.

[DeathTheSheep]

As I think you'll agree, spline16w looks oversharp
Yes, correctamundo David [Tennent]! That was the word I was looking for: "oversharp!" My guess is that this is precisely how it forced x264 to keep an abnormal amount of detail: not because it actually preserved more, but because it oversharpened the detail it actually preserved.

It seems to work obscenely well on low-bitrate/low-resolution anime (for encoding). Of course, this definitely depends on how you define " works well." From a solidly neutral perspective, it works positively terribly! :)

[DeathTheSheep]

On a completely different (summarizing) note:

Spline16w is way too sharp, spline36w is way too soft, spline36 beats both spline64 implementations, and my 64 vs 64w test conclusion earlier in this thread (Spline64w doesn't look as sharp as spline64) is reversed.

What amazing results... Are you sure that upsizing 2:1 then downsizing 1:2 repetitively is the best way to test interpolator quality? The old "rotation test" was hyped in the past...

PS: davidhorman, can you upload that test picture and your test script please? I'm really interested in this. :o

[MfA]

The old "rotation test" was hyped in the past...They have this amazing algorithm called the identity transform which completely blows that benchmark away (no, I don't think it's a particularly good benchmark ... it's more a test of reversibility than accuracy).

For upsizing the test aruzinsky (http://www.general-cathexis.com/interpolation.html) uses is okay, although I don't quite agree with using a box filter. For downsizing coming up with a good test is a little harder, you should probably start with a high rez image ... downsize it for some integer factors (say 16&17) with gaussian blur+decimation (most physically correct downsizer for integer factors) and then downsize from one those intermediate resolutions to another.

BTW. higher order continuity seems to not (http://lear.inrialpes.fr/people/triggs/pubs/Triggs-iccv01-subpix.pdf) be a very desirable property in piecewise cubic interpolators.

[wonkey_monkey]

What amazing results... Are you sure that upsizing 2:1 then downsizing 1:2 repetitively is the best way to test interpolator quality? The old "rotation test" was hyped in the past...

I couldn't find a spline16rotate function in AVS ;)

it's more a test of reversibility than accuracy

Doesn't one (at least somewhat) imply the other?

David

[MfA]

Doesn't one (at least somewhat) imply the other?
Only one way ... good accuracy means good results after iterative rotation to 360 degrees, good results after iterative rotation to 360 degrees however says very little about accuracy in the intermediate steps.

Exactly not the way needed to make it a good benchmark.

[Seraphic-]

It is understood that when you up-size, the image will most likely need to be sharpened back up. But how would LanczosResize compare with SplineResize for up-sizing? Also, how does the anti-aliasing of Spline and Lanczos compare?

(my source, if it will help, is a 16:9 ratio resolution captured at 720x480 - so I'm attempting to upscale to a wide-screen resolution)

Thanks

[IanB]

@MfA,

Thanks for the Robert G. Keys paper (http://karton.student.utwente.nl/01163711.pdf) and the Bill Triggs paper (http://lear.inrialpes.fr/people/triggs/pubs/Triggs-iccv01-subpix.pdf), very interesting reading.

So it would seem all this mathemagical tail chasing has been for naught. The current Spline16 and Spline36 implementations have been carefully chosen for a particular look. And I guess the Spline64 I dug up is also likely to have a somewhat arbitary lineage. Lets all keep digging, hopefully someone will come up with a paper or reference that will provide some grounding.

Wilbert's experimenting indicate almost anything will have an effect that at least some people will like.


It is understood that when you up-size, the image will most likely need to be sharpened back up.If that is your personel preference. However choosing a resizer that provides an appropriate amount of sharpening may save you an extra sharpening step.
But how would LanczosResize compare with SplineResize for up-sizing? Also, how does the anti-aliasing of Spline and Lanczos compare?Strictly, aliasing is not an issue with upsizing, the Nyquist frequency increases with upsizing. As for handling existing jaggies in the source image I personally think Spline16 does fairly a reasonable job.

(my source, if it will help, is a 16:9 ratio resolution captured at 720x480 - so I'm attempting to upscale to a wide-screen resolution)So you want to do an xxxResize(854, 480), use StackVertical or Interleave to compare the various offerings.

[*.mp4 guy]

Intersting test image, lots of aliasing and lots of stuff above the nyquist limit, this is what it looked like after 8 iterations with the 2x up/down sizer I'm working on.

http://img102.imageshack.us/img102/1733/testwa3.png

[Seraphic-]

So you want to do an xxxResize(854, 480), use StackVertical or Interleave to compare the various offerings.

Wouldn't the resolution be 853x480 for wide-screen? But since that is odd, and has some resize issues, would make 852x480 the better choice, no? I know it's only a few pixels, but wouldn't 854x480 be too wide?

Also, what are your thoughts on the final resolution of the video? Should it be 852x480 after cropping, be an up-size from something like 636x444 directly to 852x444, or be an up-size from 720x480 to 852x480 and then use the final size after cropping out the black-bars (around 758x444)? I was thinking #3, but wanted some other opinions.

[525/60]

but wouldn't 854x480 be too wide?872x480 would be too narrow.

[foxyshadis]

A tenth of a percent never killed anyone, come on, guys. You're overanalysing this, they're both equivalently good, and you can go up any way that looks good to you - although almost everyone uses crop-then-resize, because it makes the output size simple and deterministic. But hey, it's your script and you get to choose the workflow that makes the most sense for you, especially when it comes to dealing with AR.

mp4 guy, is that the same as the current wdresize, or is it a newer iteration?

[525/60]

A tenth of a percent never killed anyone,The difference between 853 and 872 is 2.2%.

[Bankis]

spline36 > bilinear > Lanczos > bicubic for downsizing with the current spline36 implementation? is this so?

[*.mp4 guy]

Its the current version, but with anti-aliasing/ringing and a bit of sharpening after upsizing, all done by dcte.

[jamieuk]

very cool thread

[techreactor]

yeah! but its confusing too, so whats the final verdict for downsizing and upsizing with respect to quality and which resizers should be preferred ??

[canuckerfan]

^I think spline36 for downsizing and maybe still lanczos for upsizing

[*.mp4 guy]

The lighthouse image with presharpening and my latest pet interpolator script (http://img476.imageshack.us/img476/8403/lighthouselzpgj0.png). As always, ideas for improvement are welcome.

[edit] Clown image (http://img297.imageshack.us/img297/8371/clownlzpeb0.png)

[DeathTheSheep]

And now the alpha adds support for a spline64. Is this the same spline64 as posted/tested earlier in this thread?

[manoj4986]

where can i find blackman resize filter

[buzzqw]

in avisynth 2.5.7

BHH

[IanB]

No, in 2.5.8

The is also a freestanding plugin version somewhere earlier in this thread.

[microchip8]

I found this thread which compares Lanczos vs Bicubic. It's a bit old, but the posts by user "dmunsil" are very interesting

http://archive2.avsforum.com/avs-vb/showthread.php?t=460922&page=2&pp=30

[DeathTheSheep]

Thanks for the link; that's quite a read. - Catmull-Rom plus sharpening is great at 1, very good at 2, and great at 3.
I'm assuming a filter for this exists since it was posted in the avs board, but I can't seem to put my finger on it. Anyone?

[manoj4986]

No, in 2.5.8

The is also a freestanding plugin version somewhere earlier in this thread.


thanq i didnt knew it was a core filter

[IanB]

IIRC Catmull-Rom isBicubicResize(... , b=0.0, c=0.5)

[*.mp4 guy]

That guy was... exagerating about how good Catmull-Rom is. Spline36 is better, as are a lot of others (for upsizing, for downsizing spline36 is about the best you can get)

IIRC Catmull-Rom isBicubicResize(... , b=0.0, c=0.5)
As far as I am aware, thats correct.

[foxyshadis]

It's just another one of those perceptual things. Though frankly I have a very difficult time discerning Catmull-Rom from Spline36... or I'm just too drunk to....

[microchip8]

ummm is there a difference between Spline36 and the Natural Bicubic Spline scaler or are both the one and same scaler, just with different names?

[DeathTheSheep]

And is the spline64 included in the newest alphas the same one linked to in this thread? If so, I'm afraid it might have problems since the coefficients haven't been verified, correct?

[IanB]

I'm afraid it might have problems since the coefficients haven't been verifiedWell yes, the red car is a firetruck. It won't have problems because the coefficients haven't been verified, it may have problems if they are wrong.

It resizes, it's sharp, it rings more than expected, do you have some technical insight or verification references to contribute.

[_ck_]

This thread is very close to a question I have though it's for ffvdub and not necessarily avisynth so I hope you'll tolerate me.

Does anyone know how many taps the Spline resize routine in ffvdub uses? Is it 16? 36? Unlike it's Lanczos which has a slider for taps up to 10, it does not have a scale.

I noticed that using Lanczos for some videos captures was creating a finely focused overscan line near the top of the result, vs using Spline was much more subdued while the rest of the image seems just as high quality as a 10-tap Lanczos.

[Jeremy Duncan]

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 8

This info is from IanD in this thread, first page.

I know I can set ffdshow to resize using lanczosresize, 2 taps.
But the chart I got from ianD shows that in avisynth, lanczosresize uses 6 taps.

So, my question is. Looking at the chart. Does avisynth lanczosresize use 3, or 6 taps?

Also, a quote from IanD,

"All resizers use the same lookup table based MMX/SSE code."

Is this quoted "Code", in SSE only?

Can it be updated to SSE4 or SSE2?

[IanB]

LanczosResize use 6 taps (sampling points).

The resizer generates code appropriate to the processor.

It could be updated, but it is already quite fast and other avisynth code has more pressing need of work.

[DeathTheSheep]

Does anyone here still have Wilbert's old splineW filter (.dll posted earlier in this thread, but dead link)? I'm in need of his oversharp spline16w...

[Wilbert]

http://www.geocities.com/wilbertdijkhof/newresize_04032007-2.zip

[DeathTheSheep]

Thanks, I appreciate it!

DTS

[Gavino]

I also put Keys paper up (http://karton.student.utwente.nl/01163711.pdf) if you are interested, it gives the exact coefficients for spline16/36 optimized to match the first 3/4 terms of the Taylor expansion of the signal.
Has anyone got another link for this paper? - this one (two years old) appears to be dead.

[mikenadia]

googling, I found this. I do not know if this is the one you are looking for.
http://www.cs.sunysb.edu/~vislab/papers/volvis96_Taylor.pdf (p5)

[Gavino]

Thanks - that looks relevant, but I was also interested in the original paper by R.G.Keys - "Cubic Convolution Interpolation for Digital Image Processing" (actually referenced in your linked paper).

I've tried Googling, but found only abstracts or references, not the paper itself.

[Wilbert]

Thanks - that looks relevant, but I was also interested in the original paper by R.G.Keys - "Cubic Convolution Interpolation for Digital Image Processing" (actually referenced in your linked paper).

I've tried Googling, but found only abstracts or references, not the paper itself.

http://rapidshare.com/files/239398655/01163711.pdf.html

[Gavino]

Thanks, Wilbert - that's the one. :thanks:

[mikenadia]

In the last page of the Keys paper, they point out to two different "boundaries" ( or "additionnal" conditions (to match the Taylor series expansion of the sampled function for as many terms as possible) as being may be more optimal (highest order of convergence) and not "second derivatives at endpoints=0". For Spline36 and over.
http: //www.ugrad.cs.ubc.ca/~cs303/2005W2/Handouts/piecewiseCubic.pdf ( 1st paragraph p3)
Thanks. Nice paper.

[IanB]

@mikenadia,

Is this the full URL? http://www.ugrad.cs.ubc.ca/~cs303/2005W2/Handouts/piecewiseCubic.pdf (http://www.ugrad.cs.ubc.ca/~cs303/2005W2/Handouts/piecewiseCubic.pdf)