MaskTools2 - pfmod

[pinterf]

What is the error message?
From v2.2.17 the width and height (for each affected plane) is checked agains the size of the supplied parameters.
Lack of this kind of check resulted in sometimes crash, or for "luckier" run it only corrupted pixels and/or memory.
E.g. a clip with width=2 will have an error for a 3x3 convolution.
Note that if chroma is also processed, the subsampled size (e.g. width/2 for a YV12 chroma plane) should fulfill the size requirements as well.

[Tempter57]

"mt-convolution:Plane height should be at least the vertical element count"
With masktools2 v.2.2.16 no error
https://i108.fastpic.ru/thumb/2018/1208/d3/c6800a9624fe3ba632c47b67d43bffd3.jpeg (https://fastpic.ru/view/108/2018/1208/c6800a9624fe3ba632c47b67d43bffd3.jpg.html)
function BalanceBorders(clip c, int cTop, int cBottom, int cLeft, int cRight, int "thresh", int "blur")
{
Assert(isYV12(c), "This is not an YV12 clip. Convert color space to YV12 before using BalanceBorders().")

thresh = Default(thresh, 128)
blur = Default(blur, 999)

Assert(blur > 0, "Blur parameter in BalanceBorders() must be > 0")
Assert(thresh > 0, "Thresh parameter in BalanceBorders() must be > 0")

c
cTop >0 ? BalanceTopBorder(cTop, thresh, blur).TurnRight() : last.TurnRight()
cLeft >0 ? BalanceTopBorder(cLeft, thresh, blur).TurnRight() : last.TurnRight()
cBottom >0 ? BalanceTopBorder(cBottom, thresh, blur).TurnRight() : last.TurnRight()
cRight >0 ? BalanceTopBorder(cRight, thresh, blur).TurnRight() : last.TurnRight()
}

function BalanceTopBorder(clip c, int cTop, int "thresh", int "blur")
{
cWidth = c.width
cHeight = c.height
cTop = min(cTop,cHeight-1)
blurWidth = max(4,floor(cWidth/blur))

c2 = c.PointResize(cWidth*2,cHeight*2)

c2.\
Crop(0,cTop*2,cWidth*2,2)
PointResize(cWidth*2,cTop*2)
BilinearResize(blurWidth*2,cTop*2)
mt_convolution("1 1 1","0 1 0",y=3,u=3,v=3)
BilinearResize(cWidth*2,cTop*2)
referenceBlur = last

original = c2.Crop(0,0,cWidth*2,cTop*2)

original
BilinearResize(blurWidth*2,cTop*2)
mt_convolution("1 1 1","0 1 0",y=3,u=3,v=3)
BilinearResize(cWidth*2,cTop*2)
originalBlur = last

balanced = mt_lutXYZ(original,originalBlur,referenceBlur,"z y - x +",y=3,u=3,v=3)
difference = mt_makeDiff(balanced,original,y=3,u=3,v=3)

tp = string(128+thresh)
tm = string(128-thresh)
difference = difference.mt_lut("x "+tp+" > "+tp+" x ?",y=3,u=3,v=3)
difference = difference.mt_lut("x "+tm+" < "+tm+" x ?",y=3,u=3,v=3)

mt_addDiff(original,difference,y=3,u=3,v=3)

StackVertical(last,c2.Crop(0,cTop*2,cWidth*2,(cHeight-cTop)*2)).PointResize(cWidth,cHeight)
}

[DJATOM]

BalanceBorders is just an old script, I suggest you to try https://github.com/sekrit-twc/EdgeFixer. Write me into telegram, if you need x64 build.

[real.finder]

mod for BalanceBorders https://pastebin.com/sbpK1GGC

it work now and it support new color spaces, and some speed up in non plus old avs

[Tempter57]

real.finder & pinterf
Thank You :)

[StainlessS]

Hi P, is there some way to achieve this:-
All may not be lost.
I think that if we can convert encrypted 8 bit clip into 10 bit (with a shift so that bit 0 of encrypted is shifted to bit 1 of 10 bit clip, and both bits 0 and bit 9 of 10 bit clip now 0), and then encode
the 10 bit clip, we may get a better result. However, I have no idea how to convert to 10 bit by only shifting by 1 bit.
(I also have no idea how to do a straight forward convert to 10 bit, so some assistance required here).
EDIT: Reverse procedure restoring back to 8 bit before decrypt would also be necessary.
https://forum.doom9.org/showthread.php?p=1866138#post1866138

