AviSynth+ thread Vol.2

[DTL]

Recommended edits for https://avisynthplus.readthedocs.io/...ddborders.html :

Param name "string "resample"": Typically resample means changing of samples count. Here we have only changed samples values by filtering. It also looks like some 'resampling' though. Maybe it is better to name the param 'filter' or '(filter_)kernel'.

Current text: "When r radius is not zero, then determines which resampler is used in the transient filtering. All AviSynth resizers are allowed: ("point", "bilinear", "bicubic", "lanczos", "lanczos4", "blackman", "spline16", "spline36", "spline64", "gauss" and "sinc", "sinpow", "sinclin2" and "userdefined2")."

Recommended text: When r radius is not zero, then determines which resampler' kernel is used in the transient filtering. All AviSynth resizers' kernels are allowed: ("point", "bilinear", "bicubic", "lanczos", "lanczos4", "blackman", "spline16", "spline36", "spline64", "gauss" and "sinc", "sinpow", "sinclin2" and "userdefined2"). Most useful are "gauss", "sinpow" and "userdefined2". Where "gauss", "sinpow" are easier to control and "userdefined2" can provide best quality (especially if r=2 or more with param3 (support) adjusted from default 2.3 to higher values like 5 or more. See also Notes below).


Current text: "These 'float' type parameters can be the additional parameters for the resampler. Some resizer algorithms would need and can be fine tuned with up to 3 parameters. Their default values depend on the selected chromaresample resizer kernel."

Recommended text: These 'float' type parameters can be the additional parameters for setup the used filtering kernel and convolution (support-size parameter). Some filtering algorithms would need and can be fine tuned with up to 3 parameters. Their default values depend on the selected filtering kernel.


Current text: "When r radius is not zero, transient filtering occurs. Even r=1 is giving sufficient protection for some next processing stages."

