Advice on Resizing

[D-Dave]

Lanczos, Lanczos4, Spline 16/36/64, nnedi3, etc. I’m in search of the overall best resizer for downscaling and the overall best resizer for upscaling. In the past I have been using spline 36 as I heard favorable things about the resizer, however, I have this feeling that spline 36 is not the ultimate answer to resizing. After reading “Upscaling in Avisynth – Comparision of resizers (http://jeanbruenn.info/2011/10/30/upscaling-in-avisynth-comparison-of-resizers/),” I felt incline to ask the community what I should use when downscaling and when I’m upscaling.

The writer of the article linked above, Jean, rated the resizers as so: nnedi3 > lanczos/lanczos4 > spline36 > everything else (slightly different than what I’ve read from other individuals). Would anyone agree that for general upscaling nnedi3 should be used before lanczos/4 and so forth? If not, what would be the best resizer for general upscaling? Are there any typical situations where one resizer will perform noticeably better than the “best” general upscaling resizer (if so explain)? Side note, when explaining a resizer, could you provide an example or two on how to execute it for reference on how to implement it into one’s script (I’m not sure how to use nnedi3 as a resize).:script:

As for downscaling video, would the resizer used in upscaling also be the best for downscaling or is there a resizer that is more appropriate? Are there any typical situations where one resizer will perform noticeably better than the “best” general downscaling resizer (if so explain)? If its dire to know what I will be using the resizers for in order to make a recommendation, I plan on downscaling 1080i footage to 1280 by 720 as well as upscaling 480i footage to 1280 by 720 (all interlaced footage will be deinterlaced beforehand with QTGMC). In some cases I will upscale the 1080i footage from 1440x1080 to 1920x1080 and in other cases 480i to 1920x1080 (or a 4:3 aspect ratio for 1080).

Bonus question: Has anyone looked into the super resolution that is offered in vReveal? I’ve had the program since version 1.1 and I was curious how the super resolution performs in upscaling video in comparison to what Avisynth has to offer. I will probably run my own tests in my free time, but if anyone already has information and experience with vReveal’s super resolution feel free to post.

[Asmodian]

Just a friendly note:
Don't ask what is best (check out the fourm rules (http://forum.doom9.org/forum-rules.htm))

To use nnedi3 to upscale you use nnedi3_rpow2().

The first example from the help file for nnedi3:

enlarge image by 4x, don't correct for center shift.

nnedi3_rpow2(rfactor=4)

I prefer a less ringing resize compaired to lanczos4, lanczos4 also requires more bits to encode. I like spline36 for most of my down scale resizes. Doing a large upscale I would use nnedi3 followed by spline36 to downscale again to the desired resolution, if I had the time.

I like this set of kernel visualizations (http://svn.int64.org/viewvc/int64/resamplehq/doc/kernels.html) from PhrostByte's ResampleHQ's documentation to understand the tradeoffs between resizers.

[IanB]

All of the inbuilt Avisynth resizers effectively work the same way. The difference between them is how many taps each use and what weight do they apply to each tap. More taps allows for higher sharpening but risks more ripples (ringing). The actual choice of tap weights sets the actual degree of sharpening and risk of ringing. The spline family are generally considers conservative, with emphasis on avoiding ringing. The lanczos family is more aggressive, favouring higher sharpening at the risk of marginally observable ringing, blackman is a lanczos variant that favours a slightly more conservative sharpening for higher tap counts.

The nnedi family are neural net trained edge directed interpolaters. At a single pass they will double the height of the input image. All other size adjustments are made with combinations of 90 degree rotations, multiple passes and a final standard downsize to the actual size required. For up-sizing by a factor of 2 a nnedi interpolation is currently the state of the art.

Your choice of actual resizer used should be subjectively based on the actual content of the material involved. There is no one size fits all. Crystal sharp sources almost certainly do not want any extra sharpening. Soft sources may withstand extreme sharpening particularly with large downsizing ratios. Avisynth provides many resizers so you can choose the best one for your current source material.

Note 1: PointResize implements the nearest neighbour algorithm, so no taps or weighting is involved.

Note 2: BilinearResize and GaussResize only use positive tap coefficients so provide no sharpening and cause no ringing. All the other resizers use some negative coefficients to provide sharpening and risk ringing. GaussResize at it's sharpest P setting is a PointResize. BicubicResize is a 3 tap resizer, user selectable B and C values make it fully tunable to suit any needs.

[*.mp4 guy]

Negative lobe coefficients past the first are not directly analogous to sharpening, and the first is debatable. Additionally, you can get ringing without negative coefficients. "34 0 0 0 63 100 63 0 0 0 34" will cause ringing no matter what sign's you give. It's more about phase discontinuity then coefficient sign, hell look at a large radius box blur sometime, it almost looks like it is ringing itself.

Not to say that your advice is incorrect, it isn't. The whole "negative lobe coefficients=sharpening" thing just gets on my nerves as it is overly simplistic. Negative lobes give better roll-off then keeping everything positive unless you are willing to completely nuke the passband.

[Gavino]

PointResize implements the nearest neighbour algorithm
Something I've been meaning to point out for some time is that PointResize isn't strictly 'nearest' neigbour, as it is biased to one side.
A nearest neighbour kernel would look like this:
--------
| |
| |
| |

-0.5 0 0.5
PointResize effectively has this:
--------
| |
| |
| |

-1 0

Essentially, this is the root of the different behaviour between RGB and YUV with vertical PointResize.

Interestingly, in light of your other comment,
GaussResize at it's sharpest P setting is a PointResize.
GaussResize(P=100) does provide a true nearest neighbour.

[gyth]

I found the cambridge in colour tutorials helpful.
1 (http://www.cambridgeincolour.com/tutorials/digital-photo-enlargement.htm) 2 (http://www.cambridgeincolour.com/tutorials/image-interpolation.htm) 3 (http://www.cambridgeincolour.com/tutorials/image-resize-for-web.htm)

ImageMagick guide (http://www.imagemagick.org/Usage/resize/)
upsizing pixel art (http://research.microsoft.com/en-us/um/people/kopf/pixelart/supplementary/multi_comparison.html)

[Gavino]

GaussResize at it's sharpest P setting is a PointResize.
Thinking more about this, it's not always true and depends on resize ratio and where the resampling points fall.
Certainly, with P=100, the Gaussian kernel falls off so steeply that in many cases only the nearest pixel will have a non-zero weight, which I think is the basis of Ian's assertion.
However, if a resampling point is halfway between two pixels, both neighbouring pixels will have equal weights (and if it's close to halfway, they will both still be non-zero and close to equal).

Thus, for example,
GaussResize(2*width, 2*height, 0.25, 0.25, P=100)
gives identical results to
BilinearResize(2*width, 2*height, 0.25, 0.25)
for RGB clips and the luma of YUV clips. (For YUV chroma, the offsets need to be 0.5).

(D-Dave, sorry for this technical hair-splitting which is really tangential to your original question. :))

[*.mp4 guy]

Avisynth's bilinear kernel is expanded, compared to the norm, it uses just as many pixels as bicubic, so it will never be equivelent to GaussResize, or a box filter like standard bilinear would.

Anyway, to get closer to the original topic, most of the time I would now recommend using BlackmanResize(width, height, taps=5). The blackman windowing function is good enough that you can commonly get away with a higher number of taps then avisynth's other interpolators, which is good because it really needs them. BlackmanResize looks a bit more "neutral" then spline or lanczos, but occasionally it will let some aliasing through, especially with taps of 3 or less.

[Gavino]

Avisynth's bilinear kernel is expanded, compared to the norm, it uses just as many pixels as bicubic
I don't know where you get that idea from.
Here is the relevant code from resample_functions.h:
class TriangleFilter : public ResamplingFunction
/**
* Simple triangle filter, used in BilinearResize
**/
{ ...
double support() { return 1.0; }
};

class MitchellNetravaliFilter : public ResamplingFunction
/**
* Mitchell-Netraveli filter, used in BicubicResize
**/
{ ...
double support() { return 2.0; }
...
};

so it will never be equivelent to GaussResize, or a box filter like standard bilinear would.
But with a high P (small radius), GaussResize can reduce to using only one or two pixels, making it equivalent to PointResize or (in certain cases, like the example I gave) BilinearResize.