something like [EDIT: Below mixed bittage clips, first(K) 10 bit, 2nd(Last) 8 bit, want 10 bit result (same as 1st clip K)]

AviSource("D:\Parade.avi").GreyScale # 8 bit 490x360 YUV12
K=Last.ConvertBits(10).BlankClip # 10 bit 490x360 YUV420P10
Mt_lutxy(K,Last,Expr="y") # Ideally something like Expr="y 2 *" ie shift 8 bit clip over one bit, result 10 bit clip ......0xxxxxxxx0 where x are bits from 8 bit clip.

#info

Produces this
https://i.postimg.cc/PNbHtfkH/Test.jpg (https://postimg.cc/PNbHtfkH)

I'm totally new to non 8 bit stuff, and a bit thick :)

EDIT: This seems to construct the 10 bit encrypt/decrypt key ok

Function MakeRandomKeyClip(clip c,int Seed,int "Matrix") {
Return RandomSource(Length=c.FrameCount,Width=c.width,Height=c.Height,Seed=Seed)
\ .ConvertToPlanarRGB
\ .ConvertBits(10)
\ .ConvertToYUV420(Matrix=Default(Matrix,"rec601"))
}


EDIT: If not possible, perhaps Wonkey_Donkey has a suggestion :)

EDIT: Perhaps making Stacked 10 bit clip possible, then convert to non stacked.

EDIT: Not sure, but suspect we need a 7 bit shift if 10 bit colorspace occupies 10 most significant bits of 16 bit word.

EDIT: Think that the below does as we require.

Function EncryptPrep8To10(clip c,Bool "Shift") {
# Convert from 8 bit to 10 bit (Shift on luma only if it proves useful, doubtful)
c
Shift=Default(Shift,False)
Limiter() # Dump illegal values
StackVertical(Last,Last.Blankclip.Mt_lut("0")) # Stack16 16 bit
ConvertFromStacked(Last,16) # 16 bit Native
(Shift) ? Mt_Lut(Last,Yexpr="x 1 >>u",y=3,u=2,v=2) : NOP
ConvertBits(10)
}

Function DecryptPrep10To8bit(clip c,Bool "Shift") {
# Convert from 10 bit to 8 bit
c
Shift=Default(Shift,False)
ConvertBits(16) # Maybe this dont work as required
(Shift) ? Mt_Lut(Last,Yexpr="x 1 <<u",y=3,u=2,v=2) : NOP
ConvertToStacked
Crop(0,0,0,Height/2)
Limiter() # Dump illegal values
}

SHIFT=True # Experimental (probably of no use)
AMP=True # Amplifiy Difference

AviSource("D:\Parade.avi")
Limiter() # Dont let Limiter inside functions produce difference between in and out clips.

ORG=Last
EncryptPrep8To10(SHIFT)
DecryptPrep10To8bit(SHIFT)
D = Subtract(Last,ORG)
D = (AMP) ? D.Levels(126-20,1,126+20,16,235,coring=false) : D
StackVertical(StackHorizontal(ORG,D),StackHorizontal(Last,D))

[wonkey_monkey]

EDIT: If not possible, perhaps Wonkey_Donkey has a suggestion :)

I'm leaving >8 bit well alone until the day when you can ask three people a question about it and not get three different answers!

[pinterf]

Use Expr when you want to mix together different bit depths.
This one properly shifts luma by one.
AviSource("D:\Parade.avi").GreyScale # 8 bit 490x360 YUV12
K=Last.ConvertBits(10).BlankClip # 10 bit 490x360 YUV420P10
#Mt_lutxy(K,Last,Expr="y") # Ideally something like Expr="y 2 *" ie shift 8 bit clip over one bit, result 10 bit clip ......0xxxxxxxx0 where x are bits from 8 bit clip.
Expr(K,Last,"y 2 *","","")

ConvertBits for YUV works using bit shifts.
http://avisynth.nl/index.php/ConvertBits