Recommended text: When r radius is not zero, transient filtering occurs. Even r=1 is giving sufficient protection for some next processing stages. Max used r-parameter value may reach 4 or 5 for some types of filtering if higher quality is required (total number of changed samples created by filtering process to 'describe' or 'encode' the transient's shape is r*2). See Note below. Also high values of r-parameter may be used for artistic intent to make transient to added border more visibly soft.


Current text: # Add 20 black pixels around the clip, filters (blurs) 1 pixel with the default "gauss" method
AddBorders(20, 20, 20, 20, r=1)

Recommended text: # Add 20 black pixels around the clip, filters (blurs) 1 pixel around new created transient (2 pixels total) with the default "gauss" kernel
AddBorders(20, 20, 20, 20, r=1)

Recommended Notes: As noted in Japan ARIB STD-B28 https://www.arib.or.jp/english/html/...B28v1_0-E1.pdf A.5 : The number of samples to be used for the transient shall be 6 to 9, in the case of 1920 horizontal samples, although it may depend upon the scale of hardware, process performance and the so-called “make up”. It means the max used value of the r-parameter may reach 4 or 5 (9/2=4.5 but only integers are valid for current implementation).

[pinterf]

Originally Posted by DTL

Recommended edits for https://avisynthplus.readthedocs.io/...ddborders.html :

I wait a bit with the edit, your earlier modifications are already integrated (not commited yet - only together with this batch)

[DTL]

Recommended edits to https://avisynthplus.readthedocs.io/...rs/resize.html

Current text: When resizing images, convolution filters help in smoothing or sharpening the image to avoid artifacts like aliasing, which can occur when the image is scaled up or down.

Recommended text: When resizing images, convolution filters help in smoothing or sharpening the image to avoid artifacts like aliasing, ringing, which can occur when the image is scaled up or down.

Current text: The set of SinPower/UserDefined2 and Sinc/SincLin2/Lanczos/Blackman resizers form a complementary set for a sinc-based workflow in digital imaging, allowing controlled sharpness and ringing. SinPowerResize or UserDefined2Resize are used for content creation as downscaling (compressing), while any sinc-based resizer can be used for upscaling for display or intermediate processing (interpolation, decompressing).

Recommended text: The set of SinPower/UserDefined2 and Sinc/SincLin2/Lanczos/Blackman resizers form a complementary set for a sinc-based workflow in digital moving imaging, allowing controlled sharpness and ringing. Digital moving imaging is a subset of general digital imaging for processing of moving (or, in general, any transforming in time like rotating/scaling/skewing and other) objects' views in digital form with as low distortions as possible. SinPowerResize or UserDefined2Resize are used for content creation as downscaling (compressing), while any sinc-based resizer can be used for upscaling for display or intermediate processing (interpolation, decompressing). Other resize kernels (Bicubic, Spline, Point, Gauss) come from general purpose digital imaging (typically static or pixel-based images) and can be used when sinc-based workflow can not serve good or static images processing is required. Though Gauss kernel can also be used as a good quality anti-Gibbs ringing filter for sinc-based workflows.


Current text: Optionally, when a filtering radius is given, a custom resizer can be added to AddBorders and LetterBox. In these filters the transient areas (boundary of the new borders) are filtered, in order to prevent ringing e.g. in a subsequent upscale.

Recommended text: Optionally, when a filtering radius is given, a custom convolution filtering with given resizer's kernel can be applied to new transients created by AddBorders and LetterBox filters. In these filters the transient areas (boundary of the new borders) are filtered, in order to prevent ringing e.g. in a subsequent upscale or also as additional artistic intent.

Current text: Everything is the same as mentioned above in Resizers in ConvertToXXXX section, except, that 'gauss' default parameters are tunes for blurring:

Recommended text: Everything is the same as mentioned above in Resizers in ConvertToXXXX section, except, that 'gauss' default parameters are tuned for anti-ringing processing for subsequent sinc-based interpolation giving 'flat/film' 'look/make up' of the filtered transient:


Current text: SincLinResize (clip, int target_width, int target_height,
float "src_left", float "src_top", float "src_width", float "src_height",
int "taps", int "force")
Typing error - SincLin2Resize

Current text: Internally, it is based on a sum of weighted sinc functions by b and c parameters. With b = c = 16, it is equivalent to SincResize with the given support size by the s parameter.

Recommended text: Internally, it is based on a sum of weighted sinc functions by b and c parameters. The weighting coefficients for second and third kernel members are computed as weight=(paramrter_value - 16) / 219 to be directly compatible with classic 8-bit narrow video levels range mapping. While the first kernel member weighting coefficient (virtual a-parameter) is internally fixed to 1.0. With b = c = 16, it is equivalent to SincResize with the given support size by the s parameter.

Current text: The default values of b and c (121/19) create a soft film-like look/makeup. It may be better to use sharper values like 80/-20 with higher 'sharpness/acutance'

Recommended text: The default values of b and c (121/19) create a soft film-like look/makeup. In the use cases where higher 'sharpness/acutance' is required for 'video' look/makeup - the values like 80/-20 may be recommended.

Current text: p
Parameter for GaussResize and SinPowerResize only.
Sharpness. Range from about 1 to 100, with 1 being very blurry and 100 being very sharp.
GaussResize
Default: 30.0

Recommended text: p
Parameter for GaussResize and SinPowerResize only.
Sharpness.

GaussResize

Default: 30.0. Range from 0.01 to 100, with 0.01 being very blurry and 100 being very sharp. Values below about 5 require manually increasing the support-size (s-parameter) or setting s-parameter to zero (auto-computed support size internally). If support-size is left too small with low p-parameter values it will cause non-linear distortions.

Recommended Notes addition:
All AVS+ core resizers use the same highly optimized 1 Dimensional convolution and resampling engine supporting all sample formats and bit depths. In 'no-resize' modes it is used as a convolution only engine. The only difference between different 'Resizers' is kernel function sent to the resampler and 'support' size set for processing. This causes all these resizing methods to produce some different output result in comparison with single-pass 2 Dimensional resampling engines (typically used in JincResize or typically EWA-prefixed resize methods) even if the same kernel functions is used.

For information 'support' size for different 'Resize' methods used:
PointResize - support 0.0001 (expect = 0)
BilinearResize - support 1.0
BicubicResize - support 2.0
LanczosResize, BlackmanResize, SincResize, SincLin2Resize - support=taps
Spline16Resize - support 2.0
Spline36Resize - support 3.0
Spline64Resize - support 4.0
GaussResize - support 4.0 (or defined by s-parameter or auto-calculated)
SinPowerResize - support 2.0 (fixed by design)
UserDefined2Resize - support is user-defined by s-parameter (default is 2.3)

[DTL]

It looks we have some issue with the resampling engine at handling 'edge conditions' -

Test script:

BlankClip(100, 100, 20, color=$7F7F7F, pixel_type="YV12")

near=AddBorders(0, 2, 0, 2, r=2)
far=AddBorders(0, 20, 0, 20, r=2)
far_crop=Crop(far, 0, 18, 0, -18)
near_black_expanded=AddBorders(near, 0,18, 0, 18, r=0)

StackVertical(near, far, far_crop, near_black_expanded)

LanczosResize(width*2, height*2, taps=16)

The created transient of radius=2 at the edge of frame should be valid for non-ringing resize. But sinc-based resizer still shows lots of ringing. If we add border length > taps number - the same created transient gives about non-ringed result at sinc-upsize to 2x.
Expected action of resampler at handling this edge case conditon - make extension of the last edge sample (duplicate) to the total kernel size of the resampler (make it equal to large-length added border). As last example.

Current workaround if resize required somewhere inside AVS - add border of enough size (to be comparable with resizer kernel size ?) and crop after resizing.

Addition: Tested with avsresize - it process edges as expected without ringing. So it is an issue in AVS+ resampler:


The use case of very small filtered borders transients: Add smoothing of top and bottom of the image of the wide-screen movies (like 2:35:1 cinema frame format) for playback at the TV-formatted 16:9 displays. Without smoothing we got some distraction of too sharp top and bottom edges of the frame if display's scaler do not provide service of some top+bottom image smoothing. Also the designer of the content may adjust smoothing to match internal image sharpness/look/makeup more precisely in comparison with some average image edges smoothing at playback device. 2 methods possible:

1. Add some new borders to the frame to save max useful samples but somehow increase frame size:
AddBorders(0,2,0,2,r=2, ... possible filter params to match image sharpness/look/makeup better)

2. Add internal small transient to black to top and bottom parts of frame. It more degrades original frame content but keep frame size unchanged:
LetterBox(2,2,0,0,r=2, ... possible filter params to match image sharpness/look/makeup better)

Example with wide-screen cinematic movie playback on 16:9 display:


Same applicable to left and right frame borders if adapt 4:3 old content to new 16:9 displays.

[Z2697]

Due to mirrored outside pixels perhaps?

[DTL]

Testing of padded-AVS+ resize vs avsresize and fmtconv with internal edge handling:

LoadPlugin("avsresize.dll")
LoadPlugin("fmtconv.dll")

Function Padded2xLanczosResize(clip c, int pad)
{
  padded=AddBorders(c,pad,pad,pad,pad, r=0)
  res_2x=LanczosResize(padded, padded.width*2, padded.height*2, taps=16)
  return Crop(res_2x,pad*2,pad*2,-pad*2,-pad*2)
}

Function Diff(clip src1, clip src2)
{
  return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
}

BlankClip(100, 200, 100, color=$7F7F7F, pixel_type="YV12")

AddBorders(2, 2, 2, 2, r=2, param1=8)


pad=50

std=LanczosResize(width*2, height*2, taps=16).Subtitle("AVS+ Std 2xLanczosResize taps=16", align=5)

avs_p=Padded2xLanczosResize(last, pad).Subtitle("AVS+ Padded2xLanczosResize taps=16", align=5)
avsr=z_ConvertFormat(width=width*2, height=height*2, resample_filter="lanczos", filter_param_a=16).Subtitle("avsresize lanczosResize taps=16", align=5)
fmtconv=fmtc_resample(w=width*2, h=height*2, kernel="lanczos", taps=16).Subtitle("fmt_conv lanczosResize taps=16", align=5)

d1 = Diff(avs_p,std)
#d2 = Diff(avs_p,avsr)
d2 = Diff(avsr,fmtconv)
d3 = Diff(avs_p,fmtconv)

StackHorizontal(StackVertical(std, avs_p, avsr), Stackvertical(d1, d2, d3))

The avsresize vs fmtconv is about equal (with about 1LSB difference at some corner samples) but all slightly different from 'padded resize'. The worst at r4246 is unpadded AVS+ (std) resize.

The padded versions of both avsresize and fmtconv also make some different outputs in comparison with unpadded resize by same engines. So different edges conditions handling workarounds (in different resize engines) gives still different results (vs padded method). It looks changing of kernel of resize filter in the 'resampling program' for handling edge conditions is not perfect way (but may give best performance because resampler process lowest data size).

LoadPlugin("avsresize.dll")
LoadPlugin("fmtconv.dll")

Function Padded2xLanczosResize(clip c, int pad)
{
  padded=AddBorders(c,pad,pad,pad,pad, r=0)
  res_2x=LanczosResize(padded, padded.width*2, padded.height*2, taps=16)
  return Crop(res_2x,pad*2,pad*2,-pad*2,-pad*2)
}

Function Padded2xLanczosResizeAVSR(clip c, int pad)
{
  padded=AddBorders(c,pad,pad,pad,pad, r=0)
  res_2x=z_ConvertFormat(padded, width=padded.width*2, height=padded.height*2, resample_filter="lanczos", filter_param_a=16)
  return Crop(res_2x,pad*2,pad*2,-pad*2,-pad*2)
}

Function Padded2xLanczosResizeFMTC(clip c, int pad)
{
  padded=AddBorders(c,pad,pad,pad,pad, r=0)
  res_2x=fmtc_resample(padded, w=padded.width*2, h=padded.height*2, kernel="lanczos", taps=16)
  return Crop(res_2x,pad*2,pad*2,-pad*2,-pad*2)
}


Function Diff(clip src1, clip src2)
{
  return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
}

BlankClip(100, 200, 100, color=$7F7F7F, pixel_type="YV12")

AddBorders(2, 2, 2, 2, r=2, param1=8)


pad=50

std=LanczosResize(width*2, height*2, taps=16).Subtitle("AVS+ Std 2xLanczosResize taps=16", align=5)

avs_p=Padded2xLanczosResize(last, pad).Subtitle("AVS+ Padded2xLanczosResize taps=16", align=5)
avsr_p=Padded2xLanczosResizeAVSR(last, pad).Subtitle("avsresize Padded2xLanczosResize taps=16", align=5)
fmtc_p=Padded2xLanczosResizeFMTC(last, pad).Subtitle("FMTC Padded2xLanczosResize taps=16", align=5).ConvertBits(8)
avsr=z_ConvertFormat(width=width*2, height=height*2, resample_filter="lanczos", filter_param_a=16).Subtitle("avsresize lanczosResize taps=16", align=5)
fmtconv=fmtc_resample(w=width*2, h=height*2, kernel="lanczos", taps=16).Subtitle("fmt_conv lanczosResize taps=16", align=5)

d1 = Diff(avs_p,std)
#d2 = Diff(avs_p,avsr)
#d2 = Diff(avsr,fmtconv)
#d2 = Diff(avsr,avs_p)
#d3 = Diff(avs_p,fmtconv)

d2 = Diff(avsr,avsr_p)
d3 = Diff(fmtconv, fmtc_p)


StackHorizontal(StackVertical(std, avs_p, avsr), Stackvertical(d1, d2, d3))