AviSynth+ thread Vol.2

[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]

Originally Posted by hello_hello

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

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

[wonkey_monkey]

Originally Posted by LigH

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]

Originally Posted by 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)) } )

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/Conditi...ter#ScriptClip
Avisynth+ specialities: parameter 'local'

Originally Posted by Dogway

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

Originally Posted by Dogway

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)
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.micros...redist.x64.exe
  x86 - https://download.visualstudio.micros...redist.x86.exe 

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

[pinterf]

Originally Posted by 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.

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]

Originally Posted by Dogway

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]

Originally Posted by StainlessS

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

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

[FranceBB]

Thanks Ferenc! Keep them coming!

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:

Originally Posted by FranceBB

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:

Originally Posted by qyot27

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

to which I replied:

Originally Posted by FranceBB

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)
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]

Originally Posted by FranceBB

Thanks Ferenc! Keep them coming!

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.micros...redist.x64.exe
x86 - https://download.visualstudio.micros...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]

Originally Posted by pinterf

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

Originally Posted by pinterf

but I won't do that

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

[manolito]

Originally Posted by FranceBB

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

You can drop me from this list now...
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

[ryrynz]

Originally Posted by manolito

You can drop me from this list now...

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]

Originally Posted by manolito

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.

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