Avisynth+

[poisondeathray]

Here is a similar test on a 0-255, Y,U,V pattern (0-255 Y just copied to the U,V planes), and again 8x back and forth, and then to TV range

You end up with Y 16-235 , U,V 16-240 hard limits (so chroma=100 for smooth levels is probably correct value for typical usage scenarios), but the average is skewed with coloryuv , resulting in the colorization of greyscale values. Also see the line artifacts again with coloryuv (smoothlevels had dither disabled)
https://s33.postimg.cc/uze76ln27/0-255_YUV_pattern_compare.png (https://postimages.org/)

[pinterf]

I have noticed and commented a line in color.cpp, this is the final step in lut creation, so far calculation was done in double precision:

// Convert back to int
int iValue = int(value); // hmm P.F. 20180226 no rounding?

[`Orum]

I have noticed and commented a line in color.cpp
Ah, that might be it. Do you have a test build with rounding? Otherwise I'll probably monkey with it and build one myself.
:thanks:

[pinterf]

I'll build one then

[pinterf]

EDIT:
Limiter dont work as required, mod to Levels

Are you sure?

[pinterf]

Avisynth+ r2710 test build: installer w/o C++ redistributables.
https://drive.google.com/open?id=1tMwuXOCx47jf5SpY4VW4v99uCUtwwemj

New things since last test:
- Fix: ColorYUV: round to avoid green cast on consecutive TV<>PC
- Enhanced: Limiter to work with 32 bit float clips. 'show' option still not supported
- Enhanced: Limiter new parameter bool 'autoscale' default false.
If set, minimum/maximum luma/chroma values are treated as they were in 8 bit range (but non-integer values are allowed), limiter will autoscale it.
Default: does not scale at all, parameters are used as-is. Parameters now are of float type to handle 32 bit float values.
- New: function bool VarExists(String variable_name)
Checks if a variable exists
Returns true if variable exists, false otherwise

[LigH]

So AviSynth+ "VarExists" is comparable to PHP "isset"?

[wonkey_monkey]

So AviSynth+ "VarExists" is comparable to PHP "isset"?

Hopefully it doesn't return "false" when the variable exists but is null, which is what isset does...

[LigH]

I believe AviSynth has no "null" value/type.

[pinterf]

They can hold an 'undefined' value. But in this case the variable still exists and the function returns true.

[StainlessS]

BlankClip
#Fred=Undefined # Uncomment to show True
Ex=RT_VarExist("FRED") # Edit or r2710 VarExists
Subtitle("VarExist for fred="+String(ex))

False unless assigned Undefined [EDIT: or some variable type]
Will show true in Script function where Fred is an un-supplied optional arg, ie UnDefined. (exists but not defined as anything in particular)

[StainlessS]

Are you sure?

Went all the way back to v2.57 and could not get Limiter to fail as posted, sorry, I have not explanation, other than senility.

[StainlessS]

@P,
Note, the builtin file existing function is named Exist(), ie no ending 's', so I used RT_VarExist() and RT_FunctionExist() both without ending 's',
(I initially did RT_VarExists with ending s and changed to be compatible style with builtin Exist).

EDIT: I see that you have already implemented FunctionExists() with trailing 's', maybe too late to change


Function Fred() {return True}
BlankClip
Ex=FunctionExists("FRED")
Subtitle("FunctionExists for fred="+String(ex))


EDIT: To below,
... because of senility

Yeh, sometimes I miss out the odd 's', and sometime I add way too many, hence the usernamesssss.

[pinterf]

Good advice, thanks, unless 's' is missing from there because of senility :)

[pinterf]

Ok, VarExist name is fixed and 'show' is supported in 32bit float, here is r2713
Avisynth+ r2713 test build: installer w/o C++ redistributables.

EDIT: link refreshed (I have messed up the 32/64 bit files)
https://drive.google.com/open?id=1GCgr5rCbr5HLLA9OJJwz-7LIerlDQYLn

New things for today:
- Fix: ColorYUV: round to avoid green cast on consecutive TV<>PC
- Enhanced: Limiter to work with 32 bit float clips.
- Enhanced: Limiter new parameter bool 'autoscale' default false.
If set, minimum/maximum luma/chroma values are treated as they were in 8 bit range (but non-integer values are allowed), limiter will autoscale it.
Default: does not scale at all, parameters are used as-is. Parameters now are of float type to handle 32 bit float values.
- New: function bool VarExist(String variable_name)
Checks if a variable exists
Returns true if variable exists even if it holds 'Undefined', false otherwise

[StainlessS]

P, so you decied to keep FunctionExists with the extra 's', no sweat either way :)

Sorry, but latest ver$, have included 64 bit dll's in 32 bit install.

EDIT: And just to mitigate doubts about senility,
https://s20.postimg.cc/j62balrbx/untitled.jpg (https://postimages.org/)

EDIT: Above after total uninstall, reinstall. [WinXP32]
EDIT: Not just that dll, looks like maybe all of them.

EDIT: Double check on senility [better to be sure]


C:\Documents and Settings\root>avsmeter -avsinfo

AVSMeter 2.7.7 (x86) - Copyright (c) 2012-2018, Groucho2004

Cannot load a 64 bit DLL in 32 bit Avisynth: 'C:/Program Files/AviSynth+/plugins+/ConvertStacked.dll'.

[pinterf]

EDIT: Double check on senility [better to be sure]

Senility contest: I won.
I'll upload a proper version tomorrow, until then the ColorYUV rounding issue fix can be investigated in r2710, some posts before.

[pinterf]

r2713 reuploaded

[StainlessS]

Installed, everything hunky dory here thanx https://www.cosgan.de/images/more/bigs/e250.gif

[`Orum]

