LanczosResize vs. SplineResize

[foxyshadis]

Originally Posted by check

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.

Originally Posted by HeadBangeR77

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.

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
2taps-4reps
4taps-4reps
4taps-8reps
(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
lanczos-4taps
lanczos-48taps
spline-3taps(aka spline36)

[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 script

Blankclip(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]

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.

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]

Originally Posted by IanB

• 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]

Originally Posted by IanB

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.