Tha fact that masktools mt_lutxy does not check for similar input bit-depth is a bit annoying now (I was surprised on StainlessS' example giving me a vertical bar :) ). It cannot handle properly inputs with different bit depths, unlike Expr.

[pinterf]

EDIT: Not sure, but suspect we need a 7 bit shift if 10 bit colorspace occupies 10 most significant bits of 16 bit word.

Valid values for 10-12-14 bit color spaces always occupy the lower bits in Avisynth+.
http://avisynth.nl/index.php/D_Notation#A_note_on_notation
In other systems there are other formats e.g. P210, P216 (https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats) which are always on the 16 bit magnitude, but the 10 bit version having the six LSB set to 0. These formats are used by Avisynth, e.g. these type of fourCC codes can be negotiated by Avisource, but you, as a script writer will never see it because it will be converted to Avisynth's internal YUV422P10 and YUV422P16 format.

[StainlessS]

Thanks very much Pinterf, guess I gots lots and lots to read up on.

Guess I havta try out Expr, I thought that Masktools now supported mixed bittage, I musta mixed it up with Expr().

The fact that masktools mt_lutxy does not check for similar input bit-depth is a bit annoying
I see it as my purpose in life to annoy the hell out of you :)

All of these weird colorspace/bittage formats seem awfully complicated, I think I'll go to bed.

[Dogway]

I might have dull day, but the next doesn't work for me:

mt_lut(mt_polish("abs(-40)"),u=-128,v=-128)

Looks like an issue with mt_polish and abs()

Same with pow(), the next example renders black.

mt_lut("x 1 pow",u=-128,v=-128)

[wonkey_monkey]

What's the result of

subtitle(mt_polish("abs(-40)"))

?

[Dogway]

The result is "a"

and

subtitle(mt_polish("pow(x,1)"))

doesn't output anything

Ok, it uses the ^ operator not the pow() function. The abs() issue still intrigues me.

[pinterf]

Use ^ instead of pow
http://avisynth.nl/index.php/MaskTools2

[Dogway]

Making a vignette function but something is not right.

strength = string(2.0)
w=string(width(last))
h=string(height(last))
a=mt_lutspa( last, mode = "absolute", expr = " x "+w+" 2 / - abs "+w+" 2 / / 255 * "+strength+" ^ 255 / 0 max", chroma = "-128" )
b=mt_lutspa( last, mode = "absolute", expr = " y "+h+" 2 / - abs "+w+" 2 / / 255 * "+strength+" ^ 255 / 0 max", chroma = "-128" )
c=mt_lutxy(a,b,"x y + 2 / 255 - abs")
c

This might be better, normalized to 0,1
strength = string(0.75) # range 0,1
w=string(width(last))
h=string(height(last))
a=mt_lutspa( last, mode = "absolute", expr = " x "+w+" 2 / - abs "+w+" 2 / / 255 * 1.5 "+strength+" 2 / + ^ 255 / 0 max", chroma = "-128" )
b=mt_lutspa( last, mode = "absolute", expr = " y "+h+" 2 / - abs "+w+" 2 / / 255 * 1.5 "+strength+" 2 / + ^ 255 / 0 max", chroma = "-128" )
c=mt_lutxy(a,b,"x y + 255 - abs")
c

[pinterf]

You can find some mt_lutspa examples here:
http://avisynth.nl/index.php/MaskTools2/mt_lutspa

or use sx, sy, sxr and syr in "Expr" (Avisynth+ only)
http://avisynth.nl/index.php/Expr

[Dogway]

Thanks, great examples there. I forgot Expr, still with the old avisynth mindset.
Could you confirm the mt_polish bug with abs()?

[StainlessS]

I just installed Avisynth for this test,

BlankClip(pixel_type="YV12") # added

strength = string(0.75) # range 0,1
w=string(width(last))
h=string(height(last))
a=mt_lutspa( last, mode = "absolute", expr = " x "+w+" 2 / - abs "+w+" 2 / / 255 * 1.5 "+strength+" 2 / + ^ 255 / 0 max", chroma = "-128" )
b=mt_lutspa( last, mode = "absolute", expr = " y "+h+" 2 / - abs "+w+" 2 / / 255 * 1.5 "+strength+" 2 / + ^ 255 / 0 max", chroma = "-128" )
c=mt_lutxy(a,b,"x y + 255 - abs")
c


Gets me this (no idea if correct, have not dissected expr).
https://i.postimg.cc/SsLBVJMc/Dogway.jpg (https://postimages.org/)

Looks like it might be as intended.

EDIT: During testing, suggest use RT_Stats RT_DebugF() to show result expr (and perhaps infix equivalent too [check if RPN parses OK]).

