Spline Resize vs. Lanczos Resize

[Gavino]

You're right that even for 3x, 5x, etc, it does depend on the filter kernel of the specific resizer used.
But actually, most of the resizers (when upsizing) do act as pure interpolators (their kernels have zero crossings at integer distances from the center), so source pixels are preserved where the resampling points coincide.

The exceptions are BilinearResize with b/=0, and GaussResize (except for large values of p, >80 or so).

You can demonstrate this with a script like this:
function UpDown(clip c, int scale) {
w = c.width
h = c.height
up = c.LanczosResize(w, h*scale) # or most other resizers
up.PointResize(w, h, 0, (scale-1)/2.0)
IsYV12(c) ? MergeChroma(up.PointResize(w, h, 0, scale-1.0)) : last
}

... # set source
orig = last
UpDown(5) # or any odd number
Compare(orig)
which will show successful recovery of the source pixels (by point downsizing) after upscaling by an odd multiple.
(If source is YV12, an extra step is required because of differing chroma placement.)

Of course, all this is of mainly academic interest, since I agree that the exercise is fairly pointless. ;)

[Surf]

I hope to understand any of this in my next life...

In the meanwhile, what's the recommendation of blu-ray's 1920x1080 to 720x480?

TIA

[*.mp4 guy]

But actually, most of the resizers (when upsizing) do act as pure interpolators (their kernels have zero crossings at integer distances from the center), so source pixels are preserved where the resampling points coincide.

You are right, that had slipped my mind. So I suppose any resampler derived from sinc in some way (pretty much every linear interpolator except what you listed) would behave this way.

[SEt]

How YV12 chroma is processed that exact reverse require scale-1.0 offset? Also, can anyone explain what is the point of adding 0.001 to src_width and src_height that can be seen sometimes in the scripts, like this line:
TurnLeft().EEDI2().TurnRight().EEDI2().spline64resize(last.width,last.height,0.5,-0.5,2*last.width+.001,2*last.height+.001)

[Gavino]

How YV12 chroma is processed that exact reverse require scale-1.0 offset?
Take the case scale=5. Here the middle pixel in every 5 of the upscaled video will be a copy of an original pixel. So when downsizing we want to pick out pixels 2, 7, 12, etc. This requires an offset of 2 in the downscaling PointResize, or in the general case (scale-1)/2.

For chroma, we still need to pick out pixels 2, 7, 12, etc, but because in YV12 the chroma pixels are spaced twice as far apart, we need to double the offset, hence scale-1.

Note: The UpDown function I posted above only does vertical resizing. For horizontal resizing, the same issue arises with YUY2 chroma. Also, I've since realised that for RGB the vertical offset should be negative since Avisynth processes RGB from the bottom up. For completeness, here's an extended version:
function UpDown(clip c, int scale) {
w = c.width
h = c.height
pixel = (scale-1)/2
up = c.LanczosResize(w*scale, h*scale)
up.PointResize(w, h, pixel, IsRGB(c) ? -pixel : pixel)
IsYV12(c) ? MergeChroma(up.PointResize(w, h, 2*pixel, 2*pixel)) : \
IsYUY2(c) ? MergeChroma(up.PointResize(w, h, 2*pixel, pixel)) : last
}
Also, can anyone explain what is the point of adding 0.001 to src_width and src_height that can be seen sometimes in the scripts, like this line:
TurnLeft().EEDI2().TurnRight().EEDI2().spline64resize(last.width,last.height,0.5,-0.5,2*last.width+.001,2*last.height+.001)According to Didée (here), that was a workaround for a problem in Avisynth 2.5.6 and the .001 is no longer needed, except for compatibility of scripts with that version.

[SEt]

It doesn't make any sense to me why resizer won't internally account for different quantity of YV12 chroma samples. And in test case i get correct resizing with
PointResize(width/2,(height-128)/2,0,128,width,height-128)
not with
PointResize(width/2,(height-128)/2,0,128,width,height-128).MergeChroma(PointResize(width/2,(height-128)/2,0,256,width,height-128))

[Gavino]

SEt, I think you and I are talking about different things here.

For 'normal' resizing (such as your example), you don't need to treat the chroma separately as the resizers handle everything for you, including the offsets (if any).

I am talking about using PointResize in a special way to recover specific pixels from a 3x (or 5x, 7x, ...) upsized image, and here the chroma does need to be handled differently, for the reasons I have tried to explain. I am not saying that you need a different offset for chroma with PointResize in other situations.

[leeperry]

www.sm64.org/div/Bilinear0.png
www.sm64.org/div/Spline360.png

640x480 to 320x240
Spline36 is sharper, but both look good to me.
well spline36 is actually a halo festival when going 1080p>720p...how about lanczos3 or bicubic(1.0?)? bicubic looks good I think, need to run more tests