AviSynth+ thread Vol.2

[Dogway]

Huge changelog. Thanks a lot!

EDIT: cretindesalpes also suggests Sierra dithering for encoding, I guess these 2 are worthy of being ported

[pinterf]

Today's news:
Avisynth+ 3.7.1 test build 27 (20211117) (https://drive.google.com/uc?export=download&id=1tyZCCC96arWeXaZ0EKMSiKkS6My9LxRR)

- Expr: atan2 to SSE2 and AVX2. Up to 20x speed.
See notes in readme

[pinterf]

@pinterf
This is an "old" version, two updates has been made since.
Last is : https://www.itu.int/pub/R-REP-BT.2380-2-2018

You can read the PDF i've made with my HDRTools, i've tried to explain some things. I don't know if i've succed...

Thanks for the materials. For the first sight: I'm glad that all this happens in a 3rd party plugin by you :)

[Dogway]

Thanks, you are turning my functions into legacy ^^
Is 'sign' operator possible? I see many cases of where the only alternative is to use ternaries " 1 -1 ? " or division "A B /" to get the sign, both are slow.

EDIT: Also noticed that ColorYUV(levels="TV->PC") doesn't write to frameprops. I don't use it but many users do.

[hello_hello]

pinterf,
Just a minor thing, out of curiosity....
Is there a reason why zero is never displayed as a negative number by the subtitle function when it's an integer, but it can for float? I don't think Avisynth 2.6 did that.

Subtitle(string(-0)) # displays zero
SubTitle(string(float(-0))) # displays zero
Subtitle(string(-0.0)) # displays minus zero
Subtitle(string(-float(0))) # displays minus zero

[Dogway]

Another issue (probably) with new scriptclip and frameproperties.
This works:
ScriptClip( """
st = propGetAsArray("_MinMax")
subtitle(string(st[0])) """ )
But this doesn't
ScriptClip( function [] () {
st = propGetAsArray("_MinMax")
subtitle(string(st[0])) } )

[StainlessS]

HH,
There is no such thing as -ve zero for int, leastwise not on x86 using Two's Complement arithmetic, [Two's Complement]:- https://en.wikipedia.org/wiki/Two%27s_complement ]
Some machines [sometimes older mainframes], might use Ones Complement, which does have -ve zero.
Some machines [sometimes mainframes] may use Sign and Magnitude, where a sign bit denotes sign, and remainder of bits the magnitude, these can have -ve zero.
[Signed number representations]:- https://en.wikipedia.org/wiki/Signed_number_representations

IEEE 754 floats use a sign bit, and so can also represent -ve zero. [IEEE754]:- https://en.wikipedia.org/wiki/IEEE_754

EDIT: From long time ago [2011]
I came upon this snippet, in the v2.6 header.

#if 0
#define MAX_INT 0x7fffffff
#define MIN_INT -0x7fffffff // ::FIXME:: research why this is not 0x80000000
#endif

This seems to go back some time and possibly written by Ben Rudiak-Gould, himself.
(EDIT: apart from the ::FIXME:: )


Signed Int System Equivalent meaning Result of
under system -0x7FFF,FFFF
of 0x8000,0000

Twos Complement (-MAX_INT) - 1 0x8000,0001 ie -MAX_INT

Ones Complement -MAX_INT 0x8000,0000 ie -MAX_INT

Sign & Magnitude -0 0xFFFF,FFFF ie -MAX_INT


The above "#define MIN_INT -0x7fffffff" is portable across all three positional [EDIT: See above in BLUE]
number systems regarding signed integers whereas the 0x8000,0000 one is not.

It is only when "Sign & Magnitude" is considered that the reasoning becomes evident.

EDIT: Under Twos Complement, 0x8000,0000 is troublesome anyway with
-(0x80000000) == 0x80000000

Above, eg 0x8000,0000 is intended to be read as 0x80000000 : intended to make it easier to read.

EDIT: MAX_INT and MIN_INT were present in AVISYNTH_VERSION 3 header [v2.58] and earlier versions of v2.60 header,
but removed from final v2.60 header [AVISYNTH_VERSION 5], not that long after above quoted post. [although IanB made no comment on the post]

[hello_hello]

StainlessS,
Thanks for the info. I get the gist of it, at least.
Maybe something's different for Avisynth+ in respect to the way the string function converts negative zero to a string, because I checked Avisynth 2.6 to see if I was remembering correctly, and both of these display as zero.