EDIT: eg

BlankClip(pixel_type="YV12")

strength = string(0.75) # range 0,1
w=string(width(last))
h=string(height(last))

RPN_X = " x "+w+" 2 / - abs "+w+" 2 / / 255 * 1.5 "+strength+" 2 / + ^ 255 / 0 max"
RPN_Y = " y "+h+" 2 / - abs "+w+" 2 / / 255 * 1.5 "+strength+" 2 / + ^ 255 / 0 max"

INFIX_X=Mt_Infix(RPN_X)
INFIX_Y=Mt_Infix(RPN_Y)

myName="DoggyDoo: "

RT_DebugF("DBGVIEWCLEAR") # Clear DebugView window (thanx Wonkey Donkey)

RT_DebugF("RPN_X = '%s'",RPN_X,name=myName)
RT_DebugF("RPN_Y = '%s'",RPN_Y,name=myName)

RT_DebugF("INFIX_X = '%s'",INFIX_X,name=myName)
RT_DebugF("INFIX_Y = '%s'",INFIX_Y,name=myName)

a=mt_lutspa( last, mode = "absolute", expr = RPN_X, chroma = "-128" )
b=mt_lutspa( last, mode = "absolute", expr = RPN_Y, chroma = "-128" )
c=mt_lutxy(a,b,"x y + 255 - abs")
c

EDIT: Is above 'w' in RED correct ?


00000074 0.00000000 [2176] DoggyDoo: RPN_X = ' x 640 2 / - abs 640 2 / / 255 * 1.5 0.750000 2 / + ^ 255 / 0 max'
00000075 0.00006196 [2176] DoggyDoo: RPN_Y = ' y 480 2 / - abs 640 2 / / 255 * 1.5 0.750000 2 / + ^ 255 / 0 max'
00000076 0.00012101 [2176] DoggyDoo: INFIX_X = 'max(((((abs((x-(640/2)))/(640/2))*255)^(1.5+(0.750000/2)))/255),0)'
00000077 0.00017681 [2176] DoggyDoo: INFIX_Y = 'max(((((abs((y-(480/2)))/(640/2))*255)^(1.5+(0.750000/2)))/255),0)'

[Dogway]

Useful to grab plain text result of mt_polish() (or infix)
The mask is in PC levels but I ported the functions to avs+ internal Expr and added an option to merge with source in TV levels.
Still a few things might improve since I don't understand well the scale_inputs setting.

function Vignette(clip c, float "Vignette", bool "show") {

strength = string(default(Vignette, 0.7))
show = Default(show, false)

a=expr( c, " sx width 2 / - abs width 2 / / 255 * 1.5 "+strength+" 2 / + ^ 255 / 0 max", "","", scale_inputs = "allf" )
b=expr( c, " sy height 2 / - abs width 2 / / 255 * 1.5 "+strength+" 2 / + ^ 255 / 0 max", "","", scale_inputs = "allf" )

msk=expr(a,b,"x y + 255 - abs", "128","128", scale_inputs = "allf" )
msktv=msk.expr("x 128 - 224 * 255 / 128 +", scale_inputs = "allf" )


show ? msk : expr(msktv,c,"x 16 - y 16 - * 220 / 1 * x 16 - 1 1 - * + 16 + ", "y", "y", scale_inputs = "all" )

}

[StainlessS]

Dogways see RED edit in prev post.

Also, can eg calc WD2 = W / 2 in script instead of masktools. Guess if using relative mode, can just use 0.5 instead.

[Dogway]

The lens is a fixed circle, so it must keep the lens geometry otherwise we get an oval. When shooting square the corners are not black so the maths can be improved, and specially to deal with bitdepth and scale_inputs parameter.

[StainlessS]

Thanks, that clarifies it (thought I had better mention it in case a typo).

Could you confirm the mt_polish bug with abs()?
Is the shape posted as expected ? (ie abs is working OK).

EDIT: I think real.finder is the only scriptor that understands all that bitdepth and scale_input stuff, and he's way too busy to assist here :devil:

[pinterf]

I might have dull day, but the next doesn't work for me:
mt_lut(mt_polish("abs(-40)"),u=-128,v=-128)
Looks like an issue with mt_polish and abs()

Yep, tokens beginning with 'a' and 'y' were not recognized. (abs, atan, ymin, ymax). Fixed on git, no release yet.

