AviSynth+ thread Vol.2

[real.finder]

scalef/scaleb should be as fast as ymax, ymin etc... anyway pinterf should give the right answer

anyway, I will try add new constants for full range ymaxf, yminf etc... and do PR

[Dogway]

That would lead to lots of string if else's or ReplaceStr() to change ie. ymax to ymaxf. Wouldn't be easier an argument for it? I don't see how one would want to mix full scale with stretched constants.

Anyway, thanks for looking into it, this thing was affecting my code progress.

[real.finder]

try https://www.solidfiles.com/v/ZZvV2ezjvvnQn

it has new yfmin, yfmax, cfmin and cfmax keywords

[Dogway]

Thank you. I think that nonef was a good idea except for displacing the option to use FloatUV for 32-bit chroma processing. I'm currently rebasing all my scripts.

[zorr]

Originally Posted by pinterf

New build, primarily for zorr, propAdd allows Clip type. Not tested at all, I had time only for adding the possibility.
Avisynth 3.7.1 20210618 test5

Wow thanks! I'll conduct some testing after my current MVTools test run is finished.

[GMJCZP]

Originally Posted by pinterf

Patience, please, I'm not a live L3 support line.

Thanks for your efforts.
I solved my technical problems, I hope.

[FranceBB]

The new build works fine on XP x86, Ferenc, thanks!
About the fact that Visual Studio 2022 won't support v141_xp as target, well... I'm just gonna say that the disastrous day in which Avisynth won't work on XP anymore is gonna be the day in which I'll shut down forever the Windows XP Virtual Machine and I'll fire up the Sucksdown 10 one... :'(

(or if by that time we'll have everything working on Linux, then I'll just stick with Fedora eheheheh)

[zorr]

Test results: I think I was able to store a clip into frame properties, at least there was no error and the clip displays fine after that. This works:

clip = propSet(clip, "test", function[store_this](clip c) { return store_this } )

and I think it can be turned into an array of clips by adding

clip = propSet(clip, "test", function[store_this](clip c) { return store_this }, mode=1 )

However I can't get the clip out. There's no propGetClip() -function. Doing

return ScriptClip(clip, """ return propGetAny(clip, "test") """)

returns Error getting frame property "test": type 'c' not supported

and if I try to read a clip from an array with

return ScriptClip(clip, """ return propGetAsArray(clip, "test")[0] """)

it returns ScriptClip: Function did not return a video clip! (Was the undefined value)

So looks like there needs to be some additional support for reading the clip typed frame properties.

Oh, and for some reason the plugins in x64 directory were actually 32bit versions. I just replaced them with my previous x64 versions.

[tormento]

Originally Posted by FranceBB

I'll fire up the Sucksdown 10 one... :'(

Or 11 directly.

Originally Posted by FranceBB

(or if by that time we'll have everything working on Linux, then I'll just stick with Fedora eheheheh)

Picture that I am currently using Windows 10 + WSLg with Debian. They introduced graphic and CUDA support too. In many instances it can get better scores than pure Linux.

[MysteryX]

Levels function isn't working in 16-bit. Output is completely black.

ConvertBits(16)
#ConvertToRGB64(matrix="Rec601")
ConvertToPlanarRGB(matrix="Rec601")
Levels(0, 1/2.2, 255, 0, 255)
ConvertToY(matrix="Rec601")
ConvertToYUV420()

[feisty2]

because "white" in int16 is 65535 not 255

[pinterf]

Originally Posted by MysteryX

Levels function isn't working in 16-bit. Output is completely black.

http://avisynth.nl/index.php/Levels
There is no automatic scaling.

[pinterf]

Originally Posted by zorr

However I can't get the clip out. There's no propGetClip() -function. Doing

return ScriptClip(clip, """ return propGetAny(clip, "test") """)

returns Error getting frame property "test": type 'c' not supported

Thanks, then I'll arrange a next turn soon.

[pinterf]

Originally Posted by Dogway

Yes, "{n} scalef" is almost as fast as "none". The problem is we are still using 8-bit constants which is a bit misleading. I thought ymax, ymin... constants were there to replace 8-bit expression syntax and make it cleaner.

The zillion options (both commandline arguments and internal helper keywords) of autoscaling or using 8 bit values which are converted automatically were created for help. Because when Avisynth got 10+ bits, expressions supported only 8 bits. To help the transition to translate the scripts to HBD aware (which was and is mainly done by the huge work of real.finder) these various options appeared, first in masktools then later in Expr.

I have to mention (not for you, Dogway, because you experienced a lot with Expr), using 8 bit constants are safe, they are internally treated as 32 bit floats so e.g. 16/255 does not become 0 inside.

[pinterf]

Originally Posted by real.finder

scalef/scaleb should be as fast as ymax, ymin etc... anyway pinterf should give the right answer

anyway, I will try add new constants for full range ymaxf, yminf etc... and do PR

Expressions with operation on constants are optimized. E.g. 2 2 * is precalculated to 4. I have to check but for example the expression '235 scalef' is optimized as well during the parsing time to a single constant.

Other optimizations exists, e.g. x Power of 2 is optimized to x*x (powers -1, 0, 1, 2, 3 and 4 are handled)

[pinterf]

Originally Posted by Dogway

I found something strange. Using the next expression in 16-bit to convert to TV levels yields a byte white level of 234:

"x ymax ymin - range_max / * ymin +"

That would correspond to (n*256):

"x 60160 4096 - 65535 / * 4096 +"

This is fixed if I multiply 235*257 (= 60395) instead to get the correct ymax 16-bit value.
Shouldn't this be fixed internally? I can set scale_inputs to "allf" and it fixes, but I'm not sure that's the original intention of the option (scale expression to 8-bit). Also by doing so I lose the option to use "FloatUV" for 32-bit chroma, since there's no "FloatUVf".

What is your script? This one returns 235.

ColorBarsHD(pixel_type = "YUV444P16")
Expr("65535","65535","65535")
Expr("x ymax ymin - range_max / * ymin +")
ConvertBits(8)
ScriptClip("""
Subtitle(String(expr("x").AverageLuma()))
""")

EDIT:
I got it where you got 234. This happens only when you mix the 8 bit inputs with 16 bit ranges.
(235 - 16) / 255 is not the same conversion factor as (60160 - 4096) / 65535

Calculations:

255.0f * (235.f - 16.f) / 255.f + 16.0f;
Result = 235.0

255.0f * (60160.f - 4096.f) / 65535.f + 16.0f)
Result = 234.1478

65535 * (60160.f - 4096.f) / 65535.f + 4096.0f;
Result: 60160.0

[pinterf]

['Clip' type frame property read]
Next test iteration:
AviSynth+ 3.7.1-test6 20210621

[pinterf]

Originally Posted by Dogway

For conversions you need to full scale stretch if working in PC levels. Read here.

In any case, I don't care anymore what avisynth+ does, using auto-scaling is very slow, "allf" is about 30% slower than "none" because the constants (ymax, range_max, etc) are computed at runtime. So I'm bulding a look up table which will speed things up quite a bit. Thought pinterf wanted to fix it but he doesn't seem very interested on the topic from lack of feedback.

    #                           8-bit       10-bit        12-bit       14-bit          16-bit          32-bit
    range_min  = Select (bits,  [  0,  0],  [   0,   0],  [   0,   0], [    0,    0],  [    0,    0],  [        0,        0])
    ymin       = Select (bits,  [ 16, 16],  [  64,  80],  [ 256, 272], [ 1024, 1040],  [ 4096, 4112],  [  16/255.,  16/255.])
    cmin       = Select (bits,  [ 16, 16],  [  64,  80],  [ 256, 272], [ 1024, 1040],  [ 4096, 4112],  [-112/255.,-112/255.])
    range_half = Select (bits,  [128,128],  [ 512, 640],  [2048,2176], [ 8192, 8320],  [32768,32896],  [ 128/255., 128/255.])
    yrange     = Select (bits,  [219,219],  [ 876,1095],  [3504,3723], [14016,14235],  [56064,56283],  [ 219/255., 219/255.])
    crange     = Select (bits,  [224,224],  [ 896,1120],  [3584,3808], [14336,14560],  [57344,57568],  [ 224/255., 224/255.])
    ymax       = Select (bits,  [235,235],  [ 940,1175],  [3760,3995], [15040,15275],  [60160,60395],  [ 235/255., 235/255.])
    cmax       = Select (bits,  [240,240],  [ 960,1200],  [3840,4080], [15360,15600],  [61440,61680],  [ 107/255., 107/255.])
    range_max  = Select (bits,  [255,255],  [1020,1023],  [4080,4095], [16320,16383],  [65280,65535],  [1.0,1.0])
    range_size = Select (bits,  [256,256],  [1023,1023],  [4096,4096], [16384,16384],  [65536,65536],  [1.0,1.0])

Let's see only a single example.
How did you get the constant of 80 for 10 bit ymin instead of 64?
Min values must keep the *rule of 8_bit_min * 2^(N-8) where N is the bit depth.
As for limited range maximum values there was a decision of keeping the same 8_bit_max * 2^(N-8) calculation, against the other choice of (8_bit_max + 1) * 2^(N-8) - 1.
Limited range ConvertBits() conversions are simple bit-shifts (upwards) and round-then-bitshift (downwards)

(note: Expr is always rounding and does not truncate before converting back to the integer domain)

EDIT: see calculations in my previous answer (#1116) where I put it where your calculation went astray in my opinion.

[Dogway]

Even if the ex_dlut() function might seem overdone to simply "fix" an issue in Expr() I will keep it to save some operations (ie. "ymax ymin - range_max /") and for reference.

You are referencing an old table which was wrong. You can look my table 4 posts later . Or simply check the updated function in ExTools 2.0 with float precision. It works on my tests but if you spot something wrong let me know.

Over the development of Transforms Pack, where I need bit perfect conversions I noticed something was off and that led me to this conclusion.

Your sample script is crafted to output the result you look for. A real world scenario is more like the following (no body uses fulls=true to be honest).

ColorBarsHD(pixel_type = "YUV444P8")
Expr("255","255","255")
ConvertBits(16)
Expr("x ymax ymin - range_max / * ymin +")
ConvertBits(8)
ScriptClip("""
Subtitle(String(expr("x").AverageLuma()))
""")

EDIT: To answer your #1116 EDIT. Yes, range_max is scaling in full stretch fashion whereas everything else does in bitshift, disparity that leads to that error.

255.0f * (60160.f - 4096.f) / 65280.f + 16.0f)
Result = 235.0

65280 * (60160.f - 4096.f) / 65280.f + 4096.0f;
Result: 60160.0

[pinterf]

Originally Posted by Dogway

Your sample script is crafted to output the result you look for. A real world scenario is more like the following (no body uses fulls=true to be honest).

Ah, that's the problem then. Wrong use of ConvertBits makes 255 to 255*256 instead of 65535.
Well, if people are not telling the conversion type if it should use full or limited range but still expect perfectly guessed results, I can't help with it. I'm somehow reluctant to support Avisynth Expr with new bad-habit workaround constants.