Spline Resize vs. Lanczos Resize

[Typhoon859]

Originally Posted by cogman

I don't get it. Why would you upscale the image before encoding it? If it is to justify the large bitrate, well, tell the encoder to use more bits rather then throw more at the image.

Yeah, I could see it if you are targeting a specific device that doesn't support upscaling/does a crappy job at it. However, most are generally pretty good at it.

Yeah. It's pretty much to justify the larger bitrate. @3500kbps for a 1280x720 resolution, you get less detail loss than @1400kbps for a 704x396 resolution. Anything above that bitrate for a non-HD video is just unreasonable. Plus, the lines are very obviously less jittery and the sharpening seems to work more effectively. Overall, the video looks better, even with a bitrate that makes just as much detail loss at the HD resolution vs. the SD one.

[cogman]

Well, use 2000 kbps instead of 1400 kbps on the video then. Heck use 3500 kbps on the source rather then upscaling the image, and you'll get a better quality video then if you where to use 3500 kbps on the upscaled image.

I don't see why a bitrate higher then 1400 is unreasonable for a non HD source, Very often I will use somewhere around 2000 on non-hd material (CRF is awesome that way).

If getting rid of jitters and better sharpening is the goal, I would suggest this. Upscale the image, do whatever processing you are doing now, and then downscale the image to its original resolution. Just make sure that when you upscale it you do it by an evenly divisible number (preferably a power of 2) to keep it from loosing data from the scaling. (this technique is somewhat the same as what your video cards do when they do anti-aliasing)

For example, your 704x396 image could go up to 1408x792, and shouldn't loose any data from the scaling.

[Typhoon859]

Originally Posted by cogman

Well, use 2000 kbps instead of 1400 kbps on the video then. Heck use 3500 kbps on the source rather then upscaling the image, and you'll get a better quality video then if you where to use 3500 kbps on the upscaled image.

I don't see why a bitrate higher then 1400 is unreasonable for a non HD source, Very often I will use somewhere around 2000 on non-hd material (CRF is awesome that way).

If getting rid of jitters and better sharpening is the goal, I would suggest this. Upscale the image, do whatever processing you are doing now, and then downscale the image to its original resolution. Just make sure that when you upscale it you do it by an evenly divisible number (preferably a power of 2) to keep it from loosing data from the scaling. (this technique is somewhat the same as what your video cards do when they do anti-aliasing)

For example, your 704x396 image could go up to 1408x792, and shouldn't loose any data from the scaling.

I say that more than 1400kbps is unreasonable because it just is... The size of the 24 min video ends up being a size like no other SD video I've ever seen encoded. In terms of your suggestion, it sounds interesting and very plausible though I'm not too sure how to do it. I upscale the video at the very end. If right after that, I downscale it, I don't see how it will make a difference. The actual encoding will take place on the latest resolution set. I will try it though. I sorta understand how it could help though based on your description of most video cards. I just downsize it back to it's original resolution at the end, right after I upscale?

[Sagekilla]

@cogman: When you're working with real life type content, there's no real point in trying to upscale content (Unless you're doing something like combining HD and SD content). In Typhoon's case, where he's working with animated video, you can take advantage of nice resizers like NNEDI and get very good results.

I've done a few SD -> HD conversions on animated video, and it can come out very nicely, especially when displayed on a high res screen. Since I have the advantage of using high quality (but slow) filters to produce that HD output, I don't have to deal with the lower quality resizer built into many software players.

[Typhoon859]

Originally Posted by Sagekilla

@cogman: When you're working with real life type content, there's no real point in trying to upscale content (Unless you're doing something like combining HD and SD content). In Typhoon's case, where he's working with animated video, you can take advantage of nice resizers like NNEDI and get very good results.

I've done a few SD -> HD conversions on animated video, and it can come out very nicely, especially when displayed on a high res screen. Since I have the advantage of using high quality (but slow) filters to produce that HD output, I don't have to deal with the lower quality resizer built into many software players.

So you also think it is worth upscaling to produce better quality? And yeah, especially on a high resolution screen - the difference is there.

[Jeremy Duncan]

[QUOTE=Typhoon859;1253463]Believe it or not, I'm actually asking a question... More specifically though, what are the real differences between Spline16Resize for example vs. LanczosResize? QUOTE]

Play my test disks with either resizer and see which result you like better: http://forum.doom9.org/showthread.php?t=140747

[Typhoon859]

[QUOTE=Jeremy Duncan;1272748]

Originally Posted by Typhoon859

Believe it or not, I'm actually asking a question... More specifically though, what are the real differences between Spline16Resize for example vs. LanczosResize? QUOTE]

Play my test disks with either resizer and see which result you like better: http://forum.doom9.org/showthread.php?t=140747

I will, thanks.

[*.mp4 guy]

Originally Posted by cogman

Just make sure that when you upscale it you do it by an evenly divisible number (preferably a power of 2) to keep it from loosing data from the scaling. (this technique is somewhat the same as what your video cards do when they do anti-aliasing)

For example, your 704x396 image could go up to 1408x792, and shouldn't loose any data from the scaling.

unless you are pointresizing up and boxresizing, or pointresizing down, you are losing data.

Interpolation with anything other then an integer power upscale with pixel duplication IE pointresize is lossy. Downscaling is always lossy, unless you are downsizing a previously pixel duplicated/pointresized image, by a factor of the original upscale integer, using either box or pointresize/pixel decimation.

For all practical purposes interpolation is always lossy, but the loss is of managable size and very rarely easily noticible after only one or two interpolation operations with good linear interpolation.

[Gavino]

Originally Posted by *.mp4 guy

Interpolation with anything other then an integer power upscale with pixel duplication IE pointresize is lossy.

That's right. Naively, one might think that upscaling by a factor of 2 would at least preserve the original pixels, but that's only true for PointResize. All the other resizers preserve the image center position, so all output pixels end up being interpolated.

(If we number the original pixels 0, 1, 2, ..., then the output pixels correspond to positions -0.25, 0.25, 0.75, 1.25, ...)

Interestingly (or maybe not ), it turns out that upscaling by an odd integer factor actually does preserve the original pixels amongst the interpolated ones. For example, for x3, we get pixels corresponding to -1/3, 0, 1/3, 2/3, 1, ...

[*.mp4 guy]

iirc, even for 3x, 5x, etc. upscales, the center pixel is stil processed by some of the taps of the filter, IE, for 3x, the center pixel does not get processed by the main blurring lobe, but it gets hit by the following sharpening, and bluring lobes (assuming 3 tap interpolation), I'm not sure how the internals of the functions work, so the center pixels may be bypassed, but otherwise, it is as good as impossible to preserve any of the original pixels. Furthermore, even for 3x, etc. upscaling, you would have to use pointresize downscaling, selecting only the unprocessed pixel positions to get back to where you started, and If you do that instead of at least using box downsizing, their isn't any point in upscaling at all.

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

Originally Posted by Gavino

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]

Originally Posted by SEt

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]

Originally Posted by JohannesL

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