MaskTools2 - pfmod

[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

[pinterf]

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

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

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]

Originally Posted by real.finder

I think I get bug

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

will give

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]

Originally Posted by pinterf

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...ses/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]

Originally Posted by pinterf

New release: v2.2.20

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]

Originally Posted by FranceBB

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]

Originally Posted by l00t

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 then here 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...1eef22f0c7ae98

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]

Originally Posted by pinterf

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]

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

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


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