`BicubicResize `

(`clip, int target_width, int target_height, float
"b=1./3.", float "c=1./3.", 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"`)

`BlackmanResize `

(`clip, int target_width, int target_height, float
"src_left", float "src_top", float "src_width", float "src_height", int "taps=4"`)

`GaussResize `

(`clip, int target_width, int target_height, float
"src_left", float "src_top", float "src_width", float "src_height", float "p=30."`)

`LanczosResize `

(`clip, int target_width, int target_height, float
"src_left", float "src_top", float "src_width", float "src_height", int "taps=3"`)

`Lanczos4Resize `

(`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"`)

`Spline16Resize `

(

`Spline36Resize `

(

`Spline64Resize `

(

From *v2.56* you can use offsets (as in Crop) for all resizers:

i.e.

`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.

Note the edge semantics are slightly different, Crop gives a hard absolute boundary, the Resizer filter lobes may extend into the cropped region but not beyond the physical edge of the image.

Use Crop to remove any hard borders or VHS head switching noise, using the Resizer cropping may propagate the noise into the adjacent output pixels. Use the Resizer cropping to maintain accurate edge rendering when excising a part of a complete image.

Crop(10,10,200,300).BilinearResize(100,150) # which is nearly the same as BilinearResize(100,150,10,10,200,300)

Important: AviSynth has completely separate 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`

.

`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`

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 values are *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`

`BilinearResize`

`BicubicResize`

`BilinearResize`

For the most numerically accurate filter constrain b and c such that they satisfy :-

b + 2 * c = 1This gives maximum value for c = 0.5 when b = 0. This is the Catmull-Rom spline. Which is a good 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 with a TV set sharpness control. Negative values are not allowed for b, use b = 0 for values of c > 0.5.

`BlackmanResize`

is a modification of `LanczosResize`

that has better control of ringing artifacts for high numbers of taps. See
`LanczosResize`

for an explanation for the taps argument (default:
taps=4). (added in *v2.58*)

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`

uses 4 taps and has similar speed as `Lanczos4Resize`

. (added in *v2.56*)

` LanczosResize` is an alternative to

`BicubicResize`

`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.

Lanczos4Resize is a shorthand for LanczosResize(taps=4).

**Note: the input argument named taps should really be lobes (actually
it is half the number of lobes). When discussing resizers, taps has a
different meaning, as described below.**

Assuming Taps=4, for upsampling (making the image larger), the filter span 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 is effectivly 8 taps. For 3x downsampling, you get effectivly 3*4=12 taps, and so forth.

Thus the effective number of taps you get for downsampling is the downsampling
ratio times the number of filter input taps (thus **T**x downsampling and
Lanczos**k**Resize results in T*k taps), this is rounded up to the next
even integer. For upsampling, it's always just **k** taps. Source:
[avsforum
post].

` 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.

It is very useful for magnifying small areas of pixels for close examination.

Three Spline based resizers (added in *v2.56/v2.58*). The
rational for Spline is to be as sharp as possible with less ringing artefacts than
`LanczosResize`

produces. `Spline16Resize`

uses
sqrt(16)=4 sample points, `Spline36Resize`

uses 6 sample points, etc
... The more sample points that are used, the sharper your clip will be. A comparison
between some resizers is given
here.

As of today, the authors of AviSynth have no idea how the coefficients as used in the Spline resizers are derived. If you do, please drop us a note.

**Changelog:**

v2.55 | added Lanczos4Resize |

v2.56 | added Spline16Resize, Spline36Resize, GaussResize and taps parameter in LanczosResize; added offsets in Crop part of xxxResize |

v2.58 | added BlackmanResize, Spline64Resize |

`$Date: 2007/04/17 03:29:29 $`