BicubicResize
(clip, int target_width, int target_height, float
"b", float "c")
BilinearResize
(clip, int target_width, int target_height)
LanczosResize
(clip, int target_width, int target_height,
int "taps")
Lanczos4Resize
(clip, int target_width, int target_height)
Spline16Resize
(clip, int target_width, int target_height)
Spline36Resize
(clip, int target_width, int target_height)
GaussResize
(clip, int target_width, int target_height, float
"p")
PointResize
(clip, int target_width, int target_height)
BicubicResize
(clip, int target_width, int target_height, float
"b", float "c", float "src_left", float "src_top",
float "src_width", float "src_height")
BilinearResize
(clip, int target_width, int target_height, float
"src_left", float "src_top", float "src_width",
float "src_height", int "taps")
LanczosResize
(clip, int target_width, int target_height, float
"src_left", float "src_top", float "src_width", float "src_height")
Lanczos4Resize
(clip, int target_width, int target_height, float
"src_left", float "src_top", float "src_width", float "src_height")
Spline16Resize
(clip, int target_width, int target_height, float
"src_left", float "src_top", float "src_width", float "src_height")
Spline36Resize
(clip, int target_width, int target_height, float
"src_left", float "src_top", float "src_width", float "src_height")
GaussResize
(clip, int target_width, int target_height, float
"src_left", float "src_top", float "src_width", float "src_height")
PointResize
(clip, int target_width, int target_height, float "src_left",
float "src_top", float "src_width", float "src_height", float "p")
From v2.56 you can use offsets (as in Crop) for all resizers:
GaussResize
(clip, int target_width, int target_height, float
"src_left", float "src_top", float -"src_right", float
-"src_top")
For all resizes you can use an expanded syntax which crops before resizing. The same operations are performed as if you put a Crop before the Resize, there can be a slight speed difference.
Crop(10,10,200,300).BilinearResize(100,150) # which is the same as BilinearResize(100,150,10,10,200,300)
Important: AviSynth has completely seperate vertical and horizontal resizers.
If the input is the same as the output on one axis, that resizer will be skipped.
Which one is called first, is determined by which one has the smallest downscale
ratio. This is done to preserve maximum quality, so the 2nd resizer has the
best possible picture to work with.
The BilinearResize
filter rescales the input video frames to an arbitrary
new resolution. If you supply the optional source arguments, the result
is the same as if you had applied Crop
with those arguments to the
clip before BilinearResize
(except faster).
BilinearResize
uses standard bilinear filtering and is almost identical
to VirtualDub's "precise bilinear" resizing option. It's only "almost" because
VirtualDub's filter seems to get the scaling factor slightly wrong, with the
result that pixels at the top and right of the image get either clipped or duplicated.
(This error is noticeable when expanding the frame size by a factor or two or
more, but insignificant otherwise, so I wouldn't worry too much about it.)
Examples: # Load a video file and resize it to 240x180 (from whatever it was before) AVISource("video.avi").BilinearResize(240,180) # Load a 720x480 (CCIR601) video and resize it to 352x240 (VCD), # preserving the correct aspect ratio AVISource("dv.avi").BilinearResize(352, 240, 8, 0, 704, 480) # or what is the same AviSource("dv.avi").BilinearResize(352, 240, 8, 0, -8, -0) # Extract the upper-right quadrant of a 320x240 video and zoom it # to fill the whole frame BilinearResize(320,240,160,0,160,120)
BicubicResize
is similar to BilinearResize
, except that instead
of a linear filtering function it uses the Mitchell-Netravali two-part cubic.
The parameters b and c can be used to adjust the properties of
the cubic, they are sometimes referred to as `blurring' and `ringing,' respectively.
With b = 0 and c = 0.75 the filter is exactly the same as VirtualDub's "precise bicubic," and the results are identical except for the VirtualDub scaling problem mentioned above. The default is b = 1/3 and c = 1/3, which were the values recommended by Mitchell and Netravali as yielding the most visually pleasing results in subjective tests of human beings. Larger values of b and c can produce interesting op-art effects--for example, try b = 0 and c = -5.
If you are magnifying your video, you will get much better-looking results
with BicubicResize
than with BilinearResize
. However, if you
are shrinking it, you are probably just as well off, or even better off, with BilinearResize
. Although VirtualDub's bicubic filter does produce better-looking
images than its bilinear filter, this is mainly because the bicubic filter sharpens
the image, not because it samples it better. Sharp images are nice to look at--until
you try to compress them, at which point they turn nasty on you very quickly.
The BicubicResize
default doesn't sharpen nearly as much as VirtualDub's
bicubic, but it still sharpens more than the bilinear. If you plan to encode
your video at a low bitrate, I wouldn't be at all surprised if BilinearResize
yields better quality.
You have to set
b + 2 * c = 1
for the numerically most accurate filter.
This gives for b = 0 the maximum value for c = 0.5, which is the Catmull-Rom
spline and a goog suggestion for sharpness.
From c>0.6 the filter starts to "ring". You won't get real sharpness,
what you'll get is crispening like on a TV set.
No negative values are allowed for b. Then stay on b=0.
LanczosResize
is an alternative to BicubicResize
with high
values of c about 0.6 ... 0.75 which produces quite strong sharpening.
It usually offers better quality (fewer artifacts) and a sharp image.
Lanczos4Resize
(added in v2.55) is closely related to LanczosResize
(correct name: Lanczos3Resize). The latter uses 2*3=6 lobes and the former 2*4=8 lobes to do the resizing. The result is that
Lanczos4Resize
produces sharper images. Especially usefull when upsizing a clip.
"For upsampling (making the image larger), the filter is sized such that the entire equation falls across 4 input samples, making it a 4-tap filter. It doesn't matter how big the output image is going to be - it's still just 4 taps. For downsampling (making the image smaller), the equation is sized so it will fall across 4 *destination* samples, which obviously are spaced at wider intervals than the source samples. So for downsampling by a factor of 2 (making the image half as big), the filter covers 2*4=8 input samples, and thus 8 taps. For 3x downsampling, you need 3*4=12 taps, and so forth.
Thus the total number of taps you need for downsampling is the downsampling ratio times the number of lobes (thus
Tx downsampling and LanczoskResize results in T*2*k taps). And practically, one needs to round that up to the next even integer. For upsampling, it's always 4 taps." Source:
[avsforum
post].
Lanczos4Resize is a short hand for LanczosResize(taps=4).
Two spline based resizers. Spline16Resize
is slightly faster than
Spline36Resize
. (added in v2.56)
Uses a gaussian resizer with adjustable sharpness parameter p
(default 30). p has a range from about 1 to 100, with 1 being very blurry and 100 being very
sharp.
GaussResize
has similar speed as Lanczos4Resize
. (added in v2.56)
PointResize
is the simplest resizer possible. It uses a Point Sampler
or Nearest Neighbour algorithm, which usually results in a very blocky image.
So in general this filter should only be used, if you intend to have inferiour
quality, or you need the clear pixel drawings.
Useful for magnifying small areas for examination.
Changelog:
v2.55 | added Lanczos4Resize |
v2.56 | added Spline16Resize, Spline36Resize, GaussResize and taps parameter in LanczosResize; added offsets in Crop part of xxxResize |
$Date: 2005/10/03 16:49:04 $