r2713's ColorYUV(levels="TV->PC") still looks different from MPC-HC's conversion (MPC-HC's caucasian skin-tone colors become redder post-conversion than AviSynth+'s), but at least it no longer seems to have the green cast any more, and repeated conversions back and forth (in AviSynth+) work fine now. So, the difference may be that MPC-HC is doing it incorrectly, I'm not really sure and don't have the time to dig through their code right now. As far as I'm concerned, the issue is resolved for AviSynth+, unless someone can demonstrate otherwise.

Thanks!

Edit: I'm starting to suspect the difference now really is related to a conversion error in MPC-HC, as other colors, like orange/yellow, appear to be oversaturated after conversion.

[pinterf]

Perhaps a rec601-709 mismatch happening somewhere in the conversion chain? (red cast)

[raffriff42]

I've noticed what I think is some color shift toward Cb-/Cr- with the ColorYUV(levels="TV->PC") / ColorYUV(levels="PC->TV")...

There is an offset-by-negative-one for each round trip.
That's not a bug, it's a consequence of 8-bit math doing something (round trip) it wasn't designed to do.
Attempting to fix it results in a slightly worse one-way conversion.
Increasing the source bit depth decreases the error; with 32-bit float it's un-measureable.
Alternatively, when you know you are doing a round trip, you could add an offset manually: function s(clip c) {
return c.ColorYUV(levels="TV->PC")
\ .ColorYUV(levels="PC->TV", off_y=1, off_u=1, off_v=1)
}

[pinterf]

New build r2719
https://drive.google.com/open?id=1gAyHUSGo8A_io8btrZZn31Z8JLfZJ3yo
And a test masktools2 (2.2.15) that matches this avisynth version
https://drive.google.com/open?id=1H0OnH_ACwJXb6iT7pO0hVlXCwd2c-afI

I'm posting both test builds here, because they are tightly connected.