Subtitle(string(-0.0))
Subtitle(string(-float(0)))

It's just a little thing but it puzzled me for a function that does the math with positive numbers but ultimately displays them as negative (right and bottom resizer cropping, for example). So to prevent negative zero....

A = 1.0 - 1.0
A = (A == 0) ? 0 : A
Subtitle(string(-A))

Although as it turns out, both Avisynth 2.6 and Avisynth+ round negative numbers to negative zero, or it's the string function rounding that way. This displays as negative zero, even though there's no decimal places.

Subtitle(string(-0.00001, "%.0f"))

So for either version preventing the subtitle function displaying negative zero involved something like...

A = 1.0000001 - 1.0
A = (A <= 0.0005) ? 0 : A
Subtitle(string(-A), "%.3f")

[pinterf]

Another issue (probably) with new scriptclip and frameproperties.
This works:
ScriptClip( """
st = propGetAsArray("_MinMax")
subtitle(string(st[0])) """ )
But this doesn't
ScriptClip( function [] () {
st = propGetAsArray("_MinMax")
subtitle(string(st[0])) } )

This one works for me.
propSet("_MinMax",[12,32])
ScriptClip( function [] () {
st = propGetAsArray("_MinMax")
subtitle(string(st[0])) } )

[pinterf]

Thanks, you are turning my functions into legacy ^^
Is 'sign' operator possible? I see many cases of where the only alternative is to use ternaries " 1 -1 ? " or division "A B /" to get the sign, both are slow.

EDIT: Also noticed that ColorYUV(levels="TV->PC") doesn't write to frameprops. I don't use it but many users do.
"sgn" as 1, 0, -1 is done.

ColorYUV: under construction.
Obviously, this filter with its existing parameter values cannot use input frame properties. Explicite "PC->TV" and "TV->PC" will override any input properties. But setting the output range is O.K.

[Dogway]

Sorry, it must be then a specific issue with ShowChannels. Back compatibility might be broken.
ShowChannels(SetVar=True,show=false)
# global SC_LMn_0 = 2
ScriptClip( function [] () {
subtitle(string(SC_LMn_0)) } )


EDIT: a random question, should masks (scalar by nature) should be in fullscale bitdepth values (ie. 0-65535), or it depends on the bitdepth scale it's going to be used for?

EDIT2: And I know this is not going to be very popular, but I really miss comments in expression blocks, for example ignore everything after # until end-of-line or better #this_is_is_a_comment. So I can add some notes in complex ones like medians, adaptive_sharpen, etc.

[LigH]

Is there a reason why zero is never displayed as a negative number by the subtitle function when it's an integer, but it can for float?

Yes, it's caused by the binary representation of the numbers.

Integer numbers are discrete positions in a range. There is only exactly one number with the value zero in an integer type of a specific resolution = value range. Because there is already one zero, there cannot be another "negative zero".

Wikipedia: Two's complement (https://en.wikipedia.org/wiki/Two%27s_complement)

IEEE 754 Float numbers have a different representation. They store a mantissa (fraction) and an exponent (scaling factor). And they have an explicit sign bit. This makes it possible to store both a positive and a negative number zero.

Even worse, some numbers do not even have a unique representation: If the mantissa equals zero, the exponent does not matter, it could be any, but the whole number still means zero.

