Current guide to x264 "--vf" downscaling modes

[benwaggoner]

I'm playing around with the internal x264 scaling modes from libswscale. I'm having a devil of a time finding useful documentation about them. The most definitive I've found is this one, but the actual research was done in 2008!

http://forum.doom9.org/showthread.php?t=160593

The default of bicubic is good for moderate downscaling almost everywhere. But I'm trying to figure out what's the most neutral one for big ratios (like 1920x1080 to 352x192); that's >5x. And with 4K sources starting to be used, we'll have >10x ratios for some scenarios. For this kind of stuff, even bicubic has historically had trouble with the fine details of rolling credits and that sort of thing. Heck, and optimal scaling algorithm has as many taps as the source frame has pixels that overlap with the region that the output pixel comes from, so that'd be 25+ even in the 1080p -> 192p case.

[LoRd_MuldeR]

I don't think there is a "best" one, because they all have their pros and cons.

But a nice comparison of various resize kernels (not all available in libswscale) can be fond here, for example:
http://svn.int64.org/viewvc/int64/re...c/kernels.html

[xooyoozoo]

From what I remember, resizing that drastically means that it's best to use multiple steps of 0.5 reductions each time using gaussian and bilinear. As gaussian blurs more than bilinear but iterative bilinear adds distortions, I think people generally save bilinear for the last step.

Note that the above at least applies to reduction work in image editing. I've no idea if libswscale will perform similarly.

[akupenguin]

Originally Posted by benwaggoner

Heck, an optimal scaling algorithm has as many taps as the source frame has pixels that overlap with the region that the output pixel comes from, so that'd be 25+ even in the 1080p -> 192p case.

Are there any scaling algorithms that don't do that? Other than nearest neighbor.

Originally Posted by xooyoozoo

multiple steps of 0.5 reductions each time using gaussian and bilinear

Why would you do that, rather than composing all of those steps into a single FIR filter? Same ideal result, less intermediate rounding, less cache thrashing.

[benwaggoner]

Originally Posted by LoRd_MuldeR

I don't think there is a "best" one, because they all have their pros and cons.

Indeed. I really want a very neutral one. Fine details like text should come out legible without aliasing and without the letter shapes changing significantly frame-to-frame.

Beyond that, I don't want extra hard-to-compress detail like ringing. And I want it to be reasonably sharp, without problematic blurring or sharpening.

But a nice comparison of various resize kernels (not all available in libswscale) can be fond here, for example:
http://svn.int64.org/viewvc/int64/re...c/kernels.html

This is good! Of the ones in libswscale, Gauss looks to be the best. Oddly, though bilinear is shown as the most neutral of all, which doesn't match my experience.

It'd be nice if they'd say which parameters were being used in bicubic, lanczos, etcetera.

Time for more testing!

[xooyoozoo]

Originally Posted by akupenguin

Why would you do that, rather than composing all of those steps into a single FIR filter? Same ideal result, less intermediate rounding, less cache thrashing.

That process is meant to be more of a way to deal with many image programs's limited set of sizing options rather than an efficient or even optimal approach. I thought it might apply here, as the OP seem to want to stick with swscale's current selection of scalers.

In any case, ImageMagick has a thorough page detailing its plethora of scaling algorithms and their relative sharpness and potential artifacts. Only some apply to swscale, but the resource could be useful. The author visits this forum too.

[Dark Shikari]

Originally Posted by xooyoozoo

That process is meant to be more of a way to deal with many image programs's limited set of sizing options rather than an efficient or even optimal approach. I thought it might apply here, as the OP seem to want to stick with swscale's current selection of scalers.

But, like akupenguin said, swscale's scalers already do that. Splitting the downscaling into multiple steps would just make things worse.