[real.finder]

I think I get bug

MessageClip(mt_infix("x range_half - range_half * 112 scaleb / range_half +"))

will give https://i.imgur.com/XUH9rlf.jpg

and aside from that, the float (32bit) chroma scale in Dither_Luma_Rebuild seems broke since the zero-chroma-center transition, I think most if not all scripts that has chroma lut/expr was also affected and they need review

[pinterf]

I think I get bug

MessageClip(mt_infix("x range_half - range_half * 112 scaleb / range_half +"))

will give https://i.imgur.com/XUH9rlf.jpg

and aside from that, the float (32bit) chroma scale in Dither_Luma_Rebuild seems broke since the zero-chroma-center transition, I think most if not all scripts that has chroma lut/expr was also affected and they need review
I think scaleb(112) is the proper syntax here, scaleb works here as a function.
EDIT: I wonder whether mt_infix handles all the newer stuffs properly.
EDIT: Fixed on git, no release yet.

[real.finder]

I think scaleb(112) is the proper syntax here, scaleb works here as a function.
EDIT: I wonder whether mt_infix handles all the newer stuffs properly.
EDIT: Fixed on git, no release yet.

thanks, I send you pm :)

[real.finder]

another case for mt_infix

x range_half - dup * dup y range_half - dup * + / range_max *

seems mt_infix not handle dup, maybe mt_polish too

[pinterf]

Yes, dup is a newer addition, technically it's like reusing an existing short or compex expression using a temporary variable (not 100% but somethong like this)
I think this syntax conversion is beyond my_infix functionality.
var1 = (x - range_half)
var2 = var1 * var1
var3 = y - range_half
(var3 * var3 + var2) / var1 * range_max
The same applyes for the opposite conversion case, repeating expression patterns should be recognized somehow and replaced with dup?

[real.finder]

is there bitdepth scale in mt_lutf, mt_luts, mt_lutsx and mt_lutspa? they should has at least scale_inputs

[pinterf]

New release: v2.2.20

https://github.com/pinterf/masktools/releases/tag/2.2.20

Minor fixes, lut expression syntax additions just like in Avisynth+ 3.5

Now with both Microsoft and ClangCL (LLVM 9.0) versions inside.

Changelog
**v2.2.20 (20200303)
- new "yscalef" and "yscaleb" keywords similar to "scalef" and "scaleb" but scaling is forced to use rules for Y (non-UV) planes
- mt_lutspa: add parameters "scale_inputs", "clamp_float" and "clamp_float_UV"
- new predefined constants in expressions: yrange_min, yrange_half, yrange_max
Unlike range_min, range_half, range_max the y-prefixed versions do not depend on whether the currently
processed plane is luma(Y) or chroma(U/V). They are always returning the values of Y plane.
- new parameter to lut functions: Boolean "clamp_float_UV": default false, as an addition to clamp_float (since v2.2.20).
- New: Parameter "scale_inputs" can now be set to "floatUV" (chroma pre-shift by 0.5 for 32 bit float pixels)
- Fix: mt_motion mask contained out-of range pixels for 10-14 bit inputs
- Fix: mt_edge convolution mode incorrect result on 10-32 bits when normalizer weight is not power of 2
e.g. mode = "1 2 1 0 0 0 -1 -2 -1 15.0" (normalizer: 10th parameter or maximum of (sum_positive/sum_negative))
Note: when processing chroma (u=3,v=3) on 32 bit float clip will result 0..1.0 ranged masks in chroma planes as well.
- Source:
- add LLVM-clangCl to VC project configuration (built-in clang support in VS2019)
- fix LLVM build for VS2019
- silence many warnings
- project configurations: use current SDK version 10.0.18362.0

**v2.2.19 (20190710 - not released)
- Fix: mt_infix to recognize scaleb and scalef
- Fix: mt_infix to recognize ymin, ymax, abs, atan, etc... tokens beginning with 'a' and 'y' were not converted
- Move project to VS2019 v142 toolset, xp builds still at v141_xp
- update current Avisynth+ headers
- update source to use boost 1.70 lib v142 for non-xp builds

[StainlessS]

OOOooooooh, its just like Christmas, thanx :)

[real.finder]

New release: v2.2.20


:thanks: but why "with_dual_filter_signatures" has no Clang? :)

[pinterf]