real.finder, who is responsible with many old scripts, asked me for these features for a long time. And I resisted because I was against such autoconversion. Anyway, you can start experimenting but you have to understand when you can use this feature safely (but maybe it's less prone to errors than mis-using scaleb and scalef)

- LUT functions in masktools2 and Expr in Avisynth+ have now two new parameters: scale_inputs and clamp_float (see below). In same cases they allow a quite a convenient way of using old 8 bit lut expressions to be used for generic bit-depth.

- The other feature in masktools2 is the new 'use_expr' parameter.
This parameter allows passing the whole expression to Avisynth+ when the lut filter would use the slow interpreted realtime way of expression calculation (for 16 bits no xy lut table exists because it is too big to fit in the memory). Try setting use_expr=1 for mt_lutxy (that will pass the expression to Avisynth for 10 or more bits) will drastically speed up a 16bit mt_lutxy.

Avisynth:
- New: Expr: implement 'clip' three operand operator like in masktools2
Description: clips (clamps) value: x minvalue maxvalue clip -> max(min(x, maxvalue), minvalue)
- New: Expr: Parameter "clamp_float"
True: clamps 32 bit float to valid ranges, which is 0..1 for Luma or for RGB color space and -0.5..0.5 for YUV chroma UV channels
Default false, ignored (treated as true) when scale_inputs scales float
- New: Expr: parameter "scale_inputs" (default "none")

Autoscale any input bit depths to 8-16 bit for internal expression use, the conversion method is either full range or limited YUV range.

Feature is similar to the one in masktools2 v2.2.15

The primary reason of this feature is the "easy" usage of formerly written expressions optimized for 8 bits.

Use
- "int" : scales limited range videos, only integer formats (8-16bits) to 8 (or bit depth specified by 'i8'..'i16')
- "intf": scales full range videos, only integer formats (8-16bits) to 8 (or bit depth specified by 'i8'..'i16')
- "float" or "floatf" : only scales 32 bit float format to 8 bit range (or bit depth specified by 'i8'..'i16')
- "all": scales videos to 8 (or bit depth specified by 'i8'..'i16') - conversion uses limited_range logic (mul/div by two's power)
- "allf": scales videos to 8 (or bit depth specified by 'i8'..'i16') - conversion uses full scale logic (stretch)
- "none": no magic

Usually limited range is for normal YUV videos, full scale is for RGB or known-to-be-fullscale YUV

By default the internal conversion target is 8 bits, so old expressions written for 8 bit videos will probably work.
This internal working bit-depth can be overwritten by the i8, i10, i12, i14, i16 specifiers.

When using autoscale mode, scaleb and scalef keywords are meaningless, because there is nothing to scale.

How it works:
- This option scales all 8-32 bit inputs to a common bit depth value, which bit depth is 8 by default and can be
set to 10, 12, 14 and 16 bits by the 'i10'..'i16' keywords
For example: scale_inputs="all" converts any inputs to 8 bit range. No truncation occurs however (no precision loss),
because even a 16 bit data is converted to 8 bit in floating point precision, using division by 256.0 (2^16/2^8).
So the conversion is _not_ a simple shift-right-8 in the integer domain, which would lose precision.
- Calculates expression (lut, lut_xy, lut_xyz, lut_xyza)
- Scales the result back to the original video bit depth.
Clamping (clipping to valid range) and converting to integer occurs here.

The predefined constants such as 'range_max', etc. will behave according to the internal working bit depth

Warning#1
This feature was created for easy porting earlier 8-bit-video-only lut expressions.
You have to understand how it works internally.

Let's see a 16bit input in "all" and "allf" mode (target is the default 8 bits)

Limited range 16->8 bits conversion has a factor of 1/256.0 (Instead of shift right 8 in integer domain, float-division is used or else it would lose presision)

Full range 16->8 bits conversion has a factor of 255.0/65535

Using bit shifts (really it's division and multiplication by 2^8=256.0):
result = calculate_lut_value(input / 256.0) * 256.0
Full scale 16-8-16 bit mode ('intf', 'allf')
result = calculate_lut_value(input / 65535.0 * 255.0 ) / 255.0 * 65535.0

Use scale_inputs = "all" ("int", "float") for YUV videos with 'limited' range e.g. in 8 bits: Y=16..235, UV=16..240).
Use scale_inputs = "allf" (intf, floatf) for RGB or YUV videos with 'full' range e.g. in 8 bits: channels 0..255.

When input is 32bit float, the 0..1.0 (luma) and -0.5..0.5 (chroma) channel is scaled
to 0..255 (8 bits), 0..1023 (i10 mode), 0..4095 (i12 mode), 0..16383(i14 mode), 0..65535(i16 mode) then back.

Warning#2
One cannot specify different conversion methods for converting before and after the expression.
Neither can you specify different methods for different input clips (e.g. x is full, y is limited is not supported).

masktools2:
- 32 bit float U and V chroma channels are now zero based (+/-0.5 for full scale). Was: 0..1, same as luma
(Following the change in Avisynth+ over r2664: use this plugin with r2996 or newer)
Affected predefined expression constants when plane is U or V:
cmin and cmax (limited range (16-128)/255 and (240-128)/255 instead of 16/255.0 and 240/255.0
range_max: 0.5 instead of 1.0
new: introduce range_min: -0.5 for float U/V chroma, 0 otherwise
range_half (0.0 instead of 0.5)
(range_size remained 1.0)
- New expression syntax for Lut expressions: autoscale any input (x,y,z,a) bit depths to 8-16 bits for internal
expression use. The primary reason of this feature is the "easy" usage of formerly written 8 bit optimized expressions.

New parameters for lut functions:
String "scale_inputs": "all","allf","int","intf","float","floatf","none", default "none"
and
Boolean "clamp_float": default false, but treated as always true (and thus ignored) when scale_inputs involves a float autoscale.
and
Boolean "use_expr": default 0, calls fast JIT-compiled "Expr" in Avisynth+ for mt_lut, lutxy, lutxyz, lutxyza
0: no Expr, use slow internal realtime calc if needed (as before)
1: call Expr for bits>8 or lutxyza
2: call Expr, when masktools would do its slow realtime calc (see 'realtime' column in the table above)

Extends and replaces experimental clamp_xxxx keywords.

[tormento]

real.finder, who is responsible with many old scripts, asked me for these features for a long time.
Can we use this builds with his older scripts or any processed video will turn into a LSD trip? :D

[pinterf]

Can we use this builds with his older scripts or any processed video will turn into a LSD trip? :D
I suppose these versions are backward compatible. But will show no gain until you specify the parameters that enable the features. Again, you have to know what you are doing. And check the results.

[real.finder]

expr scale seems work fine

but I got mt_lutXX does not have a named argument "scale_inputs" in xp I used in VM, same for use_expr

I did check the dll date and it seems very old!

[pinterf]

expr scale seems work fine

but I got mt_lutXX does not have a named argument "scale_inputs" in xp I used in VM, same for use_expr

I did check the dll date and it seems very old!
Weird, all dlls in the 7z package are from yesterday.

[real.finder]

Weird, all dlls in the 7z package are from yesterday.

https://s8.postimg.cc/jbn3o1i9h/Untitled.png

google drive maybe give the 1st test you did not the overwritten new one

[pinterf]

google drive maybe give the 1st test you did not the overwritten new one
Sorry, please check the fixed link again. Seems I have novice file copying problems nowadays.

[tormento]

And check the results.
No mushroom effect yet. :p

[real.finder]

Sorry, please check the fixed link again. Seems I have novice file copying problems nowadays.

thank you it work now, but there are some small problems check here https://forum.doom9.org/showthread.php?p=1844631

[pinterf]

Thanks, real.finder for the report. scale_inputs "float" with input bit depth integer was misinterpreted. r2721 fixes that problem.

AviSynth+ r2721 test build (hopefully one of the last tests):
https://drive.google.com/open?id=1QkyVQ0XK-DP6-HGR8JwN9QyQMK-vHhG6
Matching masktools2 2.2.15 test 5 (not changed since last version)
https://drive.google.com/open?id=1H0OnH_ACwJXb6iT7pO0hVlXCwd2c-afI

[`Orum]

Perhaps a rec601-709 mismatch happening somewhere in the conversion chain? (red cast)
Could be, I'll have to dig through their code when I have more time to investigate.

There is an offset-by-negative-one for each round trip.
That's not a bug, it's a consequence of 8-bit math doing something (round trip) it wasn't designed to do.
Attempting to fix it results in a slightly worse one-way conversion.
Well, as I said my test only proved there was an issue with reciprocal conversion, but I still noticed a greenish tint in a single conversion (e.g. just a single TV->PC conversion). There shouldn't be a tint in either direction (apart from saturation changes, I think) when a conversion is performed one-way.

Edit: I think I can cook up a better example with the Histogram() function that doesn't involve repeated conversions. I'll post back here when I have time (unless that patch has since made it into the release builds).

[pinterf]

And some test builds again.

Fixes 'scalef' and 'scaleb' for U/V chroma parts of 32bit float formats (bith in MaskTools2 lut and Avisynth+ Expr)
Thanks to real.finder for the report.

Not tightly avs+ related but since I put them here together:
Finished a new feature for masktools2, requested by real.finder a long time ago:
New masktools2 parameter: 'cplace' for mt_merge.
Parameter String 'cplace' : "mpeg1" or "mpeg2" (default) chroma placement for 4:2:0 formats when luma=true.

Avisynth+ r2722 (installer w/o VC redistributables)
https://drive.google.com/open?id=1N34BdfebCvfrt4PAQxqg_w0Ur2AxrE_n

Masktools2 2.2.15_test8
https://drive.google.com/open?id=1g-6XFMdVIoU7oln4unLIiOpzctMjKhoB

[magiblot]

I have noticed many filters have been added a bool "dither" parameter in AVS+ (Levels, Tweak, RGBAdjust...).

Wouldn't it be appropiate for ColorYUV to have one as well?

[real.finder]

I have noticed many filters have been added a bool "dither" parameter in AVS+ (Levels, Tweak, RGBAdjust...).

Wouldn't it be appropiate for ColorYUV to have one as well?

it's added in avs26 not avs+

[magiblot]

it's added in avs26 not avs+

Sorry. In that case, pinterf has nothing to do with it.

[pinterf]

New release with plenty of new features and changes.

Download Avisynth+ r2728 (https://github.com/pinterf/AviSynthPlus/releases/tag/r2728)

Most of the changes are already documented on avisynth.nl pages.

Note:
This release will soon be followed by some updated plugins, mostly because of the 32 bit float format internal changes:
masktools2 2.2.17 (https://github.com/pinterf/masktools/releases/tag/2.2.17) updated
FFT3DFilter 2.5 (https://github.com/pinterf/fft3dfilter/releases/tag/v2.5) updated
RgTools 0.97 (https://github.com/pinterf/RgTools/releases/tag/0.97) updated

20180702 r2728
--------------
- New: Expr: implement 'clip' three operand operator like in masktools2
Description: clips (clamps) value: x minvalue maxvalue clip -> max(min(x, maxvalue), minvalue)
- New: Expr: Parameter "clamp_float"
True: clamps 32 bit float to valid ranges, which is 0..1 for Luma or for RGB color space and -0.5..0.5 for YUV chroma UV channels
Default false, ignored (treated as true) when scale_inputs scales float
- New: Expr: parameter "scale_inputs" (default "none")

Autoscale any input bit depths to 8-16 bit for internal expression use, the conversion method is either full range or limited YUV range.

Feature is similar to the one in masktools2 v2.2.15

The primary reason of this feature is the "easy" usage of formerly written expressions optimized for 8 bits.

Use
- "int" : scales limited range videos, only integer formats (8-16bits) to 8 (or bit depth specified by 'i8'..'i16')
- "intf": scales full range videos, only integer formats (8-16bits) to 8 (or bit depth specified by 'i8'..'i16')
- "float" or "floatf" : only scales 32 bit float format to 8 bit range (or bit depth specified by 'i8'..'i16')
- "all": scales videos to 8 (or bit depth specified by 'i8'..'i16') - conversion uses limited_range logic (mul/div by two's power)
- "allf": scales videos to 8 (or bit depth specified by 'i8'..'i16') - conversion uses full scale logic (stretch)
- "none": no magic

Usually limited range is for normal YUV videos, full scale is for RGB or known-to-be-fullscale YUV

By default the internal conversion target is 8 bits, so old expressions written for 8 bit videos will probably work.
This internal working bit-depth can be overwritten by the i8, i10, i12, i14, i16 specifiers.

When using autoscale mode, scaleb and scalef keywords are meaningless, because there is nothing to scale.

How it works:
- This option scales all 8-32 bit inputs to a common bit depth value, which bit depth is 8 by default and can be
set to 10, 12, 14 and 16 bits by the 'i10'..'i16' keywords
For example: scale_inputs="all" converts any inputs to 8 bit range. No truncation occurs however (no precision loss),
because even a 16 bit data is converted to 8 bit in floating point precision, using division by 256.0 (2^16/2^8).
So the conversion is _not_ a simple shift-right-8 in the integer domain, which would lose precision.
- Calculates expression (lut, lut_xy, lut_xyz, lut_xyza)
- Scales the result back to the original video bit depth.
Clamping (clipping to valid range) and converting to integer occurs here.

The predefined constants such as 'range_max', etc. will behave according to the internal working bit depth

Warning#1
This feature was created for easy porting earlier 8-bit-video-only lut expressions.
You have to understand how it works internally.

Let's see a 16bit input in "all" and "allf" mode (target is the default 8 bits)

Limited range 16->8 bits conversion has a factor of 1/256.0 (Instead of shift right 8 in integer domain, float-division is used or else it would lose presision)

Full range 16->8 bits conversion has a factor of 255.0/65535

Using bit shifts (really it's division and multiplication by 2^8=256.0):
result = calculate_lut_value(input / 256.0) * 256.0
Full scale 16-8-16 bit mode ('intf', 'allf')
result = calculate_lut_value(input / 65535.0 * 255.0 ) / 255.0 * 65535.0

Use scale_inputs = "all" ("int", "float") for YUV videos with 'limited' range e.g. in 8 bits: Y=16..235, UV=16..240).
Use scale_inputs = "allf" (intf, floatf) for RGB or YUV videos with 'full' range e.g. in 8 bits: channels 0..255.

When input is 32bit float, the 0..1.0 (luma) and -0.5..0.5 (chroma) channel is scaled
to 0..255 (8 bits), 0..1023 (i10 mode), 0..4095 (i12 mode), 0..16383(i14 mode), 0..65535(i16 mode) then back.

Warning#2
One cannot specify different conversion methods for converting before and after the expression.
Neither can you specify different methods for different input clips (e.g. x is full, y is limited is not supported).

- Fix: Expr: expression string order for planar RGB is properly r-g-b like in original VapourSynth version, instead of counter-intuitive g-b-r.
- Fix: Expr: check subsampling when a different output pixel format is given
- Fix: ColorYUV: round to avoid green cast on consecutive TV<>PC
- Enhanced: Limiter to work with 32 bit float clips
- Enhanced: Limiter new parameter bool 'autoscale' default false.
If set, minimum/maximum luma/chroma values are treated as they were in 8 bit range (but non-integer values are allowed), limiter will autoscale it.
Default: does not scale at all, parameters are used as-is. Parameters now are of float type to handle 32 bit float values.
- New: function bool VarExist(String variable_name)
Checks if a variable exists
Returns true if variable exists even if it holds 'Undefined', false otherwise
- Fix: RGBAdjust memory leak when used in ScriptClip
- Enhanced: RGBAdjust new parameter: conditional (like in ColorYUV)
The global variables "rgbadjust_xxx" with xxx = r, g, b, a, rb, gb, bb, ab, rg, gg, bg, ag are read each frame, and applied.
It is possible to modify these variables using FrameEvaluate or ConditionalReader.
- Enhanced: RGBAdjust: support 32 bit float ('analyze' not supported, 'dither' silently ignored)
- Enhanced: AviSource to support more formats with 10+ bit depth.
http://avisynth.nl/index.php/AviSource

When pixel_type is not specified or set to "FULL", AviSource will try to request the formats one-by-one in the order shown in the table below.

When a classic 'pixel_type' shares more internal formats (such as YUV422P10 first tries to request the v210 then P210 format)
you can specify one of the specific format directly. Note that high bit-depth RGBP is prioritized against packed RGB48/64.

The 'FourCCs for ICDecompressQuery' column means that when a codec supports the format, it will serve the frame in that one, Avisource then will convert it to the proper colorspace.

Full support list (* = already supported):
'pixel_type' Avs+ Format FourCC(s) for ICDecompressQuery
YV24 YV24 *YV24
YV16 YV16 *YV16
YV12 YV12 *YV12
YV411 YV411 *Y41B
YUY2 YUY2 *YUY2
RGBP10 RGBP10 G3[0][10] r210 R10k
r210 RGBP10 r210
R10k RGBP10 R10k
RGBP RGBP10 G3[0][10] r210 R10k
RGBP12 G3[0][12]
RGBP14 G3[0][14]
RGBP16 G3[0][16]
RGBAP10 G4[0][10]
RGBAP12 G4[0][12]
RGBAP14 G4[0][14]
RGBAP16 G4[0][16]
RGB32 RGB32 *BI_RGB internal constant (0) with bitcount=32
RGB24 RGB24 *BI_RGB internal constant (0) with bitcount=24
RGB48 RGB48 BGR[48] b48r
RGB64 RGB64 *BRA[64] b64a
Y8 Y8 Y800 Y8[32][32] GREY
Y Y8 Y800 Y8[32][32] GREY
Y10 Y1[0][10]
Y12 Y1[0][12]
Y14 Y1[0][14]
Y16 Y1[0][16]
YUV422P10 YUV422P10 v210 P210
v210 YUV422P10 v210
P210 YUV422P10 P210
YUV422P16 YUV422P16 P216
P216 YUV422P16 P216
YUV420P10 YUV420P10 P010
P010 YUV422P10 P010
YUV420P16 YUV420P16 P016
P016 YUV422P16 P016
YUV444P10 YUV444P10 v410
v410 YUV444P10 v410
- Changed (finally): 32bit float YUV colorspaces: zero centered chroma channels.
U and V channels are now -0.5..+0.5 (if converted to full scale before) instead of 0..1
Note: filters that relied on having the U and V channel center as 0.5 will fail.
Why: the old UV 0..1 range was a very-very early decision in the high-bitdepth transition project. Also it is now
compatible with z_XXXXX resizers (zimg image library, external plugin at the moment).
- New function: bool IsFloatUvZeroBased()
For plugin or script writers who want to be compatible with pre r2672 Avisynth+ float YUV format:
Check function availablity with FunctionExists("IsFloatUvZeroBased").
When the function does not exists, the center value of 32 bit float U and V channel is 0.5
When IsFloatUvZeroBased function exists, it will return true (always for official releases) if U and V is 0 based (+/-0.5)
- Fix: RGB64 Turnleft/Turnright (which are also used in RGB64 Resizers)
- Fix: Rare crash in FrameRegistry
- Enhanced: Allow ConvertToRGB24-32-48-64 functions for any source bit depths
- Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits
E.g. after a 8->32 bit fulls=false fulld=true:
Y: 16..235 -> 0..1
U/V: 16..240 -> -0.5..+0.5
Note: now ConvertBits does not assume full range for YUV 32 bit float.
Default values of fulls and fulld are now true only for RGB colorspaces.
- Fix: couldn't see variables in avsi before plugin autoloads (colors_rgb.avsi issue)
- Fix: LoadVirtualdubPlugin: Fix crash on exit when more than one instances of a filter was used in a script
- New: LoadVirtualdubPlugin update:
- Update from interface V6 to V20, and Filtermod version 6 (partial)
- VirtualDub2 support with extended colorspaces
Allow RGB24, RGB48, RGB64 besides RGB32
AutoConvert 8 bit Planar RGB to/from RGB24, RGBPA to/from RGB32 (lossless)
AutoConvert RGB48 and 16 bit Planar RGB(A) to/from RGB64 (lossless)
Support YUV(A) 8 bits: YV12, YV16, YV24, YV411, YUVA420P8, YUVA422P8, YUVA444P8
Support YUV(A) 10-16 bits (properly set "ref_x" maximum levels, no autoconvert)
- Supports prefetchProc2 callback (API >= V14 and prefetchProc2 is defined) for multiple input frames from one input clip
PrefetchFrameDirect and PrefetchFrame are supported. PrefetchFrameSymbolic not supported
- Supports prefetchProc callback (API >= V12 and prefetchProc is defined)
- Supports when filter changes frame count of the output clip
- Extra filter parameter added at the end of filter's (unnamed) parameter list
Imported Virtualdub filters are getting and extra named parameter to the end:
String [rangehint]
This parameter can tell the filter about a YUV-type clip colorspace info
Allowed values:
"rec601": limited range + 601
"rec709": limited range + 709
"PC.601": full range + 601
"PC.709": full range + 709
"" : not defined (same as not given)
Parameter will be ignored when clip is non-YUV
How it works: the hint will _not_ change the internal VirtualDub colorspace
constant (e.g. kPixFormat_YUV420_Planar -> kPixFormat_YUV420_Planar_709 will not happen).
Instead the base color space is kept and colorSpaceMode and colorRangeMode will set in PixmapLayout.formatEx.
Filter can either use this information or not, depending on supported API version and its implementation.
E.g. Crossfade(20,30) -> Crossfade(20,30,"rec601") though this specific filter won't use it.
- New function: BuildPixelType

Creates a video format (pixel_type) string by giving a colorspace family, bit depth, optional chroma subsampling and/or a
template clip, from which the undefined format elements are inherited.
"[family]s[bits]i[chroma]i[compat]b[oldnames]b[sample_clip]c"

string family: YUV, YUVA, RGB, RGBA, Y
int bits: 8, 10, 12, 14, 16, 32
string chroma: for YUV(A) 420,422,444,411. Ignored for RGB(A) and Y
bool compat (default false): returns packed rgb formats for 8/16 bits (RGB default: planar RGB)
bool oldnames (default false): returns YV12/YV16/YV24 instead of YUV420P8/YUV422P8/YUV444P8
clip sample_clip: when supported, its format is overridden by specified parameters (e.g. only change bits=10)

Example#1: define YUV 444 P 10

family = "YUV"
bits = 10
chroma = 444
compat = false
oldformat = false
s = BuildPixelType(family, bits, chroma, compat, oldformat)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

Example#2: Change only the bit depth of the format to 16

newbits = 16
c = last
s = BuildPixelType(bits=newbits, sample_clip=c)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

- Source: move to c++17, 'if constexpr' requires. Use Visual Studio 2017 (or GCC 7?). CMakeLists.txt changed.
- Source: C api: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init
- Source: C api: avs_is_same_colorspace VideoInfo parameters to const
- Project struct: changelog to git.
- Include current avisynth header files and def/exp file in installer, when SDK is chosen

[Groucho2004]

New release with plenty of new features and changes.:thanks:

[LigH]

I already wonder if complex scripts like QTGMC can take advantage of these changes (or even need adaptions to the new plugins?)...

[jpsdr]

:thanks:

[real.finder]

I already wonder if complex scripts like QTGMC can take advantage of these changes (or even need adaptions to the new plugins?)...

it will get more speed if it use expr especially with HBD, I need some times to update QTGMC and others

[Sparktank]

Not just AVS+, but other plugins as well.

Thanks a lot for these :)

[StainlessS]

EDIT: RUBBISH POST, PLEASE IGNORE.
Seems that I generated this bit with Grunt installed, thought is was from AVS+
I investigated it with Grunt not installed, however it had already been generated some time previous.
The scan examined builtin names, but got parameters from the Grunt plugin because of same Scriptclip name, oops.

ScriptClip "cs[showx]b[after_frame]b[args]s[local]b"



I'm trying to figure out how to adapt to using AVS standard with Grunt, or AVS+ without (concerning ScriptClip).

From http://avisynth.nl/index.php/GRunT
GRunT provides extended versions of the following run-time filters:
ScriptClip, ...

ScriptClip (clip clip, string filter [, bool showx, bool after_frame, string args, bool local])
GScriptClip(clip clip, string filter [, bool show , bool after_frame, string args, bool local])

As in the AviSynth internal counterparts, show (or showx) to true will display the actual values on the screen.


Presume that show/showx can be used to force original Scriptclip or GRunt version of ScriptClip when Grunt extended args NOT used.

AVS+, I See this Auto Generated using RT_InternalFunctions from Avisynth r2728 [EDIT: Via RT_Stats Make_Avisynth_BuiltIn_FunctionList.avs]

ScriptClip "cs[showx]b[after_frame]b[args]s[local]b"


There are probably multiple function definitions in AVS+ source, but there is only a single one available via InternalFunctions().


Colorbars(Pixel_Type="YV12").ShowFrameNumber
SSS="""
x=averageluma
Subtitle("Fred Exist="+String(VarExist("fred"))+String(x," : X=%f"),Size=24,align=5)
"""
fred=true
# UnComment below lines one at a time
#####################################
##### AVS+ With GRunt Installed #####
#ScriptClip(SSS,show=true) # OK, builtin
#ScriptClip(SSS,showx=true) # OK, Grunt
#ScriptClip(SSS,args="fred") # OK, Grunt
#ScriptClip(SSS,local=true) # OK, Grunt
#
#GScriptClip(SSS,show=true) # OK
#GScriptClip(SSS,showx=true) # Script Error. GScriptclip does not have a named argument 'showx'. EDIT: So OK, expected
#GScriptClip(SSS,args="fred") # OK
#GScriptClip(SSS,local=true) # OK
#####################################
##### AVS+ With GRunt Missing #####
#ScriptClip(SSS,show=true) # OK
#ScriptClip(SSS,showx=true) # Script Error. Scriptclip does not have a named argument 'showx'.
#ScriptClip(SSS,args="fred") # Script Error. Scriptclip does not have a named argument 'args'.
#ScriptClip(SSS,local=true) # Script Error. Scriptclip does not have a named argument 'local'.
#
#GScriptClip(SSS,show=true) # All GScripClip fail with missing Grunt dll, as not supported in Avs+
#GScriptClip(SSS,showx=true) #
#GScriptClip(SSS,args="fred") #
#GScriptClip(SSS,local=true) #
#####################################


Is AVS+ ScriptClip with showx, args and local documented somewhere ? [EDIT: the func definition 2 code blocks up suggests it exists]

GScript dll:- http://avisynth.nl/index.php/GScript
GSCript in Avs+: http://avisynth.nl/index.php/AviSynth%2B#GScript

In AviSynth+ there is no need to wrap your GScript code in a string. The language extensions are native to
AviSynth+ and can be used transparently.

Might best be rewritten in docs as
In AviSynth+ you must not wrap your GScript code in a GScript(" ... ") ...

Also, should be doc'ed that as well as GScript(), GEval(), and GImport() are not supported.

EDIT: I'm using below to implement script in both AVS with GSCript and AVS+ without [needs RT_FunctionExist()]
Where InstS = a multiline string.

IsAvsPlus=(FindStr(UCase(versionString),"AVISYNTH+")!=0) HasGScript=RT_FunctionExist("GScript")
Assert(IsAvsPlus || HasGScript,RT_String("%sNeed either GScript or AVS+",myName))
...
HasGScript ? GScript(InstS) : Eval(InstS) # Use GSCript if installed (loaded plugs override builtin)


EDIT:
Maybe GScript, GEval, and GImport, could be implemented as script functions (with some other names) and act based on
whether GScript dll or AVS+ present, GImport equivalent though might be tricky as I think the ScriptDir() type stuff changes
to the target directory of the imported file, probably not impossible to kludge around.

EDIT: If anybody wants complete listing of AVS+ r2728 BuiltIn function definitions, see SendSpace in sig below this post, or here:
http://www.mediafire.com/file/py89853bys1y3j1/AviSynth+_0.1_%28r2728_ORDERED_Function_List.TXT.7z [~5KB]
NOTE, Only a single definition for each function is available, eg AssumeFPS has multiple definitions, using float FPS, or int numerator, int denominator.
(Not sure if its the first or last definition that is produced by Avs API.)
The actual script to produce the list is included in RT_Stats (any recentish version, last 3 or 4 years).

[FranceBB]

I've been using Avisynth since 2006 and I've got many plugins in my Avisynth plugin directory.
Unfortunately, the development of Avisynth didin't really make any step forward for a while and even thought I have been able to use some sort of "workaround" to accomplish my tasks, time has come for me to move to Avisynth+.
I downloaded AviSynthPlus-MT-r2728-with-vc_redist.exe from Github (the latest Pinterf release).
I generally compile binaries myself, but I never used Avisynth+ so I wanted to download the official binaries.
I started the installation and it asked me whether I wanted to replace Avisynth or just "upgrade" and I clicked "upgrade".
It installed itself and also the C++ Redistributable 2017.

Unfortunately, I removed my old Avisynth plugin directory 'cause some of my old plugins make Avisynth+ crash.

So, I started adding them one by one until I found out which ones were breaking Avisynth+ and now it works.

I was kinda skeptical at the very beginning, but I tested it with a few simple scripts and I got very excited!
I mean, overall I find it faster than Avisynth 2.6.1 as it reacted immediately when I tried to preview results with AVSPmod and the syntax is basically identical, so I don't have to learn things from scratch, but just new functions! :D
I started to play with colorbars and test sources...
ConvertBit() is really useful, but what I found most exciting is that many internal filters are already capable to work at 10, 12, 14, 16bit and they are blazing fast!
I mean, I can simply use ConvertBit(10) and then use... I don't know... Tweak and Spline64Resize? Really? I don't have to Dither it up to 16bit stacked, use Dither functions and Dither it down to 10bit with Dither_Quantize, but I can work directly at 10bit if I want to? I know it sounds silly and easy to you, but it sounds really cool to me.
Besides, if I use FFMpegSource2 it will index the source and output it in its native Bitdepth... this is amazing!! It really is amazing, 'cause last time I had to compile ffms2 myself to include "enable10bithack=true".
I mean, again, it may sound silly to you but it sounds cool to me.
Avisynth+ also solved some nasty bug I have been dealing with for years...! Yes, for years...! Including some I reported but never got fixed in Avisynth 2.6.1... this is amazing!

I'm far too excited...
A big fat "thank you" to pinterf and to everybody who committed changes to the developing branch.

[Groucho2004]

Unfortunately, I removed my old Avisynth plugin directory 'cause some of my old plugins make Avisynth+ crash.

So, I started adding them one by one until I found out which ones were breaking Avisynth+ and now it works.
Any chance you could tell us which plugins "break" AVS+?

[manolito]

Alright, this seems to be the time when everybody is abandoning plain vanilla AviSynth, I probably also should take a closer look at AVS+, but I am still very reluctant to make this step.

My needs are probably a little different than the needs of many other folks, especially the folks on this forum, so I'd like to ask a few questions about the advantages I would get in my usual projects by switching to AVS+.

I do not care at all about high bit depths and hi color. Most of my projects are SD, either for DVD or for AVC/AAC output (only rarely in HD resolution). The most demanding conversions I sometimes do for other folks are BD structures or AVCHD files which play on a standard hardware BD player. And all these formats are 8-bit with 4:2:0 color subsampling.

So I believe that most of the newer AVS+ features are not needed for me. I also need ALL of my old AVS plugins to continue working, this includes some VDub filters. Is this a realistic expectation?

Next question is about multithreading. Is there any speed gain in AVS+ when using old single threaded plugins and just add the "prefetch" command to the end of my scripts?

And then the question about AVS+ stability. I am very conservative here, I have not much use for software which gets bug fix updates every couple of weeks. I prefer software which is stable and has an update frequency of no less than one year. From loosely following the related threads I got the impression that AVS+ as well as some important "modernized" plugins (like MaskTools and MVTools) are still work in progress and need frequent bug fix updates.


So after considering all these aspects I wonder if I should really switch to AVS+ yet. It may be inevitable at a later time, but it seems too early right now, at least for my needs...


Cheers
manolito

[FranceBB]

Any chance you could tell us which plugins "break" AVS+?

Only ancient 2.0 C plugins like InpaintFunc, a delogo I've been using for years, but there are alternatives, so I don't mind.

[Groucho2004]

Only ancient 2.0 C plugins like InpaintFunc, a delogo I've been using for years, but there are alternatives, so I don't mind.I see. When someone mentions 'break' or 'crash' I wouldn't assume that it's related to a feature simply not supported.

Anyway, I'm glad you like AVS+, I also find the ConvertBits() and ConvertToStacked() functions very useful.

[StainlessS]

Manolito,
FranceBB seems quite happy, (not surprisingly).
Any problems are quite rare and fixed almost immediately (no 6 month wait till next update), Pinterf dont hang about.
Avs+ is I think definitely faster than standard, and seems to swallow less amounts of memory, although neither of those
qualities have been benchmarked by me in any way, everything just feels better. (I'm still on XP32, mostly).
Its easy enough to switch versions, Groucho even does a fast switcher, I got it but have yet to try (easy enough to just switch without it).
The only irksome difference to v2.60/2.61, is the GScript thing, but that is easily overcome just by installing GScript dll and ignoring the Avs+ built in
Gscript parsing (loaded plugs override builtin). [GScript Thing, Avs+ dont like the surrounding GScript(""" ... """) stuff.]

However, you can avoid such difficulties using code in last code block in post #4144
(a few posts previous, requires RT_Stats though, not something that I have a problem with).

Give it a try, easy enough to switch back, but I'm guessin' that you will not be doing that, ever.

EDIT: Any problems/bugs that rarely occur are usually in new functionality, if you dont use it, you will not have to be a guinea pig.
EDIT: And if you is still on the ol' Vdub, then switch that too to VD2, another recentish 'fantabulism'.
EDIT: 'GSCript thing', I think (but am not sure) that you should be able to mix GScript(""" ... """) and unwrapped gscript code
even in same script when you have the Gscript dll installed. I'm currently modding all of my script to work with either GSCript or
avs+ without Gscript.