Wikipedia: Signed zero (https://en.wikipedia.org/wiki/Signed_zero)

[wonkey_monkey]

Even worse, some numbers do not even have a unique representation: If the mantissa equals zero, the exponent does not matter, it could be any, but the whole number still means zero.



The mantissa has an implicit leading "1" (unless it's a denormal number) so that is not the case.

[pinterf]

Sorry, it must be then a specific issue with ShowChannels. Back compatibility might be broken.
ShowChannels(SetVar=True,show=false)
# global SC_LMn_0 = 2
ScriptClip( function [] () {
subtitle(string(SC_LMn_0)) } )

Sorry, what is ShowChannels?

But without knowing that, variable visibility - especially writing global variables - is very strict inside a function which is inside a ScriptClip.
See:
http://avisynth.nl/index.php/ConditionalFilter#ScriptClip
Avisynth+ specialities: parameter 'local'



EDIT: a random question, should masks (scalar by nature) should be in fullscale bitdepth values (ie. 0-65535), or it depends on the bitdepth scale it's going to be used for?


Maximum mask value is (2^N)-1 for integer bit depths and 1.0 for float. 255, 1023, 4095, 16383, 65535


EDIT2: And I know this is not going to be very popular, but I really miss comments in expression blocks, for example ignore everything after # until end-of-line or better #this_is_is_a_comment. So I can add some notes in complex ones like medians, adaptive_sharpen, etc.
Considering.

[StainlessS]

ShowChannels:- https://forum.doom9.org/showthread.php?t=163829

EDIT:


void __stdcall ShowChannels::CallSetVar(bool init,int n,int chan,AVSValue avs,IScriptEnvironment* env) {
// Create/Update Global variable
const char*p,*nam[]={"Ave","Min","Max","LMn","LMx","AAve","AMin","AMax","ALMn","ALMx","Visited"};
char bf[256],*d;
for(d=bf,p=Prefix;*d++=*p++;); // strcpy Prefix eg "SC_"
--d; // back up 1, to point at nul term
for(p=nam[n];*d++=*p++;); // strcat variable name part
if(chan >= 0) { // if NOT "Visited" variable
d[-1]='_'; // append channel suffix eg "_0".
*d++ = chan + '0';
*d='\0'; // nul term again
}
if(init) { // In constructor ONLY , use SaveString
env->SetGlobalVar(env->SaveString(bf), avs);
} else { // SaveString not needed as already exists (Created by Constructor)
env->SetGlobalVar(bf, avs);
}
}

[Dogway]

Thanks for the notes. I read that a few days before but didn't quite grasp it. So I have to assume that ShowChannels() is one of those plugins written in the assumption that local=false, hence it doesn't work in new scriptclip with either local=false or true.
I see a mention on UseVar(), but didn't find an example, it might be useful in this case(?).

About masks, here an example:
convertbits(16, fulls=true, fulld=false)
mt_binarize(60) # output 65535
scriptclip("subtitle(string(YPlaneMax),x=30,y=10)")

So here's the situation:
convertbits(16, fulls=true, fulld=false)
a=last
msk=mt_binarize(60)
# ( (0~65280)/65535 * (0|65535)/65535 ) * 65280
expr(a, msk, "x range_max / y range_max / * range_max *","")

If clip source is white 60160, for the white part (pass) of the mask we get:
((60160/65535) * (65535/65535) ) * 65535 = 60160

If the mask has the same bitdepth scale than source:
((60160/65535) * (60160/65535) ) * 65535 = 55225.84

Is this ok (one or the other)?

In my tools I map range_max to bitdepth scale including masks, so this is the situation:
((60160/65280) * (65280/65280) ) * 65280 = 60160

Is this wrong?


On another note I found myself testing 32-bit filtering and getting some warning messages, because I always revert back to input bitdepth (using dithering) when filtering in a higher bitdepth. But now this occurs (not a fan of warning messages):


convertbits(32)
blah()

function blah(clip a) {
a.convertbits(32)
# Required 32-bit filtering
convertbits(BitsPerComponent(a), dither=1)}

[pinterf]

meanwhile
Avisynth+ 3.7.1 test build 28 (20211124) (https://drive.google.com/uc?export=download&id=1Syz8js7R3_8376WAyYKzmwKP40gu3wHy)
Changes since test27
20211124 WIP
------------
- Language syntax: accept arrays in the place of "val" script function parameter type regardless of being named or unnamed.
(Note: "val" is "." in internal function signatures)
Example:
BlankClip(pixel_type="yv12")
r([1, 2, 3])
r(n=[10,11,[12,13]])
r("hello")
function r(clip c, val "n")
{
if (IsArray(n)) {
if (IsArray(n[2])) {
return Subtitle(c, String(n[2,1]), align=8) #13 at the top
} else {
return Subtitle(c, String(n[2]), align=2) #3 at the bottom
}
} else {
return Subtitle(c, String(n), align=5) #hello in the center
}
}

- Histogram "Levels": more precise drawing when bit depth is different from histogram's resolution bit depth
- Expr: no more banker's rounding when converting back float result to integer pixels. Using the usual truncate(x+0.5) rounding method
- ColorYUV: fix 32 bit float output
- ColorYUV: More consistent and accurate output across different color spaces, match with ConvertBits fulls-fulld conversions
- ColorYUV: set _ColorRange frame property
levels = "TV->PC" -> full
levels = "PC->TV" or "PC->TV.Y" or "TV" -> limited
levels = (not given) and _ColorRange property exists -> keeps _ColorRange
levels = (not given) and no _ColorRange property -> full range (old default behaviour)
- ColorYUV: when no hint is given by parameter "levels" then use _ColorRange (limited/full) frame property for establishing source range
If _ColorRange does not exist, it treats input as full range (old default behaviour)
Why: when there is no limited<->full conversion, but gamma is provided then this info is still used in gamma calculation.
- ColorYUV: fixes for showyuv=true:
- fix display when bits=32
- "showyuv_fullrange"=true case: U and V range is chroma center +/- span (1..max) for integer bit depths instead of 0..max
Shown ranges:
For bits=8: 128 +/- 127 (range 1..255 is shown) (UV size is 255x255 -> 510x510 image YV12)
bits=10: range 512 +/- 511 (UV size is 1023x1023 -> 2046x2046 image YUV420P10)
bits=12: range 2048 +/- 2047 (UV size is same as 10 bits 1023x1023 -> 2046x2046 image YUV420P12)
bits=14: range 8192 +/- 8191 (UV size is same as 10 bits 1023x1023 -> 2046x2046 image YUV420P14)
bits=16: range 32768 +/- 32767 (UV size is same as 10 bits 1023x1023 -> 2046x2046 image YUV420P16)
bits=32: range 0.0 +/- 0.5 (UV size is same as 10 bits 1023x1023 -> 2046x2046 image YUV420PS)
In general: chroma center is 2^(N-1); span is (2^(N-1))-1 where N is the bit depth
- propShow: display _Matrix, _ColorRange and _ChromaLocation constants with friendly names
- Info on Wincows XP compatibility (Microsoft side)
Avisynth+ can be build to be XP compatible (VS2019): v141_xp toolset and -Z-threadSafeInit flag.
But in order to work, a _compatible_ (=not latest) Visual C++ runtime is still needed (XP support has been stopped by MS meanwhile)
As experienced here: https://github.com/AviSynth/AviSynthPlus/issues/241
The latest XP compatible version is probably 14.28.29213.0.
Links to official installers for last XP compatible Microsoft Visual C++ 2015-2019 Redistributable (version 14.28.29213):
x64 - https://download.visualstudio.microsoft.com/download/pr/566435ac-4e1c-434b-b93f-aecc71e8cffc/B75590149FA14B37997C35724BC93776F67E08BFF9BD5A69FACBF41B3846D084/VC_redist.x64.exe
x86 - https://download.visualstudio.microsoft.com/download/pr/566435ac-4e1c-434b-b93f-aecc71e8cffc/0D59EC7FDBF05DE813736BF875CEA5C894FFF4769F60E32E87BD48406BBF0A3A/VC_redist.x86.exe

- Expr: new function "sgn". Returns -1 when x is negative; 0 if zero; 1 when x is positive

[pinterf]

Thanks for the notes. I read that a few days before but didn't quite grasp it. So I have to assume that ShowChannels() is one of those plugins written in the assumption that local=false, hence it doesn't work in new scriptclip with either local=false or true.

There was no change in behaviour in ScriptClip called with string parameter. Theoretically when ScriptClip is called with the function-syntax then local=false would help, I think it can even write back global variables with global varname = value syntax. (But varname = value may not work, don't know)

[pinterf]

If clip source is white 65280, for the white part (pass) of the mask we get:
((65280/65535) * (65535/65535) ) * 65280 = 65025.99

I see. The problem is that 65280 (255 << 8) is not a standard white in either 16 bit logic. Too big to be a limited range value. If it were full-range then it must be 65535.

edit: with the new 'sgn' you can convert 0..max-1 mask values into 0.0 and 1.0 and use it for multiplication

[Dogway]

Sorry, I borked at many places with my examples. I will give it a though and edit it.

EDIT: ok, 65280 is a defect, it shouldn't exist at first place or fix prior to anything.

[pinterf]

ShowChannels:- https://forum.doom9.org/showthread.php?t=163829

Thanks, downloaded, I'm gonna give it a try.

[FranceBB]

Thanks Ferenc! Keep them coming! :D

About XP, you should both (you and qyot) be aware already that the C++ Redistributable shipped with the installer were not XP Compatible 'cause I raised the "issue" several months ago, saying that reverting to the old C++ Redistributable worked.
I'm gonna quote myself 'cause it's always funny ehehehe
Cherry picked from this very same thread, posted on 5th February 2021:

Hi Ferenc,
I have just a thing to report.

The AviSynth+ 3.7.0 release installer for Windows XP has been shipped with the "wrong" version of C++ Redistributable.
Let me explain.

There are:

- AviSynthPlus_3.7.0_20210111_vcredist_xp.exe
- AviSynthPlus_3.7.0_20210111_xp.exe

Both builds work just fine on Windows XP and they've been compiled to run on XP targeting v141_xp correctly, so no problem, however the "_vcredist_xp.exe" version isn't shipping the XP compatible Microsoft C++ Redistributable 2015-2019 installer, so what will happen is that the C++ Redistributable that is gonna be installed won't work on XP, hence it will make impossible to use Avisynth.
In order to make it work, I've installed the "vcredist" version shipped with AviSynth+ 3.6.1 and then I installed "AviSynthPlus_3.7.0_20210111_xp.exe" without re-installing the C++ Redist and it worked like a charm.
I think you should be shipping the vcredist version from AVS 3.6.1 for XP ;)

And Stephen said:

Then Microsoft changed the vcredist silently, because it was the standard 2015-2019 vcredist download link.

to which I replied:

Yep...
I just checked and it seems that VC++ 2019 version 14.28.29213.0 (August 2020) is the last version compatible with Windows XP... :( C++ Redistributable AIO (XP Compatible) (https://github.com/abbodi1406/vcredist/releases/download/v0.35.0/VisualCppRedist_AIO_x86_x64_35.zip)
I've just archived it... For future XP releases, we should always include that one I think.


So... when you're gonna release 3.7.1 stable, you know what to do :P

[pinterf]

Thanks Ferenc! Keep them coming! :D

About XP, you should both (you and qyot) be aware already that the C++ Redistributable shipped with the installer were not XP Compatible 'cause I raised the "issue" several months ago, saying that reverting to the old C++ Redistributable worked.


I know exactly what I'd like to do with XP support but I won't do that at the moment. :)

As written in the changelog:
- Info on Windows XP compatibility (Microsoft side)
Avisynth+ can be build to be XP compatible (VS2019): v141_xp toolset and -Z-threadSafeInit flag.
But in order to work, a _compatible_ (=not latest) Visual C++ runtime is still needed (XP support has been stopped by MS meanwhile)
As experienced here: https://github.com/AviSynth/AviSynthPlus/issues/241
The latest XP compatible version is probably 14.28.29213.0.
Links to official installers for last XP compatible Microsoft Visual C++ 2015-2019 Redistributable (version 14.28.29213):
x64 - https://download.visualstudio.microsoft.com/download/pr/566435ac-4e1c-434b-b93f-aecc71e8cffc/B75590149FA14B37997C35724BC93776F67E08BFF9BD5A69FACBF41B3846D084/VC_redist.x64.exe
x86 - https://download.visualstudio.microsoft.com/download/pr/566435ac-4e1c-434b-b93f-aecc71e8cffc/0D59EC7FDBF05DE813736BF875CEA5C894FFF4769F60E32E87BD48406BBF0A3A/VC_redist.x86.exe

[pinterf]

(I was just playing some hours with an interesting mod - proof of concept -, namely 64 bit double and int64 support. Of course this works only on x64. But hey, I've just displayed 7FFFFFFFFFFFFFFF in hex after getting sqrt(2) in double :))

[FranceBB]

I know exactly what I'd like to do with XP support

:scared:


but I won't do that :)


I'm sure manolito, hello_hello, Katie and others are gonna thank you for this eheheheh

[manolito]

I'm sure manolito, hello_hello, Katie and others are gonna thank you for this eheheheh

You can drop me from this list now... :scared:
About 6 months ago I woke up one morning after having an overnight stroke without even waking up. Life goes on, but I am no longer the smart person I used to be. I cannot even decipher code I wrote myself right before this stroke.

I still try to read the forum threads I used to be interested in, but it is a bit frustrating. As far as computers are concerned, I am happy that I can manage my emails and my bank account.

So I would like to thank all the folks from this forum, I had a great time here as long as it lasted.

Take care and Cheers
manolito

[kedautinh12]

Bye manolito, see you again in future :D

[ryrynz]

You can drop me from this list now... :scared:


I'm sure you'd still like XP support to die lol.

Life is too short to focus on what was, I hope you can enjoy those things you can do with as much time as you have left. A pleasure having you around and all the best to you.

[VoodooFX]

About 6 months ago I woke up one morning after having an overnight stroke without even waking up. Life goes on, but I am no longer the smart person I used to be. I cannot even decipher code I wrote myself right before this stroke.

Ooh, scary stuff, sad to hear... I hope you'll get better. :scared:

[pinterf]

Hey manolito, sad things happened to you, get better. Avisynth x86 test versions are still compiled with SSE requirement only, traditionally, just because of you.

[tormento]

About 6 months ago I woke up one morning after having an overnight stroke without even waking up.
I have a rare genetic mutation (EDS syndrome) that gives me sometimes excruciating pain and the risk of a sudden death every single day.

Unfortunately the doctors discovered it when I was 45 already, with all that goes with it. No treatment possible, at least for the next decade or so.

I toss the coin every morning and every day is a new day of a new life.

I can't work anymore (and welfare is not helping me at all) but I go to swimming pool, diving (when I have enough money) and I do try my best.

My best wishes for your "new" everyday life.

[FranceBB]

About 6 months ago I woke up one morning after having an overnight stroke without even waking up. Life goes on, but I am no longer the smart person I used to be. I cannot even decipher code I wrote myself right before this stroke.

I still try to read the forum threads I used to be interested in, but it is a bit frustrating. As far as computers are concerned, I am happy that I can manage my emails and my bank account.

So I would like to thank all the folks from this forum, I had a great time here as long as it lasted.

Take care and Cheers
manolito

I'm really sorry to hear that. :(
Take care and try to rest a bit and not think about this.
That must have been scary...
Anyway, your words are always gonna stay here in this forum and I've had a good time with you and the others too.
I consider Doom9 as a sort of family which just shows how people can be respectful and cooperative. :)
I hope you're gonna recover and get back to be active again here one day, but in any case, it's been a pleasure having you around. :)


I have a rare genetic mutation (EDS syndrome) that gives me sometimes excruciating pain and the risk of a sudden death every single day.

Unfortunately the doctors discovered it when I was 45 already, with all that goes with it. No treatment possible, at least for the next decade or so.

I toss the coin every morning and every day is a new day of a new life.

Yet the fact that you wake up every morning and that you also find time to post here, test scripts, deal with new stuff etc just shows how much you care about encoding. :') I mean, other people in your situation would have just dropped everything... If we won't hear back from you one day, we'll know what happened... :(

[tormento]

If we won't hear back from you one day, we'll know what happened... :(
[emoji1591] (sorry, I think Italians only can understand).

I prefer to think that those days when you don’t hear me, it’s because I am at the sea.

[kedautinh12]

So sad for you two

[Gavino]

Best wishes, manolito!

Coraggio, tormento!

[FranceBB]

[emoji1591] (sorry, I think Italians only can understand).


hahahahaha "le corna" / "tocca ferro" is impossible to translate ehehehe I guess the closest thing we can say to translate it would be something like 'touch wood' :P


I prefer to think that those days when you don’t hear me, it’s because I am at the sea.

yeah enjoying the sun and the sea, but hopefully not in France this time so you won't have to remember *that person* eheheheh

[VoodooFX]

hahahahaha "le corna" / "tocca ferro" is impossible to translate ehehehe I guess the closest thing we can say to translate it would be something like 'touch wood' :P

I know that English is a poor language, but they understand "knocking on wood". :P

[StainlessS]

but they understand "knocking on wood"
Yes they do, and we send best wishes to Mani and Tormento and feel for the pair of you,
you have both made for an indelible presence on the forum and if you choose to spend less time here
you will be sorely missed.

[pinterf]

Avisynth+ 3.7.1 test build 29 (20211126) (https://drive.google.com/uc?export=download&id=1gxEaQDQYoLBiZdFc1HOJKWgh8o7zVLf5)
Plus new sections in http://avisynth.nl/index.php/ConditionalFilter#ScriptClip after experimenting with ScriptClip, functions, local and global variables.
20211126 WIP
------------
- New: ArrayAdd(a, b): appends b to the end of a (a is array, b is a value which can be another array)
Example:
a = []
a=ArrayAdd(a,[1,2]) # [[1,2]]
a=ArrayIns(a,3,0) # [3,[1,2]]
a=ArrayAdd(a,"s1") # [3,[1,2],"s1"]
a=ArrayAdd(a,"s2") # [3,[1,2],"s1","s2"]
a=ArrayDel(a,2) # [3,[1,2],"s2"]
- New: ArrayIns(a, b, n): inserts b into a to position n (a is array, b is a value (but can be another array), n is a zero based index. 0: inserts at the beginning, array_size: inserts after the last element)
- New: ArrayDel(a, n): removes the n-th element from a (a is array, n is a zero based index, must be a valid index between 0 and arraysize-1)
- Enhancement: xPlaneMin/Max/Median/MinMaxDifference runtime functions to accept old packed formats (RGB24/32/48/64 and YUY2)
(By autoconverting them to Planar RGB or YV16)
- New runtime function: PlaneMinMaxStats(clip, float "threshold", int "offset", int "plane", bool "setvar")
Returns an 5-element array with [min,max,thresholded minimum,thresholded maximum,median]
Parameters:
float 'threshold': a percent number between 0.0 and 100.0%
int 'offset': if not 0, they can be used for pulling statistics from a frame number relative to the actual one
int 'plane' (default 0):
0, 1, 2 or 3
for YUV inputs they mean Y=0,U=1,V=2,A=3 planes
for RGB inputs R=0,G=1,B=2 and A=3 planes
bool 'setvar' (default false):
when true then it writes a global variables named
"PlaneStats_min" "PlaneStats_max" "PlaneStats_thmin" "PlaneStats_thmax" "PlaneStats_median"

Note: using global variables are thread safe from ScriptClip only when used with 'function'-syntax call with its default 'local'=true

Example:

# function-syntax ScriptClip + runtime function call + dedicated global var demo
# Here 'local'=true (for the sake of the demo; this is the default for this mode).
# 'local'=true makes a dedicated global variable area, in which 'last' and 'current frame'
# 'c' is a parameter which must be passed to the function. Name is not important, it moves the actual clip into function's scope.
# This is why we can SubTitle on it.
# A function can see only global variables. 'last' and 'current_frame' are available here - they are global variables which were
# set by ScriptClip after creating a safe global variable stack.
# PlaneMinMaxStats writes five global variables "PlaneStats_min", "PlaneStats_max", "PlaneStats_thmin", "PlaneStats_thmax", "PlaneStats_median"
ScriptClip( function [] () {
x=PlaneMinMaxStats(threshold=30, offset=0, plane=1, setvar=true)
subtitle("min=" + string(PlaneStats_min) + " thmax" + String(PlaneStats_thmax) + " median = " + String(PlaneStats_Median) + " median_too=" + String(x[4]))
} , local = true)

[StainlessS]

Note: using global variables are thread safe from ScriptClip only when used with 'function'-syntax call with its default 'local'=true
Does that mean that globals using standard scriptclip are not thread safe in avs + MT ? [or specifically only in 'function'-syntax]

In my plugs setting globs, I usually use a PreFix arg (string), where default prefix might be eg "PlaneStats_", and subnames postfixed to that.
What if you wanna sample frames, previous, current, and next [using offset], and you only got single non prefix option.
[I guess you could sample, and transfer to locals between calls].
Also, if only of use in function'-syntax call, would setting locals be better [some of mine set globals, some locals, has depended on user feedback or plugin request and such].

and thanks for the new one, installing it in a few minutes.

[Dogway]

oooh thanks a lot! Out of dispair I was at the brink of writing a script based, obviously unoptimized, PlaneStats() function. Thanks for the addition.

I plan to add some kind of rolling average to the values, will check tomorrow how to do it but looks tricky.

[goorawin]

Thanks for the continued updates, however one thing I have noticed is that all these test builds (64bit) have been unable to run MP_Pipeline. The following error occurs:
MP_Pipeline: Unable to create slave process. Message: (slave_common.cpp) ReadFile failed,code=109

[pinterf]

There has been an update on mp_pipeline some months ago, do you have the latest one?

[pinterf]

StainlessS: I'm gonna return to it later, it takes more time for me to explain it, what I found is already added to the linked wiki entry.

[goorawin]

There has been an update on mp_pipeline some months ago, do you have the latest one?
Thanks pinterf that did it. I thought I had the lastest, but turns out I didn't

[VoodooFX]

20211126 WIP
- Enhancement: xPlaneMin/Max/Median/MinMaxDifference runtime functions to accept old packed formats (RGB24/32/48/64 and YUY2)
I guess that's after my recent complaint somewhere. You want me to drop v2.6 support. :D

Tested new PlaneMinMaxStats():

ScriptClip( function [] () {
Y=PlaneMinMaxStats(plane=0, setvar=true)
YMinMaxDiff = Y[1] - Y[0]
U=PlaneMinMaxStats(plane=1, setvar=true)
UMinMaxDiff = U[1] - U[0]
V=PlaneMinMaxStats(plane=2, setvar=true)
VMinMaxDiff = V[1] - V[0]
subtitle("Y=" +string(int(YMinMaxDiff)) +" U=" +String(int(UMinMaxDiff)) +" V=" +String(int(VMinMaxDiff)))
} , local = true)

YV12
https://i.imgur.com/Ho43aaO.png

Despite "for RGB inputs R=0,G=0,B=0 and A=3", RGB24 works too:

https://i.imgur.com/M1E1X7a.png


EDIT:
I'm wondering, what is good corresponding chroma plane minmaxdiff value to YPlaneMinMaxDifference value to get the somewhat solid looking frames?
Now I'm using half of Y for some reason, maybe I should use same?

[pinterf]

I guess that's after my recent complaint somewhere. You want me to drop v2.6 support. :D

Not exactly. Some other runtime functions supported them already in the same autoconverting way so I copy pasted those lines.

Tested new PlaneMinMaxStats():

ScriptClip( function [] () {
Y=PlaneMinMaxStats(plane=0, setvar=true)
YMinMaxDiff = Y[1] - Y[0]
U=PlaneMinMaxStats(plane=1, setvar=true)
UMinMaxDiff = U[1] - U[0]
V=PlaneMinMaxStats(plane=2, setvar=true)
VMinMaxDiff = V[1] - V[0]
subtitle("Y=" +string(int(YMinMaxDiff)) +" U=" +String(int(UMinMaxDiff)) +" V=" +String(int(VMinMaxDiff)))
} , local = true)

YV12
https://i.imgur.com/Ho43aaO.png

Despite "for RGB inputs R=0,G=0,B=0 and A=3", RGB24 works too:

https://i.imgur.com/M1E1X7a.png


EDIT:
I'm wondering, what is good corresponding chroma plane minmaxdiff value to YPlaneMinMaxDifference value to get the somewhat solid looking frames?
Now I'm using half of Y for some reason, maybe I should use same?
R=0 G=1 B=2 of course. (and I noticed other typos in the changelog.) If you were able to pass plane=3 for RGB24 then it seems that I do not have proper check for valid plane indexes.

Note: when you do not need global variables, setvar=true is not necessary. You'll get the result array without it.

[Dogway]

@pinterf, now after_frame=true, is not required right?

[Gavino]

now after_frame=true, is not required right?
I suppose you are referring to the example in pinterf's post #1589 above.

I wouldn't expect the behaviour of after_frame to have changed.
In the recent example that required after_frame=true, the call to ShowChannels() was outside the ScriptClip() call (before it).
But in pinterf's example, we have PlaneMinMaxStats() inside ScriptClip's run-time script. The order of events inside the run-time script is not affected by after_frame, which only controls whether the run-time script as a whole is to be evaluated before or after fetching the current input frame.

However... (catch 22), evaluating the run-time script can itself sometimes cause an input frame to be fetched at some point, so the order of events is often not at all obvious!
See here for more hairy details:
Runtime filter evaluation sequence rather more complex than documented

[StainlessS]

Any runtime script that directly samples/force_fetches a frame [YPlaneMin, Averageluma or even PlaneMinMaxStats(), etc], does not need after_frame=true.
[any script code following the sampling will act as if after_frame=true {the sampling will force a fetch of the frame and then sample it, any script code following that acts as if after_frame=true}]

EDIT:

SSS="""
x = 42 # no force fetch of frame for this line of code, processed before frame is fetched.
Return Last # or implicit return of Last, forces fetch of frame from previous filter, (after above script code already executed)
"""
Scriptclip(SSS,after_frame=FALSE)



SSS="""
x = 42 # As After_frame=true, so frame already requested from previous filter even before SSS script is executed.
Return Last
"""
Scriptclip(SSS,after_frame=TRUE)