The project doesn't have such configuration. Way too much version even at present state. I was even considering dropping those dual config versions.

[FranceBB]

Thank you for the new release! And yes, I'm one of those people using the dll "with_dual_filter_signatures".

Move project to VS2019 v142 toolset, xp builds still at v141_xp

Thank you for still building targeting the v141_xp with C++ Redistributable 2019, I appreciate that. :)

[pinterf]

Thank you for the new release! And yes, I'm one of those people using the dll "with_dual_filter_signatures".



Thank you for still building targeting the v141_xp with C++ Redistributable 2019, I appreciate that. :)
You're welcome.

I wonder why are you using dual signature versions?

[l00t]

n00b question here: what is "with_dual_filter_signatures" and how does it differ from the normal versions?

[real.finder]

n00b question here: what is "with_dual_filter_signatures" and how does it differ from the normal versions?

it's here to avoid this kind of problems here (https://forum.doom9.org/showthread.php?p=1800152#post1800152) then here (https://forum.doom9.org/showthread.php?p=1800467) it will happen in any non avs 2.5 color format like Y8 and YV16 not only avs+ HBD

if you has 2.5 masktools it will be used instead of new one in these cases cuz new masktools use float in many parameters since HBD so with "with_dual_filter_signatures" it has both float and int so it's fix the problem

so maybe instead of remove with_dual_filter_signatures it's better to make it the main one :)

from pinterf in PM when I discussed the problem with him

Aaaaah.
Everyone is right.

1.) Avisynth is choosing the best matching parameter list for the call.
In our tests, we were feeding integers for the parameters. The best match was the old masktools2 function.
Try it with 155.0 instead of 155 and feel the difference.

2.) But there is another problem.
When someone wants to use the functions with a parameter list without the names,
e.g. mt_binarize(clip,80,"0 255",3,1,1), it won't work anymore. Parameters Y, U and V and the others are shifted in the parameter sequence.

For example this is the function signature of the new mt_binarize:
"c[threshold]f[upper]b[mode]s[stacked]b[paramscale]s[Y]f[U]f[V]f[chroma]s[offX]i[offY]i[w]i[h]i[sse2]b[sse3]b[ssse3]b[sse4]b[avx]b[avx2]b"

This needs a bit more serious workaround because tp7 made the function signatures automagically assembled from
- filter specific (as seen above, c[threshold]f[upper]b[mode]s[stacked]b[paramscale]s)
- common (starting with Y, U, V, etc)

If I want to keep the compatibility, I have to "flag" the new extra parameters of all filters, thus tp7's filter definition would work from 3 sources:
- filter specific (old, like c[threshold]f[upper]b[mode])
- common
- filter specific (new, like [stacked]b[paramscale]s)

3.) Plus, because of your original problem (best parameter type match), perhaps I have to double the definitions, one for integer only parameters, and one for the float-type.


after that, the fix should be in changes log
- dual interface int and float parameter list (autoload problem)

edit: here it is https://github.com/pinterf/masktools/commit/d67aecaf985a3db229cc47300d1eef22f0c7ae98

edit2: at least with mvtools2 after update limit to float SMDegrain limit parameter seems work fine even if there no dual interface, I think it because it use it as limit=limit

[FranceBB]

You're welcome.

I wonder why are you using dual signature versions?

Although on my machine I have the very latest build of Avisynth+ on both XP and Win10, I sneaked a series of portable installation at work long before they accepted to let me (and my colleagues) use Avisynth officially. It was on C:\Encoding\ and it was using a series of commands to call Avisynth and encode some 8bit MPEG-2 files. It was years ago, way before StainlessS convinced me to switch to Avisynth+, so I don't remember whether I deployed Avisynth 2.5.8 or 2.6.0 to each and every machine along with my collection of plugins; all my workflows were either 8bit or 16bit stacked/interleaved back then. Today, all the installation I officially make within the company are running Avisynth+ but I kinda lost track of the first "sneaky" ones (but I'm pretty sure they are still used by someone somewhere), so I keep my plugins as compatible as possible so that if people copy the plugin folder from another official machine running AVS+ (and I know they do it every once in a while) they don't get weird errors and they don't break workflows, especially 'cause most of them are automatized. It's funny how complicated it is for some company to simply accept that open source software is better and more reliable than crappy and expensive professional one... One day I'll tell you the story of how I "brought" Avisynth into one of the leading TV company and how hard it was for them to accept it...

