AviSynth+ thread Vol.2

[feisty2]

you go ahead delete your posts if you want, I won't, I am not a big fan of self-censorship.

edit: for davidh, the definition of self-censorship (https://www.merriam-webster.com/dictionary/self-censorship): the act or action of refraining from expressing something (such as a thought, point of view, or belief) that others could deem objectionable. the perfect word for what you just did.

[wonkey_monkey]

Not what the word means but okay...

Self-censoring is quite distinct from censorship. That's why it has "self-" in front of it.

I deleted my posts not for their objectionality but because they were off-topic.

[pinterf]

O.K., by popular demand I consider integrating brainfuck language (https://en.wikipedia.org/wiki/Brainfuck) elements into Expr :)

[ChaosKing]

Finally something I can understand easily!

[Myrsloik]

O.K., by popular demand I consider integrating brainfuck language (https://en.wikipedia.org/wiki/Brainfuck) elements into Expr :)

We'll soon announce a commercial implementation of Expr that uses whitespace as the programming language. It's the only way to ensure nobody can read secret corporate scripts and is one of the most requested features in VapourSynth. The backend will be obviously be based on freepascal.

[wonkey_monkey]

pinterf, do you know if there's any documentation for jitasm? I see references to a "GettingStarted wiki" but I don't know where to find that or if it still exists. I'm slowly grasping it through reading exprfilter.cpp but I could use the context of an actual guide.

[GMJCZP]

pinterf, do you know if there's any documentation for jitasm? I see references to a "GettingStarted wiki" but I don't know where to find that or if it still exists. I'm slowly grasping it through reading exprfilter.cpp but I could use the context of an actual guide.

Will this do?
Here (https://asmjit.com/doc/index.html)

[Dogway]

Thanks for the update pinterf. I got the Sorting Network to work, it is not THAT slow though. Given that the top speed one can get with a median in Expr is "undot" (min and max clamp), sorting is only 18% below in performance. It's fine for implementing exotic kernels and use in production. The only problem I see is that unlike ex_boxblur() median Expr can't match removegrain speed, and the only difference is the operator used (min and max), since pixel fetching is shown to give the same performance. I do think there might be room for improvement but can't actually tell as I don't understand CPP.

# 100% removegrain(1,-1)
# 83% ex_median(mode="undot",UV=1)
# 65% ex_median(mode="undot2",UV=1) # 301fps
# 1.2% MedianBlur(1,0,0)

I wanted to implement your median of 3 and 5 kernels, but didn't understand the code. What is the window size, 3x3? So I actually tested it and it matched removegrain(4,-1) (for radius 1). I think there's value for the MedianBlur plugin because it can use bigger kernels and also temporal, but the performance of 6fps struck me a bit.

# mode name prone to change (suggestions welcome :P )
mode == "undot2" ? "x[-1,1] A^ x[0,1] B^ x[1,1] C^ x[-1,0] D^ x[1,0] E^ x[-1,-1] F^ x[0,-1] G^ x[1,-1] H^ " \
+"A C min AA^ A C max CC^ " \
+"B D min BB^ B D max DD^ " \
+"E G min EE^ E G max GG^ " \
+"F H min FF^ F H max HH^ " \
+"AA EE min A^ AA EE max E^ " \
+"BB FF min B^ BB FF max F^ " \
+"CC GG min C^ CC GG max G^ " \
+"DD HH min D^ DD HH max H^ " \
+"A B min AA^ A B max BB^ " \
+"C D min CC^ C D max DD^ " \
+"E F min EE^ E F max FF^ " \
+"G H min GG^ G H max HH^ " \
+"CC EE min C^ CC EE max E^ " \
+"DD FF min D^ DD FF max F^ " \
+"BB E min B^ BB E max EE^ " \
+"D GG min DD^ D GG max G^ " \
+"B C min BB^ B C max CC^ " \
+"DD EE min D^ DD EE max E^ " \
+"F G min FF^ F G max GG^ " \
+"x[0,0] BB GG clip" : \



@wonkey_monkey: I tested with the ternary option as I thought one ternary might be faster than min+max but I don't think your code example works.
"A C < Q@ A AA^ C CC^ ? Z^ Q C CC^ A AA^ ? Z^ "
I think Expr ternaries don't look for a true or false (in case Q@ catches that at all) but expect a comparison operator.

PD: I had a look at the MSVC compiler size, 40Gb, ouch!

[wonkey_monkey]

Will this do?
Here (https://asmjit.com/doc/index.html)

That's asmjit rather than jitasm, but actually yes, it will make for informative reading, so thanks!

[wonkey_monkey]

@wonkey_monkey: I tested with the ternary option as I thought one ternary might be faster than min+max but I don't think your code example works.
"A C < Q@ A AA^ C CC^ ? Z^ Q C CC^ A AA^ ? Z^ "
I think Expr ternaries don't look for a true or false (in case Q@ catches that at all) but expect a comparison operator.


A quick "fingers" test - lift a finger for each variable that gets added to the stack, lower a finger for each popstore or regular operator, lower two fingers for a "?" - suggests you've only got one item on the stack when you reach the "?"

Remember that everything before the "?" gets executed - all "?" does is select which of the two topmost stack items to remove. Maybe you meant AA@ and CC@, so as not to remove A and C from stack, but in any case both will then be overwritten by the next section anyway, as will the result you would have stored in Z.

So your code says:

Compare A and C (stack contains result)
Store result in Q (stack contains result)
Load A, but immediately store and pop into AA (stack contains result)
Load C, but immediate store and pop into CC (stack contains result)
? - needs three items on the stack so it fails


Also shouldn't the last line be:


x[0,0] FF GG clip"

?

[feisty2]

PD: I had a look at the MSVC compiler size, 40Gb, ouch!


GCC 11 (mingw-w64 target) is less than 100MB, and msvc is far less than 40GB if you only need C++ components.

[Dogway]

@wonkey_monkey: true, true, typo (^ for @). I was also overwriting the second ternary.

This thing is tricky, this should do it but it doesn't, so I will leave this here and think in the evening:

+"A C < Q@ A AA@ C CC@ ? Z^ Q C CC@ A AA@ ? Z^ "
+"B D < Q@ B BB@ D DD@ ? Z^ Q D DD@ B BB@ ? Z^ "
+"E G < Q@ E EE@ G GG@ ? Z^ Q G GG@ E EE@ ? Z^ "
+"F H < Q@ F FF@ H HH@ ? Z^ Q H HH@ F FF@ ? Z^ "
+"AA EE < Q@ AA AAA@ EE EEE@ ? Z^ Q EE EEE@ AA AAA@ ? Z^ "
+"BB FF < Q@ BB BBB@ FF FFF@ ? Z^ Q FF FFF@ BB BBB@ ? Z^ "
+"CC GG < Q@ CC CCC@ GG GGG@ ? Z^ Q GG GGG@ CC CCC@ ? Z^ "
+"DD HH < Q@ DD DDD@ HH HHH@ ? Z^ Q HH HHH@ DD DDD@ ? Z^ "
+"AAA BBB < Q@ AAA A@ BBB B@ ? Z^ Q BBB B@ AAA A@ ? Z^ "
+"CCC DDD < Q@ CCC C@ DDD D@ ? Z^ Q DDD D@ CCC C@ ? Z^ "
+"EEE FFF < Q@ EEE E@ FFF F@ ? Z^ Q FFF F@ EEE E@ ? Z^ "
+"GGG HHH < Q@ GGG G@ HHH H@ ? Z^ Q HHH H@ GGG G@ ? Z^ "
+"C E < Q@ C CC@ E EE@ ? Z^ Q E EE@ C CC@ ? Z^ "
+"D F < Q@ D DD@ F FF@ ? Z^ Q F FF@ D DD@ ? Z^ "
+"B EE < Q@ B BB@ EE EEE@ ? Z^ Q EE EEE@ B BB@ ? Z^ "
+"DD G < Q@ DD DDD@ G GG@ ? Z^ Q G GG@ DD DDD@ ? Z^ "
+"BB CC < Q@ BB BBB@ CC CCC@ ? Z^ Q CC CCC@ BB BBB@ ? Z^ "
+"DDD EEE < Q@ DDD D@ EEE E@ ? Z^ Q EEE E@ DDD D@ ? Z^ "
+"FF GG < Q@ FF FFF@ GG GGG@ ? Z^ Q GG GGG@ FF FFF@ ? Z^ "


The last line should be the second from the minimum and second from the maximum, since order is A B C D E F G H, I chose B G. I compared it against removegrain(2) anyway.

[wonkey_monkey]

This thing is tricky, this should do it but it doesn't, so I will leave this here and think in the evening:

I'm afraid you're still misunderstanding how "?" works. Could you start a new thread so we can discuss it there, or I can PM you?

[Dogway]

I have used ternaries for years now, this is rather a stack issue, posted here (https://forum.doom9.org/showthread.php?p=1947059#post1947059) a simplified code.

[qyot27]

It took several months, but I finally got around to working on a macOS installer package. 3.7.0 is available on the normal Releases page, in two forms:
High Sierra and Mojave builds (10.13 & 10.14)
Catalina and higher builds (10.15+)

And also filesonly tarballs if you'd rather skip the installer (although they do have shell scripts to help users unfamiliar with the process).

[wonkey_monkey]

Is there any way to load the contents of a text file as a string using built-in Avisynth functions? I can't seem to find one but maybe there is a trick.

[StainlessS]

Is there any way to load the contents of a text file as a string
Not that I ever found. [even trying to abuse Import() failed for me].

Only thing I'm aware of,

RT_ReadTxtFromFile(String ,Int "Lines"=0,Int "Start"=0)
Non-clip function.
String Filename, Name of text file to load into a string.
Lines=0=unlimited. Set to number of leading lines in text file to load, eg 1 = load only the first line of text file.
The return string is n/l ie Chr(10) separated, and carriage returns are removed from the returned string.
If source file was missing newline on very last line, it will append a newline so that all lines are similarly formatted.
v1.03, Added Start arg default=0=very first line (relative 0). Would have been nice to have start and lines in reverse
order but implemented as above to not break scripts.
Throws an error if your requested Start is >= to the number of lines in the file, or zero len file.
To fetch the last line of a text file, use eg Start = RT_FileQueryLines(Filename) - 1 (Start is zero relative).
You could eg get the last line of a d2v file which might look like this:- "FINISHED 100.00% VIDEO"

[pinterf]

Is there any way to load the contents of a text file as a string using built-in Avisynth functions? I can't seem to find one but maybe there is a trick.
Abusing ConditionalReader?
http://avisynth.nl/index.php/ConditionalReader

[pinterf]

It took several months, but I finally got around to working on a macOS installer package. 3.7.0 is available on the normal Releases page, in two forms:
High Sierra and Mojave builds (10.13 & 10.14)
Catalina and higher builds (10.15+)

And also filesonly tarballs if you'd rather skip the installer (although they do have shell scripts to help users unfamiliar with the process).
Congratulations!

[LigH]

:eek: AviSynth+ on Mac? Selur might enjoy that for Hybrid...

[DTL]

As users tried to use output of ColorBars() for resamplers testing ( https://forum.doom9.org/showthread.php?p=1947958#post1947958 ) it is recommended to add 'mode' parameter to ColorBars() internal function with at least 3 values:
1. 'pixel-art' (as today ColorBar() ouput)
2. 'film-look' ( I think it is default for real prof color bar generator)
3. 'video-look'

Possible processing is suggested in https://forum.doom9.org/showthread.php?p=1947974#post1947974 .

And may be at least put a note to Avisynth wiki about non-compatibility of current ColorBar() output for testing of 'film/video' motion pictures data processing software for quality and results of levels transition processing.

Linked wiki .pdf https://www.arib.or.jp/english/html/overview/doc/6-STD-B28v1_0-E1.pdf also notes about correct levels transitions preparation:

Annex A5: A.5 Transient
Ringing may occur when the stripe level of this color bar is suddenly changed, then this may possibly
cause operational inconvenience. Therefore, it is necessary to carry out design while limiting
bandwidths for leading edge and falling edge.
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”.

Also the older ITU recs describes some valid forms of levels transition in details:
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.801-1-199510-W!!PDF-E.pdf
Rec. ITU-R BT.801-1 (for SDTV)
Test signals for digitally encoded colour television signals conforming
with Recommendations ITU-R BT.601
and ITU-R BT.656
These digital waveforms are made up of pulses in uniform ranges, ramps between two uniform
ranges, and transitions between two uniform ranges, shaped by a filter whose impulse response R(t)
is defined as a function of time t as follows:
– for –3T < t < 3T, R(t) = 0.42 + 0.50 cos(π t/ 3T) + 0.08 cos(2π t/ 3T)
– otherwise R(t) = 0
(R(t): Blackman window).
The value of T is 74 ns for digital waveforms A1, A2, A3 and A4

And Rec. ITU-R BT.1729 https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.1729-0-200504-I!!PDF-E.pdf (for HDTV)
Rise and fall times of bar transitions
The 10% to 90% rise time and 90% to 10% fall time of the colour bars should be identical to each
other and should be consistent with the frequency response specifications in Recommendations
ITU-R BT.601, ITU-R BT.1358, ITU-R BT.1847, ITU-R BT.1543 or ITU-R BT.709, as
appropriate to the format2. The shape of the leading and trailing edges should be similar to a raised
cosine function.

[Dogway]

Just wanted to report that for some time I have been having issues with variables that start with the same letter:

mode == "edgeW" ? " y[0,0] I@ y[0,1] B@ - abs I y[0,-1] G@ - abs max BB^ " \
+"I y[1,1] C@ - abs I y[-1,-1] F@ - abs max CC^ I y[-1,0] D@ - abs I y[1,0] E@ - abs max DD^ " \
+"I y[-1,1] A@ - abs I y[1,-1] H@ - abs max BB min CC min DD min " \
+"DI@ DD == x D E dup1 dup1 min I min swap2 max I max clip DI BB == x B G dup1 dup1 min I min swap2 max I max clip " \
+"DI CC == x C F dup1 dup1 min I min swap2 max I max clip x A H dup1 dup1 min I min swap2 max I max clip ? ? ?" : \

If I change the DI variable to S, everything is fine again.

[wonkey_monkey]

Another little note, not on Expr per se but on Format and String, which are useful in preparing Expr expressions. They only expand floats to six decimal digits after the point, which could cause some unnecessary inaccuracy. I think you need around 9 or 10 significant digits to guarantee hitting the true closest floating point number. Could consideration be given to a higher-precision flag or variations of those functions?

Or even allow %a format: https://stackoverflow.com/questions/4826842/the-format-specifier-a-for-printf-in-c/10128764

[cretindesalpes]

I’m just installing AVS+ for the first time and suddenly I feel like a total newbie… So I have a question I cannot find the answer on the official website nor on the wiki:

What are the host applications compatible with 64-bit AVS+ ? For:
– Editing and previewing
– Piping
– Encoding

Also, maybe the installer should be a bit more clear that you can also keep intact your existing 32-bit AviSynth 2.5 just by unchecking the 32-bit dll. I needed to keep my 32-bit AVS 2.6 because I found incompatibilities with my existing plug-in set and the 32-bit AVS+.

[Sharc]

Also, maybe the installer should be a bit more clear that you can also keep intact your existing 32-bit AviSynth 2.5 just by unchecking the 32-bit dll. I needed to keep my 32-bit AVS 2.6 because I found incompatibilities with my existing plug-in set and the 32-bit AVS+.
You may find Groucho's Universal Avisynth Installer useful for easy switching between versions:
https://forum.doom9.org/showthread.php?t=172124

[Boulder]

What are the host applications compatible with 64-bit AVS+ ? For:
– Editing and previewing
– Piping
– Encoding


Editing and previewing : VirtualDub2 (https://sourceforge.net/p/vdfiltermod/wiki/Home/)
Piping : Avs2yuv64 (https://github.com/MasterNobody/avs2yuv/releases)
Encoding : f.ex. x264, x265 64-bit builds

[real.finder]

Editing and previewing : VirtualDub2 (https://sourceforge.net/p/vdfiltermod/wiki/Home/)


and/or AvsPmod https://forum.doom9.org/showthread.php?t=175823

maybe the installer should be a bit more clear that you can also keep intact your existing 32-bit AviSynth 2.5 just by unchecking the 32-bit dll. I needed to keep my 32-bit AVS 2.6 because I found incompatibilities with my existing plug-in set and the 32-bit AVS+.

the installer can keep the old 32 avs if you uncheck the avs+ 32, I always did this, my 32 avs always avs 2.6 MT by SEt, but I often use 64 so it's last avs+

[kedautinh12]

Megui
https://sourceforge.net/projects/megui/

[LigH]

StaxRip (github (https://github.com/staxrip/staxrip) / VideoHelp (https://www.videohelp.com/software/StaxRip))

[Dogway]

Use avpsmod by gispos. Works fine with latest AVS+ 3.7.1.
For encoding I use avs2pipemod64 as always and x264_r2935_x64(Ligh).
To debug I find avsmeter and AVSInfoTool great tools too. I also had issues on the past and this tells you what is set on the register.

[cretindesalpes]

Thank you all very much for your replies!

[FranceBB]

Wow! @Cretindesalpes, you're back! :D
It's nice to see the creator of Dither Tools getting Avisynth+ for the very first time.
You won't ever feel the need to go back to the normal Avisynth, I can tell you that, you'll love AVS+ ;)

[kedautinh12]

Wow! @Cretindesalpes, you're back! :D
It's nice to see the creator of Dither Tools getting Avisynth+ for the very first time.
You won't ever feel the need to go back to the normal Avisynth, I can tell you that, you'll love AVS+ ;)

And he will port fmtconv to avs
https://forum.doom9.org/showthread.php?p=1948178#post1948178

[FranceBB]

And he will port fmtconv to avs
https://forum.doom9.org/showthread.php?p=1948178#post1948178

Nice! :D

[qyot27]

I’m just installing AVS+ for the first time and suddenly I feel like a total neebie… So I have a question I cannot find the answer on the official website nor on the wiki:

What are the host applications compatible with 64-bit AVS+ ? For:
– Editing and previewing
– Piping
– Encoding

Also, maybe the installer should be a bit more clear that you can also keep intact your existing 32-bit AviSynth 2.5 just by unchecking the 32-bit dll. I needed to keep my 32-bit AVS 2.6 because I found incompatibilities with my existing plug-in set and the 32-bit AVS+.
FFmpeg and mpv as well, so long as FFmpeg was configured with --enable-avisynth (which itself checks for the presence of AviSynth+'s headers in the system includes).

On all the other OSes* and CPU arches** AviSynth+ can now be used on natively, FFmpeg (and thus anything built against it, like mpv or VLC or kdenlive) and DJATOM's fork of avs2yuv are the direct points of contact.

*Linux, macOS, and BSD (since 3.5.0), Haiku (3.7.0)
**ARM (3.6.0), PowerPC (3.7.0), RISC-V and SPARC (git)

[StainlessS]

– Editing and previewing
Gispos did lots of work on AvsPMod:- https://forum.doom9.org/showthread.php?t=175823
And the old dead VirtualDub is reborn, VirtualDub2:- https://forum.doom9.org/showthread.php?t=172021
[VD2 not seem an update since about beginnning of pandemic, but its great and has AVS script editor, similar to old VDubMod].

[GAP]

Can you have AVISynth and AVISynth + on the same computer? It seems like you can only have one or other but some programs such as AVSMod can only use AVISynth vanilla.

[real.finder]

Can you have AVISynth and AVISynth + on the same computer? It seems like you can only have one or other but some programs such as AVSMod can only use AVISynth vanilla.

you mean avspmod? it work with avs+, seems you use outdated one

anyway, you can have AVISynth and AVISynth+ on the same computer by temporarily switch the dll of AVISynth or AVISynth+ with MPP, avspmod can do it too, and some programs/tools can use the AVISynth.dll that in same folder with it

[GAP]

So when I install AVISynth + and it asks me to override AVISynth files, I just select that option?

[LigH]

Yes, the core DLL(s) need to be in the system folder to be registered systemwide, and additional files get in their carefully planned locations. Switching is easy, using the Universal Avisynth Installer (https://forum.doom9.org/showthread.php?t=172124) by Groucho2004. But when you intend to just be and stay up-to-date, just run the official installer once and agree.

[cretindesalpes]

I have another question about the plane (or channel) identification, from a user point of view. In RGB, the channels are numbered in the B-G-R-(A) order. If I want to let a user specify a plane index (as a number) in a filter parameter, should I follow the internal Avisynth convention? Or the more common R-G-B-(A) order? What other plug-ins are doing regarding this topic?

I see that some old Avisynth plug-ins have been ported to support planar RGB in addition to YUV. These plug-ins often have “y”, “u” and “v” parameters. Are these parameters implicitly used for RGB planes too? If yes, what is the mapping convention?

[real.finder]

I have another question about the plane (or channel) identification, from a user point of view. In RGB, the channels are numbered in the B-G-R-(A) order. If I want to let a user specify a plane index (as a number) in a filter parameter, should I follow the internal Avisynth convention? Or the more common R-G-B-(A) order? What other plug-ins are doing regarding this topic?

I see that some old Avisynth plug-ins have been ported to support planar RGB in addition to YUV. These plug-ins often have “y”, “u” and “v” parameters. Are these parameters implicitly used for RGB planes too? If yes, what is the mapping convention?

in masktools
https://i.postimg.cc/j251vC8k/Untitled.png (https://postimages.org/)

others just ignore “y”, “u” and “v” parameters for RGB, but in any case nothing can stop you from use arrays for planes just like vs plugins does but this mean it will not work in old avs+ and avs 2.6 just like vsLGhost (vsLGhost still use “y”, “u” and “v” parameters though but use arrays for mode, shift, and intensity)

[Reel.Deel]

I have another question about the plane (or channel) identification, from a user point of view. In RGB, the channels are numbered in the B-G-R-(A) order. If I want to let a user specify a plane index (as a number) in a filter parameter, should I follow the internal Avisynth convention? Or the more common R-G-B-(A) order? What other plug-ins are doing regarding this topic?

I see that some old Avisynth plug-ins have been ported to support planar RGB in addition to YUV. These plug-ins often have “y”, “u” and “v” parameters. Are these parameters implicitly used for RGB planes too? If yes, what is the mapping convention?

From a users point of view I think it makes more sense using RGB(A).

MaskTool2 follows the YUVA-->RGBA mapping, also Expr maps the expressions to YUVA/RGBA. As real.finder said, most of the plugins that have been ported from VS always process RGB with no way to override it. Don't know if this would work but it would be nice if said plugins had a "planes" parameter at the very end that accepts an array just like VS, and when defined overrides the Y-U-V parameters for any colorspace.

[cretindesalpes]

Thanks for your answers. I’m kinda reluctant to use the array solution for compatibility reasons, so I think I’ll use a string instead. "all" processes all planes, "" nothing, and any combination containing '0', '1', '2', '3', 'y', 'u', 'v', 'r', 'g', 'b', 'a' selects the right planes, with the 'r', 'g', 'b' values being equivalent to 'y', 'u', 'v'.

[cretindesalpes]

I couldn’t find any clear specification about the floating point ranges in Avs+. It would be great if the Avisynth+ color format page (http://avisynth.nl/index.php/Avisynthplus_color_formats) could indicate this information. In a few locations it is implied that the f. p. range is “full-scale”, so I understand that black is 0.f and 100 % white is 1.f. Also, I’m not sure if the chroma center is 0.f or 0.5f (found some tests for a FLOAT_CHROMA_IS_HALF_CENTERED macro in the source code).

However:

– I’m not sure it is a documentation issue or a bug, but it seems that ColorBarsHD generates levels that are not “full-range” in floating point (pixel_type="YUV444PS"): pure black is 16/255 (not 0) and 100 % white is 235/255 (not 1). Is this the expected behaviour? The scale factor is defined here (https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/source.cpp#L851) in the source code.

– In the ConvertBits (http://avisynth.nl/index.php/ConvertBits) documentation, it is specified that “Conversion from and to float is always full-scale”. However the floating point scale seems to depends on the fulls argument, so the aforementioned ColorBarsHD is correctly converted to PC.709 (full scale) by setting fulls=false, fulld=true. Again, is this a documentation imprecision or a bug?

– In the Levels (http://avisynth.nl/index.php/Levels) documentation, there is a table giving the equivalence between values for different bitdepth, and the f. p. values have a denominator of 256. This is a slightly different convention as the 255 used in ColorBarsHD.

So, is Avs+ floating point data subject to the TV/PC range madness too? And if yes, what are the exact conversion conventions?

[DTL]

"ColorBarsHD generates levels that are not “full-range” in floating point (pixel_type="YUV444PS"): pure black is 16/255 (not 0) and 100 % white is 235/255 (not 1). Is this the expected behaviour?"

It may be a general idea for better-precision coding of moving pictures digital levels:
The base range of nominal black and white is 16 and 235. And any additional bits only increases precision without moving the range. Like 10bit only allow to encode 16.25, and float 32bit allow to encode 16.12345 (about 7 decimal digits of precision).
With integer formats it was useful for converting from >8 bits to 8 bits with just skipping lower bits.
So may be with addition of single-pres float we just have only better precision of coding natural 16..235 range. Also it makes easy the conversion between different precisions with just convert float to int and back without additional scaling and shifting and it increases processing speed.

[jpsdr]

I've never seen in avisynth filters whith lookhead (that doesn't mean they don't exist). I know in VDub when you are processing frame n, how to access previous and next frames (n-1,n-2,...,n+1,n+2,...), provided by the API (without having to do it yourself with your own internal buffers) (you must have a recent VDub version using the last API), but i don't know how to do this in avisynth, even if it's possible (i mean directly with API, not doing it yourself with your own buffer).

[cretindesalpes]

DTL:

I can’t see any clear advantage for the user in transferring the full/limited range standards to floating point data, instead of keeping a consistent 0 = nominal black, 1 = nominal white. However the center of the chroma signals (0 or 0.5) is a bit more debatable.

The efficiency argument is mostly insignificant: bitdepth conversions should be only a tiny part of the whole processing calculations, especially if you go the floating point way (complex calculations requiring great accuracy or extended ranges, use of hardware shaders, etc.) There is no “fast bit shift” for floating point conversions, you always have to multiply. Setting a fixed range may introduce an extra addition, which is very light compared to actual processing functions like non-linear operations, multi-dimension table look-up, etc. And given that some common operations expect the black to be 0, other processing devices may have to rescale data back and forth if in/out black is not 0.

The only advantage is for the designers and coders of bitdepth conversion programs. It simplifies their operations, they don’t have to think about it when converting between float and int.

We have both full and limited range in the integer world. Digital consumer medias and broadcasts have generally limited signals, whereas most video cameras output full-range signals. Limited range for bitdepths > 8 bits is specified for a long time by international standards, and they make sense. Anyway we have to live with both ranges, and this is a PITA for low-level video processing users as well as plug-in developers, because we have to care about it for most operations.

At least with floating point data we have the opportunity to use a unique range, because the f. p. format holds plenty of headroom making the “limited” range meaningless. This is better for both users and plug-in developers. Vapoursynth made this choice and this is much easier for everybody with no drawback on the performance side. It’s like in the audio world: in floating point, 0 dBFS is almost universally set to ±1.0 in a processing graph. Nobody would use another reference, even if some storage formats may use a different convention for historical reasons.

However, my point was not about changing the choice made by the Avisynth+ team regarding floating point ranges. I just pointed out some discrepancies and wanted to get a clear description about the chosen data format convention.

[DTL]

If you set nominal 'video' to 0.0 and 1.0 it mean you still need to process and keep now negative -0.xx undershoots and over 1.0 overshoots.

I think the most prof video was with having footroom and headroom 'limited' coding and the only new and possibly degrading thing is PQ-full HDR that may be not have footroom and headroom and it will increase processing distortions but giving a bit more bits for HDR levels encoding.

The only exact physically defined display level is 'black' and 'white' is completely picked by system designer as it want. And for processing we still need to have footroom below black and over white (with both max super-white legal level + processing overshoots over max system super-white) so we need as much as possible headroom over nominal system white level. So I think no any reason to put black and white to 'nice' numbers like 0 and 1.

Working with about -0.1..1.x range may cause more precision lost because of walking around zero (very small values of positive and negative floats): There is a warning about using close to denornals in float32: https://stackoverflow.com/questions/9044555/for-float-and-double-why-it-is-asymmetric-for-the-negative-and-positive-numbers
"The range on the bottom end is further extended by allowing a floating value to be denormal. The smallest possible non-zero float has a 1 in the least significant bit of the mantissa.
You never actually want to get close to denormals, they lose significant digits in a hurry. They really only help to avert division-by-zero problems, at a price."
Also about denornals around zero in floats: https://en.wikipedia.org/wiki/Denormal_number

"We have both full and limited range in the integer world."

There are 2 digital picture worlds - of static and moving pictures. For static pictures typically full range is used. For moving pictures - limited. Unfortunatelly most of Avisynth's design from old times do not cleary shows it and still have lots of defects for processing moving pictures data.

The word 'limited' is not very nice - it may be better for the great olds to use word 'nonresticted' range. It better displays the requirements for coding method to have at least some footroom and headroom for coded values above and below nominals.

"most video cameras output full-range signals. "

Normal video camera for moving pictures must feed RGB in limited range also. See for example HDTV https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-6-201506-I!!PDF-E.pdf - 4 Digital representation
4.1 Coded signal R, G, B or Y, CB, CR
4.6 Quantization levels - both RGB and Y black levels are of 16 for 8bit and 64 (16.00) for 10bit limited range.

[real.finder]

I couldn’t find any clear specification about the floating point ranges in Avs+. It would be great if the Avisynth+ color format page (http://avisynth.nl/index.php/Avisynthplus_color_formats) could indicate this information. In a few locations it is implied that the f. p. range is “full-scale”, so I understand that black is 0.f and 100 % white is 1.f. Also, I’m not sure if the chroma center is 0.f or 0.5f (found some tests for a FLOAT_CHROMA_IS_HALF_CENTERED macro in the source code).


floating point ranges in Avs+ is same as vs now, 0..1.0 for luma and -0.5..0.5 (zero centered) for chroma (and of course both can have out of range Values)


However:

– I’m not sure it is a documentation issue or a bug, but it seems that ColorBarsHD generates levels that are not “full-range” in floating point (pixel_type="YUV444PS"): pure black is 16/255 (not 0) and 100 % white is 235/255 (not 1). Is this the expected behaviour? The scale factor is defined here (https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/source.cpp#L851) in the source code.

– In the ConvertBits (http://avisynth.nl/index.php/ConvertBits) documentation, it is specified that “Conversion from and to float is always full-scale”. However the floating point scale seems to depends on the fulls argument, so the aforementioned ColorBarsHD is correctly converted to PC.709 (full scale) by setting fulls=false, fulld=true. Again, is this a documentation imprecision or a bug?

– In the Levels (http://avisynth.nl/index.php/Levels) documentation, there is a table giving the equivalence between values for different bitdepth, and the f. p. values have a denominator of 256. This is a slightly different convention as the 255 used in ColorBarsHD.

So, is Avs+ floating point data subject to the TV/PC range madness too? And if yes, what are the exact conversion conventions?

start read from https://forum.doom9.org/showthread.php?p=1926780#post1926780