fmtconv/Avisynth+: resize, bitdepth and colorspace conversions

[cretindesalpes]

I just ported my fmtconv (https://forum.doom9.org/showthread.php?t=166504) Vapoursynth plug-in to Avisynth+.

>>> fmtconv-r31.zip <<< (https://ldesoras.fr/src/vs/fmtconv-r31.zip)

Fmtconv is a format-conversion plug-in for the Vapoursynth and Avisynth+ video processing engines. It does:

Resizing and convolution.
Bitdepth conversion with dithering.
Colorspace conversion (matrix, transfer characteristics and chromatic adaptation).

Supports:

8-–12-, 14- and 16-bit integer, 32-bit float
Colorspaces: RGB, Y, YUV, YCoCg, YDzDx and ICtCp in 4:4:4, 4:2:2, 4:2:0 and 4:1:1 chroma subsampling factors.
Progressive and interlaced content.

Fmtconv is focussed primarily on quality and exactness rather than execution speed. This does not mean it is slow or unoptimized, but fmtconv is clearly not on par with the fastest equivalent 8-bit filters.

The full documentation is included in the zip file.

Source code is also available as Git repository (https://gitlab.com/EleonoreMizo/fmtconv).

Please note:
This plug-in will work only in Avisynth+ (v3.7.0 and above), not in regular Avisynth, because it makes extensive use of the new high-bitdepth colorspaces. Stack-16 format is not supported.
Fmtconv is not internally threaded at the moment (excepted resample that can use AVSTP (https://forum.doom9.org/showthread.php?t=164407)), but could be if there is a real need. All the functions support the MT_NICE_FILTER multi-treaded mode. Enabling multi-threading is currently not automatic, you have to activate it from your scripts with SetFilterMTMode (http://avisynth.nl/index.php/SetFilterMTMode) and use the Prefetch function at the right location. This may change later.
32-bit version is strongly discouraged. I may remove it completely in the future.
The whole thing is complex and testing every parameter combination is impossible. The core functionalities work and have been tested for several years with Vapoursynth, but the Avs+ interface is new and may have related issue. Please report here anything suspicious, I’ll try to fix it as soon as possible.
Documentation lacks examples for Avs+, but this will come later.

[Dogway]

Thanks a lot! Will play with it today. I still have to finish TransformsPack but fmtconv will come handy to double check results.
Finally can use Void and Cluster! :thanks:

[Reel.Deel]

Thank you very much cretindesalpes! :thanks:
Nice to see you back around :)

[real.finder]

thanks for avs+ porting


Fmtconv is not internally threaded at the moment, but could be if there is a real need. All the functions support the MT_NICE_FILTER multi-treaded mode. Enabling multi-threading is currently not automatic, you have to activate it from your scripts with SetFilterMTMode (http://avisynth.nl/index.php/SetFilterMTMode) and use the Prefetch function at the right location. This may change later.


isn't fmtconv used to use avstp?

[kedautinh12]

thanks for avs+ porting



isn't fmtconv used to use avstp?

You will replace dither with fmtconv in your scripts???

[cretindesalpes]

real.finder:

LOL right, I wrote this too quickly!
Indeed resample can use AVSTP if available.

[real.finder]

You will replace dither with fmtconv in your scripts???

yes, I plan to do that for at least nnedi3_resize16 now, I will think about the others later

[real.finder]

real.finder:

LOL right, I wrote this too quickly!
Indeed resample can use AVSTP if available.

I did try

LoadPlugin("C:\a\avstp.dll")
LoadPlugin("C:\b\fmtcavs.dll")
ColorBars(width=640, height=480, pixel_type="yv12")
ConvertBits(16).fmtc_resample(Width(),Height()*2).fmtc_resample(Width(),Height()).ConvertBits(8)


I can't see any multi threaded speed with avstp

[FranceBB]

Nice one.
It's good to see you back. :)

[cretindesalpes]

real.finder:

1. Make sure that avstp.dll is found by the fmtconv. Check the thread list with Process Explorer or any other task manager.

2. resample splits its workload in tiles, which are dependent on the resizing parameters and input clip. The tiles are processed in different threads. If there is only one tile per frame, there won’t be any gain.

Anyway fmtconv has only minimal support for avstp at the moment, because it was primarily developed for Vapoursynth which handles threading very well natively and it doesn’t need avstp at all. If threading is still a performance issue on Avisynth+, I’ll add a better threading support.

[real.finder]

2. resample splits its workload in tiles, which are dependent on the resizing parameters and input clip. The tiles are processed in different threads. If there is only one tile per frame, there won’t be any gain.
yes with fmtc_resample(Width()*2,Height()*2).fmtc_resample(Width(),Height()) I can see the speedup!

[kedautinh12]

Don't sure about problem of avstp or mvtools2. If you have freetime, can you check it??
https://forum.doom9.org/showthread.php?p=1942642#post1942642

[StvG]

Thanks for porting the filter.

It seems i420 is not supported.
FFVideoSource() #yuv 8-bit input
fmtc_bitdepth(16) # error

Edit: Converting yuv < 32-bit to yuv 32-bit: _ColorRange is still 1. Shouldn't be 0?

[cretindesalpes]

It seems i420 is not supported.
Got it. I was naively trying to build a I420 high-bitdepth format which is not supported by Avs+. It is now converted to a regular YUV420Pxx. Here (http://ldesoras.free.fr/src/vs/fmtconv-avs-bin.zip) are some fixed binaries that you can try in the meantime of a new release.

Converting yuv < 32-bit to yuv 32-bit: _ColorRange is still 1. Shouldn't be 0?
The _ColorRange property has no meaning for floating point formats. So I just keep it as a trace of the original format. Should I erase it? I don’t know. What is the common practice in this case?

[StvG]

The _ColorRange property has no meaning for floating point formats. So I just keep it as a trace of the original format. Should I erase it? I donÂ’t know. What is the common practice in this case?

There is still no common practice... I think. I was curious because:
1. If you do yuv < 32-bit to 32-bit (default options) you have limited->full range.
2. If you do yuv < 32-bit + fulls=true (mimic internal conversion functions) to 32-bit you have no range range expand.

You have same _ColorRange for both cases.

Edit: Thanks for the new binaries.

[StvG]

Can you add top left cplace for fmtc_resample?

[cretindesalpes]

Yes, this can be accommodated.

[DTL]

I can suggest next additions:
1. Add also sinc interpolation as option to lmpulse kernel setting - as made in UserDefined2Resize in jpsdr plugins. I like an idea of extending filter support as user-provided setting instead of hardcoded value.
2. Add option to weight to zero at the end some end lobes of sinc resample kernel (for example linear-trapezioid as made in SincLin2Resize). So users can use sinc resize with lower taps value without computational issue at the end of kernel when taps lower about 70.

[cretindesalpes]

I can suggest next additions:
1. Add also sinc interpolation as option to lmpulse kernel setting
You mean replacing the current linear interpolation with a sinc one? This would make the function unnecessarily complex, especially for a niche functionality. Because sinc is infinite and has to be windowed. But which window? How long? It is expected that the user provides a pre-oversampled kernel (64x is more than enough), the linear interpolation is just here to square the aliasing level (-25 dB goes to -50 dB) at almost no cost, computationally (when generating the final kernel) and spatially.

2. Add option to weight to zero at the end some end lobes of sinc resample kernel.
blackman (https://en.wikipedia.org/wiki/Window_function#Blackman_window), blackmanminlobe (https://en.wikipedia.org/wiki/Window_function#Nuttall_window,_continuous_first_derivative) and lanczos (https://en.wikipedia.org/wiki/Window_function#Lanczos_window) are already sinc kernels of adjustable length with a window. But I can add a configurable Tukey (https://en.wikipedia.org/wiki/Window_function#Tukey_window) window; I’m not sure how useful it would be, but this is not much work anyway.

[DTL]

"replacing the current linear interpolation with a sinc one?"

Adding sinc interpolation option and a user-accessible switch to select between old linear and new sinc.

"Because sinc is infinite and has to be windowed. But which window?"

Simple 'natural-box-window' of filter-support that is not require additional computation or programming.
I.e. filter-support is about (number_of_user_provided kernel samples)*2+1.
Also I see you have filter support as user-definable in the field value and the Impulse may be array of any number of values. It greatly expands functionality of UserDefined2 function based on limited ability of passing only 2 kernel members via equivalent of BicubicResize 2-user arguments instead of unlimited list. I do not know how to pass any required number of user-provided kernel samples as an array so currently we have only fixed by 2 kernel samples UserDefined2 (in the plans are UserDefined4 or more) but if Avisynth API allow to pass any required kernel members in user-provided in the field array it is much better. For example for more precise test data generation we need up to 10 kernel members. They are provided in the book by Krivosheev in about 197x or 198x year (when engineers was high level and think about new digital video systems as very precise and high quality not what awful mix that we got today in 202x).

"It is expected that the user provides a pre-oversampled kernel "

Using sinc-interpolation allow to provide very short number of kernel samples down to 2 and it already works very well. For typical user to provide even 2 kernel samples is not very easy task. One of the main idea from that book about impulse responce of ideal band-limited data - if it is designed as a linear sum of weighted sincs it will be band-limited (close to ideally as sinc itself) with any values of weighting samples. And linear interpolation require user to provide highly oversampled kernel array as I see.

"blackman, blackmanminlobe and lanczos are already sinc kernels of adjustable length with a window. But I can add a configurable Tukey window; I’m not sure how useful it would be, but this is not much work anyway."

The most 'classic DSP/math' windows have special purposes in the other domain - like having special form of Fourier transform. And here we just make bug-fixed sinc resize for the very limited number of taps to get enough computation speed. And as the best bugfix it is better to have self-configured bugfix window without user thinking about it. From my quick tests simple trapezoidal starting from taps/2 works about good and not require additional user input and allow to lower non-visible distortions level taps number from about 70 to about 10 that is good speed increase because with typical good conditioned data we rarely need >10 or >20 taps in sinc kernel to good restore highest possible frequences. And set taps >70 for just fix end of kernel calcultaion issue is wasting of time and resources. Ofcourse it is better to search for better possible window to make sinc resize possible with as low taps as possible without that end of kernel issue _but_ still keeping as much as possible 'full-strike/full-blood' sinc lobes untouched for better restoration of highest valid frequencies with lowest possible kernel taps and so lowest possible filter support and highest possible computing speed.

It may be called 'fixed-sinc' without direct naming of the weighting window because it is programmer-side. The requirements for the window:
1. Work without computational errors at the end of kernel at least with 8bit output integer precision (for >8bit may be more taps or adjustments of window required)
2. Restore with higher possible amplitude the highest valid frequencies with equal number of taps with typical windows like Lanczos. Because we can set Lanczos with taps >50 and have about 10 starting lobes of sinc almost untouched but speed will be less in compare with sinc(taps=10).

Here is current state:
For linear in space and in levels test sequence (16), 27,132,235,132,27,(16)
Test pattern file link https://www.sendspace.com/file/ubhv78 . It is not 2D-ideal elementary point but for exact H and V directions from center it about good conditioned against ringing for sinc-based workflow.
Script

LoadPlugin("fmtcavs.dll")
LoadPlugin("ResampleMT.dll")

ImageReader("1_point_132_27_lim_lin.bmp")

ConvertToPlanarRGB()

#fmtc_resample(width*10, height*10, kernel="sinc", taps=10)
SincLin2ResizeMT(width*10, height*10, taps=10)

ConvertToRGB24()

Levels(10,1,50,0,255)

Results:
https://i5.imageban.ru/out/2021/08/26/396c1df1dbbb90b228a58a93f6cd4127.png
https://i6.imageban.ru/out/2021/08/26/6bcdc69aecc51e541c480c8cd871c14a.png
https://i4.imageban.ru/out/2021/08/26/26c22e0466aac8aefffadc9e394da833.png

Also the overall field of fmtc output is unclear with looks like +-1 LSB ringing error - may be something wrong with conversion from float to int like +0.5f rounding shift missed or added or compiler error with float to int conversion or other.

[cretindesalpes]

Also the overall field of fmtc output is unclear with looks like +-1 LSB ringing error - may be something wrong with conversion from float to int like +0.5f rounding shift missed or added or compiler error with float to int conversion or other.
fmtc_resample() outputs at least 16-bit data, so the subsequent ConvertToRGB24() has to convert the bitdepth too, and this is where lies the problem. Use fmtc_bitdepth(bits=8) or ConvertTo8bit(dither=1) in between.

EDIT: there’s also a bug with the fulls and fulld parameters in fmtc_resample, declared as int instead of bool as they should be. I will fix this quickly.

[Dogway]

Does fmtc_resample support jinc function? I'm trying to find out if I can use N.Robidoux ewa_lanczossharp with lobes = 3.2383154841662362 and blur = 0.9812505644269356.

[cretindesalpes]

That’s pretty accurate constants! But no, jinc is not supported at the moment.

[DTL]

"Use fmtc_bitdepth(bits=8)"

Yes - it helps. Though as it plugin for Avisynth - may be made its default output compatible with ConvertToRGB(24) and may be other without special steps. Some users may miss required steps for more quality result and got distortion.

[cretindesalpes]

I’m very likely to remove the planes parameter from fmtc_transfer introduced in r24. I added it because it was almost free, but with the upcomping addition of OOTFs, planes are no longer independant, and the parameter is making the implementation too complicated for my taste. Any objection?

[Quadratic]

"Use fmtc_bitdepth(bits=8)"

Yes - it helps. Though as it plugin for Avisynth - may be made its default output compatible with ConvertToRGB(24) and may be other without special steps. Some users may miss required steps for more quality result and got distortion.
fmtc was originally made for Vapoursynth, asking the developer to go out of their way to consider the behavior of decade-old functions is absurd. Avisynth users need to learn how to control their scripts and stop relying on internal operations.

Levels() may introduce some error when being used at RGB24, it would be better for you to perform that operation when the clip is still of high precision.

[DTL]

"a sinc one?"

I made some simulation with sinc-summing tool and made bc and bcde coefficients table for (almost) non-ringing kernel.
With conversion or bc(de) values to kernel program:

Filter(double _b, double _c) // same for d,e
{
a = 1.0; // 0 sample = 1
b = (double)clamp(_b, -50.0, 250.0); // 1 and -1 sample
c = (double)clamp(_c, -50.0, 250.0); // 2 and -2 sample
b = (b - 16.0) / 219.0;
c = (c - 16.0) / 219.0;
// same for d,e

}

double sinc(double value)
{

if (fabs(value)>0.000001)
{
value *= M_PI;
return sin(value)/value;
}
else return 1.0;
}

double Filter::f(double x) // kernel output
{
x = fabs(x);

if (x<=3)
// - here is rect window of kernel and =support, <=5 for bcde, practically with non-ringing bc(de) params this kernel is self-windowed outside 3..5 around center,
// i.e. it is both real space and Fourier-space constrained, so do not suffer from any significant members cut-off by rect window of enough size and Gibbs-effects
{
return c*sinc(x+2) + b*sinc(x+1) + a*sinc(x) + b*sinc(x-1) + c*sinc(x-2); // for bc
// for bcde
// return e*sinc(x+4) + d*sinc(x+3) + c*sinc(x+2) + b*sinc(x+1) + a*sinc(x) + b*sinc(x-1) + c*sinc(x-2) + d*sinc(x-3) + e*sinc(x-4);

}
else return 0;

}


The required number of user-provided samples very quickly fades and last e-member usually about zero (16 code value). And using bcd instead of bc allows to have lower level of ringing at high overshooting kernels or higher overshooting with less ringing.
https://i4.imageban.ru/out/2021/08/30/23ad291161c5f75384738ceaed2600db.png

[tormento]

I just ported my fmtconv

I am having an AviSynth exception when playing the following AVS with VirtualDub2 or encoding with x256 --crf 22 --preset slow --output-depth 10 --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --input-depth 10, any idea?

Source is 1080p anime.

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\Eva01\eva01.dgi")
ConvertBits(16)
SMDegrain(tr=4,thSAD=400,refinemotion=true,contrasharp=false,PreFilter=4,plane=4,chroma=true)
fmtc_bitdepth(bits=10,dmode=8)
Prefetch(6)

It works ok if I set fmtc_bitdepth(bits=8,dmode=8) or use a plain ConvertBits(10) instead.

[cretindesalpes]

tormento: Indeed, it is fixed now.

fmtconv r25 (https://forum.doom9.org/showthread.php?t=183139) is mostly a bug-fix release:
bitdepth/Avisynth+: fixed I420 input that couldn’t be converted to higher bitdepth. Thanks to StvG for the report.
matrix: fixed the output colorspace autodetection which failed with specific matrix combinations.
resample/Avisynth+: fixed fulls and fulld parameters which were wrongly defined as int instead of bool.
resample/Avisynth+: fixed cplaced which was wrongly copied from cplaces. Thanks to TbtBI for the report.
transfer: automatically adapts the output format (16-bit integer) if the input is a low-bitdepth clip and nothing is specified in bits nor flt, instead of emitting an error.
transfer: fixed the BT.2100 HLG curve that was inverted.
transfer: fixed the sRGB curve linear part and extended its positive range. Thanks to poisondeathray for the report.
Avisynth+: fixed a crash occuring when using data bitdepths between 9 and 14. Thanks to tormento for the report.

[tormento]

Indeed, it is fixed now.
Thank you, will try ASAP!

[DTL]

The download link in the first post for r25 do not work for unknown reason and github link only shows r24 build release. Though source code shows update to r25. Why no r25 release at github for download ?

[StainlessS]

r25 first post link works for me [just now], and worked on 19th sept too.

[real.finder]

r25 first post link works for me [just now], and worked on 19th sept too.

same, anyway there are also https://web.archive.org/web/20210919222003/http://ldesoras.free.fr/src/vs/fmtconv-r25.zip

[cretindesalpes]

Yes sorry I forgot to make a “Github release”. This is now done.

[DTL]

Yes - in r25 the HLG transfer looks like works much better.

Can I make LPF (convolution) with such impulse response using 'impulse' kernel setting:
https://i2.imageban.ru/out/2021/09/22/4e627652febaa9e86d1d64b11d2de4ee.png

Or direct 1/2 downsize of chroma planes with this kernel pre-filtering. I too lazy to program another kernel for Avisynth resampler (also known as having some bugs at the edges) to test it and remember fmtc provides some functionality for user-defined kernels. It is for 4:4:4 to 4:2:2 chroma subsampling operation. How to correctly define 'impulse' kernel is possible ? Do I need to interpolate it somehow or direct samples like half or full width (both) sides possible like 0.5;0.315;0;-0.09... ?

[cretindesalpes]

You can downsample the chroma like this:

ColorBars (pixel_type="YV24")
imp = [-0.00643, 0, 0.014234, 0, -0.027172, 0, 0.049515, 0, -0.097162, 0, 0.315252,
\ 0.5, 0.315252, 0, -0.097162, 0, 0.049515, 0, -0.027172, 0, 0.014234, 0, -0.00643]
fmtc_resample (Width (), Height (), css="420", kernel="impulse", impulse=imp, kovrspl=2)

Because your kernel is already a half-band filter, you have to specify that it is 2x oversampled with kovrspl. Custom kernels are expected to be full-band. If you just want to convolve without decimating, remove the css parameter, set kovrspl=1 and add fv=-1, fs=-1 to make sure that the convolution is not optimized out because source and destination windows are identical. However all planes will be processed, so you’ll have to specify planes=[2, 3, 3] to bypass the luma plane.

I realize that I forgot to mention in the doc that "impulse" should be specified as kernel parameter when using custom kernel, otherwise fmtc_resample ignores it.

Edit: oops it seems that planes doesn’t do anything here, another bug to fix…

[real.finder]

You can downsample the chroma like this:

ColorBars (pixel_type="YV24")
imp = [-0.00643, 0, 0.014234, 0, -0.027172, 0, 0.049515, 0, -0.097162, 0, 0.315252,
\ 0.5, 0.315252, 0, -0.097162, 0, 0.049515, 0, -0.027172, 0, 0.014234, 0, -0.00643]
fmtc_resample (Width (), Height (), css="420", kernel="impulse", impulse=imp, kovrspl=2)

Because your kernel is already a half-band filter, you have to specify that it is 2x oversampled with kovrspl. Custom kernels are expected to be full-band. If you just want to convolve without decimating, remove the css parameter, set kovrspl=1 and add fv=-1, fs=-1 to make sure that the convolution is not optimized out because source and destination windows are identical. However all planes will be processed, so you’ll have to specify planes=[2, 3, 3] to bypass the luma plane.

I realize that I forgot to mention in the doc that "impulse" should be specified as kernel parameter when using custom kernel, otherwise fmtc_resample ignores it.

Edit: oops it seems that planes doesn’t do anything here, another bug to fix…

impulse can work with array? it should be array parameter then https://github.com/AviSynth/AviSynthPlus/issues/226#issuecomment-914035294

[DTL]

It works close to as expected with command

fmtc_resample(impulse="-0.00643,0,0.014234,0,-0.027172,0,0.049515,0,-0.097162,0,0.315252,0.5,0.315252,0,-0.097162,0,0.049515,0,-0.027172,0,0.014234,0,-0.00643", fh=-0.5, fv=-0.5, cnorm=true,center=false,fulls=true, fulld=true)

Looks like it is not scaled in that table for input sampling, so fh and fy is -0.5. Also normalization enabled.

"kernel="impulse""

List of 'kernel' param values do not have 'impulse' value in the provided documentation.

" "impulse" should be specified as kernel parameter when using custom kernel, otherwise fmtc_resample ignores it."

It looks like working here with version r25 even without setting kernel="impulse".
The result have significally wider transient field in compare with provided amplitude-frequency response at that drawing and in compare with hard cuf-off lowpass with something like

SincResize(width/2,height/2,taps=16)
SincResize(width*2,height*2,taps=16)


Source:
https://i1.imageban.ru/out/2021/09/23/54d40a2105f86c3fbc88658548c4f11f.png

This impulse kernel process with command above:
https://i7.imageban.ru/out/2021/09/23/519afd0804023b13d86781b7ecbcfeb1.png

SincResize down and up
https://i1.imageban.ru/out/2021/09/23/cae97582abd1dc0445edd01a4ed990be.png

[DTL]

Is it a bug in fmtc_transfer (2084):


LoadPlugin("fmtcavs.dll")

BlankClip(100,100,100,color=$101010, pixel_type="RGB24")
Trim(0,1)
ConvertToRGB24(matrix="PC.709")

ConvertToPlanarRGB()
ConvertBits(16)

fmtc_transfer(transs="2084", transd="linear", fulls=true, fulld=true,bits=32, flt=true)

fmtc_transfer(transs="linear",transd="2084", fulls=true, fulld=true)
fmtc_matrix(mat="2020",fulls=true,fulld=true)
ConvertBits(10)


Output Y'=0x004C.
0x0040 expected (in 709 and hlg it is).

It looks fmtc_transfer(transs="2084", transd="linear", fulls=true, fulld=true,bits=32,flt=true) do not switches to float(32) RGBPS (silently, no error raised), stays in RGBP16 and lost precision.
fmtc_transfer(transs="2084", transd="linear", fulls=true, fulld=true,bits=32) - switches to RGBPS and output OK.
flt is not listed in Avisynth syntax but somehow works and produces bugs in Avisynth. May be raise an error in Avisynth if flt is in arguments with any type of argument ?

[cretindesalpes]

real.finder:

Yes impulse can be an array of float or a string containing printed numbers separated with a space. That’s why it is a '.' variant type.

DTL:

You have to specify kernel="impulse" for custom kernels. Otherwise the default kernel is used (spline36). Your picture shows the spline36 kernel, not the custom one.

You can set fh and fv to -0.5 but IMHO for this case it makes more sense to specify that the kernel is oversampled.

For the HLG curve, indeed adding
ScriptClip ("""Subtitle (String (AverageLuma ()))""") at the end of the script shows 76 with r25, I don’t know exactly why. However my current build displays 64 as expected. I’m doing a lot of modifications to transfer which are not committed yet, so I guess I fixed it while I was about it. Current transfer works always in integer with integer input, because it is just a LUT. But the result should be exact if target format is floating point.

I also fixed the flt and bits combination in resample.

[real.finder]

array with only '.' variant type will not be work in next update of avs+ unless it become '.+'

[cretindesalpes]

This is really unfortunate so I read in the readme for the 3.6.0 release that ".+" and ".*" cannot be followed by other arguments. Does this mean that I can only have one parameter like this per function? I tried to replace every "." with ".+" or ".*", but this crashes Avisynth+. Is there any workaround or should I remove the arrays and keep only the strings?

[kedautinh12]

Avs+ last ver
https://forum.doom9.org/showthread.php?p=1953038#post1953038

[pinterf]

This is really unfortunate so I read in the readme for the 3.6.0 release that ".+" and ".*" cannot be followed by other arguments. Does this mean that I can only have one parameter like this per function? I tried to replace every "." with ".+" or ".*", but this crashes Avisynth+. Is there any workaround or should I remove the arrays and keep only the strings?
Do you have them as named arrays, or unnamed ones?
It is true that unnamed-untyped arrays can appear only as the very last parameter in Avisynth. But when they have names and you pass their values with name specifier, well, this has to work.
(at least in latest 3.7.1 test version, which has some fixes regarding array parameters, mainly because of script array syntax)
If your array can hold only strings/floats then specify the array with the exact type, e.g. "[paramname]s+" or "[coeffs]f+".

[StainlessS]

I know very little (nothing) about these new array things, but I know I can use named optional args after data arrays.


env->AddFunction("RT_WriteFile", "ss.*[Append]b",RT_WriteFile, 0);



RT_WriteFile(String FileName, string format, dat1, ... , datn, bool "Append"=False)


Where (unnamed) data args [dat1 ... datn] can be zero or more of any type (except clip in this case - internally trap/abort on clip args), and if you need to specify "Append" arg, then have to use eg "Append=True" with explicit (optional) name, ie name not optional and must be specified.

I would think this would work (or could be made to work) with new arrays too.

EDIT: Above works in v2.58, v2.57 too I think, and maybe prior to that.

EDIT: works

RT_WriteFile(".\temp.txt","%d # comment=%s",current_frame,"some text",Append=true)

dont work (true interpreted as data arg, function throws error as format string specifies int %d and string %s data args only expected)

RT_WriteFile(".\temp.txt","%d # comment=%s",current_frame,"some text",true)

[cretindesalpes]

pinterf:

Yes, the parameters are named. I didn’t pay attention to this aspect when reading the readme, so finally there isn’t any problem here.

Anyway the ".+" behaviour is slightly different of ".". When reading its value on the plug-in side, the parameter is always set as defined and typed as an array, possibly empty. If the parameter is set by the user to a single value (not an explicit array), this value comes as the first member of the array instead of being the parameter itself. However this is not a big deal, I wrote some code to work around it.

[real.finder]

Anyway the ".+" behaviour is slightly different of ".". When reading its value on the plug-in side, the parameter is always set as defined and typed as an array, possibly empty. If the parameter is set by the user to a single value (not an explicit array), this value comes as the first member of the array instead of being the parameter itself. However this is not a big deal, I wrote some code to work around it.

in last update Avisynth+ 3.7.1 test build 17 (20210924) .+ should not always set as defined, but yes it always array

[tormento]

@cretinedesalpes

What can we use as a "modern" version of GradFun3 after your last releases? I have a badly mastered anime with coarse banding and I would like to try to smooth it out.

[cretindesalpes]

Tools included in the Dither package remain unchanged at the moment. You can still use GradFun3, it works.

[DTL]

Is this an issue with full/limited:

LoadPlugin("fmtcavs.dll")

plY=Blankclip(width = 10, height = 1, pixel_type="Y10").Expr("sx 0 == 64 sx 1 == 64 sx 2 == 64 sx 3 == 64 sx 4 == 64 sx 5 = 64 sx 6 = 64 sx 7 == 64 sx 8 == 64 64 ? ? ? ? ? ? ? ? ?")
plU=Blankclip(width = 5, height = 1, pixel_type="Y10").Expr("sx 0 == 512 sx 1 == 512 sx 2 == 512 sx 3 == 512 512 ? ? ? ?")
plV=Blankclip(width = 5, height = 1, pixel_type="Y10").Expr("sx 0 == 512 sx 1 == 512 sx 2 == 512 sx 3 == 512 512 ? ? ? ?")
CombinePlanes(plY, plU, plV, "YUV", "YYY", pixel_type="YUV422P10")

ConvertToYUV444()

PointResize(500,500)
ScriptClip ("""Subtitle (String (AverageLuma ()))""")

rgb_lin=fmtc_matrix(mat="RGB", mats="2020",fulls=false, fulld=false)
rgb_lin=fmtc_transfer(rgb_lin,transs="hlg",transd="linear",bits=32,fulls=false, fulld=false)

return fmtc_transfer(rgb_lin,transs="linear",transd="709",fulls=false, fulld=false).ConvertBits(8).ConvertToRGB()

return R'G'B' 0,0,0.
expected 16,16,16 (limited black).
I hope input to fmtc part of processing is Y=64, U=512, V=512 (10-bit black limited). ScriptClip(AverageLuma) confirms Y=64.00.