[real.finder]

Yes, dup is a newer addition, technically it's like reusing an existing short or compex expression using a temporary variable (not 100% but somethong like this)
I think this syntax conversion is beyond my_infix functionality.
var1 = (x - range_half)
var2 = var1 * var1
var3 = y - range_half
(var3 * var3 + var2) / var1 * range_max
The same applyes for the opposite conversion case, repeating expression patterns should be recognized somehow and replaced with dup?

what is the best one? since this problem didn't fix yet :)

also seems the scaling parameter didn't work well in this case with chroma float

ColorBars(width=640, height=480, pixel_type="yv12")
convertbits(32)
mt_binarize(threshold=128, U=3, V=3)

also mt_binarize is like mt_edge that should give 0..1.0 ranged for chroma

edit: seems mt_binarize need 0..1.0 ranged for chroma
ColorBars(width=640, height=480, pixel_type="yv12")
convertbits(32)
mt_lut("x 0.5 +",y=2, U=3, V=3)
mt_binarize(threshold=128, U=3, V=3)
mt_lut("x 0.5 -", y=2,U=3, V=3)
now it's work

so I think it's not a bug since it's should be used with masked clip

[DanilaZabiaka]

Listen, I dont understand your development

WTF is masktools2? It's useful for 60FPS

Can it be processed in real time? Yes, using SVP

Can SVP be free? Yeah, I ported to Uplavnyalka this https://forum.doom9.org/showthread.php?t=180656

What is SVP? Its mvtools+render plugin

And this plugin can be friendly with mvtools as I know

May be you can friend this with svpflow2 and give people simple presets?

Its how ported svp (Uplavnyalka) 'gui' looks like
http://i.prntscr.com/wSiy7yy9TUuEzx0F9A35Vw.png

PotPlayer developer integrated avisynth from ffdshow to this project, why people cant do this too? Or rewrite analogue of render plugin?

[sl1pkn07]

Hi

any plans for make the filter linux avs+ compatible?

greetings

[pinterf]

Hi

any plans for make the filter linux avs+ compatible?

greetings
Yes, and all the others (mvtools, rgtools, etc) as well. I'll start with a simple one for experimenting. In general it takes two phases, first to make the source gcc (and clang) friendly, then the port itself.

[pinterf]

Listen, I dont understand your development

WTF is masktools2? It's useful for 60FPS


Thank you for your kind interest in masktools2.

[DanilaZabiaka]

imho coders code not for users, but just for code. no simple solutions, but complex, NEW, etc. fuh

[pinterf]

masktools functionality and optimization level is everything but not simple. Along with mvtools they are of the most complex filters I met. Feel free to rewrite the whole filter group to a more simple and hyper user friendly one. Spend months of your free time with it. Or better: plan and build your own CPU to reach your magic 60 FPS. But wait, no, hardware engineers work not for users and create too complex things.

[DJATOM]

Don't mind him, apparently Daniil is just unmanner guy who makes ridiculous insults towards forum users :(

[Music Fan]

Hi,
I just re-installed Avisynth+ 32 bit (3.5.1), I selected the masktools2 dll (2.2.20) from the x86 folder, put it in the C:\Program Files (x86)\AviSynth+\plugins+ folder but when I open my script, I get the error message "no function named ylevels".:o
I also tried in the plugins folder, same result.

I had installed this Visual C++ and Visual Studio package ;
https://github.com/abbodi1406/vcredist/releases
I was told (in the AVS+ topic) that it contained everything useful for Avisynth when we don't install the vcredist version, what am I doing wrong ?


edit : that's ok now, I forgot the YLevels_mt avsi :rolleyes:

[real.finder]

I was adding HBD to http://avisynth.nl/index.php/Hysteria

Convertbits(16)
noisymask = mt_edge(thy1=6,thy2=6,mode="cartoon")
cleanmask = mt_edge(thy1=20,thy2=20,mode="cartoon")
mt_hysteresis(cleanmask,noisymask).mt_inflate().Blur(1.0).Blur(1.0).mt_deflate()

these not give same output as 8bit, with 32 it's worst, bug in mt_hysteresis?

[pinterf]

If you say, probably yes :) Should be the same, isn't it?

[real.finder]

If you say, probably yes :) Should be the same, isn't it?

yes, it should, maybe paramscale in mt_hysteresis not work correctly?