MaskTools2 - pfmod

[pinterf]

mt_hysteresis fixed.

Download masktools v2.2.21
https://github.com/pinterf/masktools/releases/tag/2.2.21

[real.finder]

mt_hysteresis fixed.

Download masktools v2.2.21
https://github.com/pinterf/masktools/releases/tag/2.2.21

yes, it work now :thanks:

[StainlessS]

Oops, originally posted in Mv Tools thread.

Gavino reported an infix ternary conditional Mt_Polish bug back in 2014, nobody ever seems to have taken a blind bit of notice of it.

2014: https://forum.doom9.org/showthread.php?p=1666933#post1666933
2017: https://forum.doom9.org/showthread.php?p=1814483#post1814483

mt_polish parses nested conditionals incorrectly

For example,
mt_polish("x > 128 ? 255 : x > 64 ? 128 : 0")
produces
x 128 > 255 x 64 > ? 128 0 ?
instead of
x 128 > 255 x 64 > 128 0 ? ?

It can be worked round by putting the inner conditional in parentheses
mt_polish("x > 128 ? 255 : (x > 64 ? 128 : 0)")
but this should not be necessary.

Test script:
BlankClip(pixel_type="YV12")
Subtitle(mt_polish("x > 128 ? 255 : x > 64 ? 128 : 0"))
Subtitle(mt_polish("x > 128 ? 255 : (x > 64 ? 128 : 0)"), y=30)





BlankClip(pixel_type="YV12")

aInfix = "x > 128 ? 255 : x > 64 ? 128 : 0"
aRpn = mt_polish(aInfix)
aInfix2 = mt_Infix(aRpn)

Subtitle("aInfix = "+ aInfix, y=10)
Subtitle("aRpn = "+ aRpn, y=30)
Subtitle("aInfix2 = "+ aInfix2, y=50)
astripped="((x>128) ? 255 : (x>64)) ? 128 : 0"
Subtitle("aInfix2 = "+ astripped + " ##### STRIPPED #####", y=70)

bInfix = "x > 128 ? 255 : (x > 64 ? 128 : 0)"
bRpn = mt_polish(bInfix)
bInfix2 = mt_Infix(bRpn)

Subtitle("bInfix = "+ bInfix, y=100)
Subtitle("bRpn = "+ bRpn, y=120)
Subtitle("bInfix2 = "+ bInfix2, y=140)
bstripped="(x>128) ? 255 : ((x>64) ? 128 : 0)"
Subtitle("bInfix2 = "+ bstripped + " ##### STRIPPED #####", y=160)

return last

https://i.postimg.cc/SRw9d5rx/Ternary.jpg (https://postimages.org/)

I tend to use the 'b' infix version with extra parenthesis, so that it works as Avs script [as per Gavino suggestion fix].

[pinterf]

"A small step for a ternary operator but a giant leap for mt_polish" edition :)
Download masktools2 2.2.23
https://github.com/pinterf/masktools/releases/tag/2.2.23
**v2.2.23 (20200513)
- fix mt_polish for nested ternary operators

**v2.2.22 (20200422)

Add AVX2 to mt_expand and mt_inpand 10-16 bit processing
Add Avisynth+ interface V8 frame property copy support (test)

**v2.2.21 (20200410)

fix mt_hysteresis for 10-32 bits

[StainlessS]

A giant leap indeed, this one aint sitting in my in-box at all, thanks very much, great stuff :)

EDIT:
Lovely [one great big pain in the bum removed].
https://i.postimg.cc/05TsSwKC/Ternary.jpg (https://postimages.org/)

EDIT: @ Big G, finally got it fixed, YippEEEEE!!!

[FranceBB]

Another step forward. Thank you, as always! :)

[`Orum]

I moved my encoding/filtering machine to Linux, and I've been trying to get this filter to run under wine. But, so far, every attempt has ended in failure. Has anyone managed to do so, and if so, how did you manage to get it to work? This is the only filter that I use frequently (as it's used in so many other filters) that doesn't seem to want to work in that environment.

I saw your other comment regarding mvtools, rgtools, etc., which already both seem to run just fine within wine, at least for me. Is this the last filter remaining?

Alternatively, if there's anything I can do to help get it to run under Linux, let me know. I'm no expert at getting things to work under wine (and struggling to get my own filters to play nice with it), but even if it's only testing, I'm more than willing to assist.

[FranceBB]

I moved my encoding/filtering machine to Linux, and I've been trying to get this filter to run under wine. But, so far, every attempt has ended in failure. Has anyone managed to do so, and if so, how did you manage to get it to work? This is the only filter that I use frequently (as it's used in so many other filters) that doesn't seem to want to work in that environment.

I saw your other comment regarding mvtools, rgtools, etc., which already both seem to run just fine within wine, at least for me. Is this the last filter remaining?

Alternatively, if there's anything I can do to help get it to run under Linux, let me know. I'm no expert at getting things to work under wine (and struggling to get my own filters to play nice with it), but even if it's only testing, I'm more than willing to assist.

I have Linux too (Fedora) but instead of Wine I use a Windows VM when I'm too lazy to reboot into Windows.
What I can say, though, is that Wine is expected to have the same compatibility as Windows XP and MaskTools2 Pinterf Mod work absolutely fine on XP so they should work in Wine.
Are you using Avisynth x86 under Wine? Did you try with the XP build of MaskTools2?

[`Orum]

I use a Windows VM when I'm too lazy to reboot into Windows.
Same; that's how I was able to narrow it down to a problem with MT2 specifically.
Wine is expected to have the same compatibility as Windows XP and MaskTools2 Pinterf Mod work absolutely fine on XP so they should work in Wine.
Wine doesn't have 100% perfect compatibility with any version of Windows to my knowledge.
Are you using Avisynth x86 under Wine? Did you try with the XP build of MaskTools2?
I'm using the 64-bit version of AviSynth+, as some of my filters are 64-bit only. I have not yet tested the XP builds, but if that's more compatible I'll definitely give it a shot. Do you know if Wine needs to be configured for XP compatibility as well, or can it remain configured for later versions of Windows?

Edit: Both the XP and Clang builds seem to work well under Wine. The Clang build is about 2% faster than the XP build when tested with lsfmod. Thanks!

[pinterf]

I love when things get resolved without me :)
Wine is not a perfect emulator, once I had to do something (some input local-aware stuff?) differently in Avisynth core because it misbehaved under wine.

[DJATOM]

I still can remember times when I had to split script to 4 parts and render them into y4m on Xeon X3330, as that was my working PC and I didn't allowed to install Windows on it. So I've used Wine + avs 2.5 ST (2.6 ST later) and filtered animes in lossless files (no one ever caught me). Later I've bought own 4 cores PC, but Avs+ evolved to being MT friendly at those times.

[real.finder]

I think I find bug

ColorBars()
ConvertToY8
mt_Convolution("1","50 99 50",U=3,V=3)

it crash

[pinterf]

I think I find bug

ColorBars()
ConvertToY8
mt_Convolution("1","50 99 50",U=3,V=3)

it crash
Check if this (https://drive.google.com/file/d/1PCR118_Vx_Au-IGIAFtKZFd8SkcSrTLb/view?usp=sharing) works (Stupid request, I know that it works, but I still wait a bit longer on your feedback that it functions normally with other filters; you use filters more frequently than I do)

[real.finder]

Check if this (https://drive.google.com/file/d/1PCR118_Vx_Au-IGIAFtKZFd8SkcSrTLb/view?usp=sharing) works (Stupid request, I know that it works, but I still wait a bit longer on your feedback that it functions normally with other filters; you use filters more frequently than I do)

it seems work fine, thanks

[real.finder]

since you didn't release it yet, is this (https://forum.doom9.org/showpost.php?p=1879768&postcount=328) forgotten? also swap

maybe adding support for dupN and swapN like expr will be a good thing since I plan to take some expr/lut improvements from vs ported scripts

[pinterf]

since you didn't release it yet, is this (https://forum.doom9.org/showpost.php?p=1879768&postcount=328) forgotten? also swap
ported scripts
What do you mean? Support them in infix/polish helper functions?


maybe adding support for dupN and swapN like expr will be a good thing since I plan to take some expr/lut improvements from vs ported scripts
Expr already has them. I'd rather continue implementing real lut functions in Avisynth.

[pinterf]

since you didn't release it yet
v24 released (https://github.com/pinterf/masktools/releases)
**v2.2.24 (20200619)
- fix: mt_convolution divbyzero when greyscale + forced U=3,V=3 (process chroma)

[real.finder]

What do you mean? Support them in infix/polish helper functions?

yes


Expr already has them. I'd rather continue implementing real lut functions in Avisynth.

I know Expr has them, but I mean for MaskTools2

[FranceBB]

v24 released (https://github.com/pinterf/masktools/releases)
**v2.2.24 (20200619)
- fix: mt_convolution divbyzero when greyscale + forced U=3,V=3 (process chroma)

It's always good when you wake up, you have your breakfast, you get to work and you find out that Ferenc just published a new version of Masktools :D
Thank you.

[real.finder]

I find another bug

colorbars()
converttoyv12
convertbits(32)
mt_edge(thY1=0,thY2=255,mode="min/max",U=1,V=1)
convertbits(8)

it crash

[GMJCZP]

When I use the x86 Clang version I get the following error message un VDub2:

"Error reading source frame 0: Avisynth read error: CAVIStreamSynth: System exception - Illegal Instruction at 0x0560DAD0"

When I use the x86 only version everything works fine, I am using the neo_f3kdb Clang version without problems

[pinterf]

Sse4.1? Maybe my clang builds need it.

[GMJCZP]

Sse4.1? Maybe my clang builds need it.

I have e5800 CPU, no sse4 instructions capable.

[pinterf]

I see. Then you should use msvc builds. And next time I have to document this prequisite.

[GMJCZP]

Out of curiosity, why does the Clang version of neo_f3kdb work for me, for example?

[pinterf]

Out of curiosity, why does the Clang version of neo_f3kdb work for me, for example?
Because masktools as a whole is sse4.1 compiled when clang (or gcc) is used. The source is full of common sse2/sse4.1 parts which work under msvc for a simple SSE2 build but for clang such source parts must be separated one by one into a sse2 and a sse4.1 version (and apply on them different function attributes sse2 or sse4.1).

This procedure is painful, takes way too much time, yields nothing in 2020-21, and increases source complexity. Plus I though that SSE4.1 is so rare nowadays (even non-AVX2 processors are rare in my opinion - we are talking about video processing).

There are positive examples as well: because of gcc (linux build in mind) I had to do this separation in Avisynth core. sse2, ssse3, sse4.1. I've done this separation for my other easier to touch filters as well.
If I remember well, nor mvtools2 can be compiled with plain sse2 option when clang is used - it is a similar monster like masktools2. Brrr.

[GMJCZP]

I am not an expert in compilations but I am aware that you have had many difficulties in optimizing masktools and mvtools, they are monsters with many heads and I personally appreciate your efforts.

[pinterf]

Compiling with clang/gcc is not any more difficult as with msvc but they are a bit more picky in this 'processor architecture' aspect. Unfortunately the code which was accepted by msvc (and historically old code meant to be Visual c++ only) must be reorganized for these cases which is usually done when a specific code part really have to be touched for some other reasons.

[real.finder]

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

it has new yfmin, yfmax, cfmin and cfmax keywords

masktools with same new keywords https://www.solidfiles.com/v/vNBW52KnQrwxn

x64 only and for test only

[MysteryX]

It would be great to see filters like this written for both Avisynth and VapourSynth like I did here (https://forum.doom9.org/showthread.php?t=182961).

It's really not that difficult to detach most of the complex code-base from both environments, and then just write function registrations and few platform-specific tasks for each.

Plus taking OUT any of the complexity of Avisynth (like the way it deals with plane indexes) out of the complex code-base makes it simpler.

I'm trying to port some code to VapourSynth; and it seems to be lacking in terms of masks management.

[MysteryX]

I'll update that most of the MaskTools2 functions have equivalents in VapourSynth, and I listed them here (https://forum.doom9.org/showthread.php?t=182989).

Remains the fact that libraries could easily be written to work on both platforms with just a bit of code abstraction.

[Dogway]

I don't know whether this is a bug or not or if this was always the case (I'm trying to port an old script), but for shapes in masktools2 when zero=false it automatically changes to a plus kernel instead of the original kernel and a hole in the center (the 0,0 pixel), is this by design?

[pinterf]

I don't know whether this is a bug or not or if this was always the case (I'm trying to port an old script), but for shapes in masktools2 when zero=false it automatically changes to a plus kernel instead of the original kernel and a hole in the center (the 0,0 pixel), is this by design?
Just looking into the source code I found no reason for this behaviour, I'd need a demo script that proves that.

[kedautinh12]

Hi @pinterf, long time to see you. Can you explain here about arrays for 2 people here :D
https://forum.doom9.org/showthread.php?p=1949689#post1949689

[pinterf]

Hi @pinterf, long time to see you. Can you explain here about arrays for 2 people here :D
https://forum.doom9.org/showthread.php?p=1949689#post1949689
Is this masktools topic or a messageboard?

[Reel.Deel]

Hi pinterf,

I think I found 2 bugs in MaskTools:

1) It seems that mt_merge always processes the chroma channels when luma=true. I don't know if this is the intended behavior but I would think the chroma/u/v parameters would have priority. You can see what I'm talking about by setting luma to true/false in the test script.

2) Access violation when chroma is processed and mask does not have enough planes; with luma=true it does not happen.


base = Blankclip(color=$FFFFFF, pixel_type="RGBP8")
base2 = Blankclip(color_yuv=$FFFFFF, pixel_type="YUV444P8")
over = Colorbars(pixel_type="RGBP8")
over2 = Colorbars(pixel_type="YUV444P8")
mask = Blankclip(color=$000000, pixel_type="RGBP8").Subtitle("AviSynth", size=150, align=5)
masky = mask.ShowRed("Y8")
mask2 = YToUV(masky,masky,masky)

#RGB
#mt_merge(base, over, mask, chroma="copy", luma=true)

#YUV
mt_merge(base2, over2, mask2, chroma="copy", luma=true)

# Avisynth read error: CAVIStreamSynth: System exception - Access Violation at 0x00000000251D8C90
#mt_merge(base2, over2, masky, chroma="process", luma=false)


--------

Is this masktools topic or a messageboard?

Did you not hear the news?.... this is kedautinh's message board now :D

[Dogway]

Just looking into the source code I found no reason for this behaviour, I'd need a demo script that proves that.

Here's a test script. You can change mt_square() with the other shapes as well.

BlankClip(width=640, height=480, pixel_type="YV12")
manyPlus_Pattern("dirac")
mt_luts( last, mode = "max", pixels = mt_square( 3, zero=false ), expr ="y" )

[Dogway]

Maybe someone can help me because I'm unable to properly read the mt_luts() source (https://github.com/pinterf/masktools/blob/16bit/masktools/filters/lut/functions.h). I'm having issues when 2 different clips are supplied, in the case of modes "max", "min" it looks as if the second clip is supplied twice "mt_luts(b,b,.....)", so no difference with "mt_luts(a,b,.....)". EDIT: looks like a known bug (https://forum.doom9.org/showthread.php?p=1637985#post1637985).

In the case of median, I'm unable to reproduce the behaviour.

Taking as an example the following call (square without the center pixel)
MT_Luts(C, C.removegrain(12), mode="med", pixels = "-1 -1-1 1 1 -1 1 1 0 1 1 0 -1 0 0 -1" , expr = "X Y - abs", u=1,v=1)
And this is my failed attempt (tried many combinations though, spent the last 6h on this):
Expr(C, C.removegrain(12),"
y[-1,-1] A^ y[-1,0] B^ y[-1,1] C^ y[0,-1] D^ y[0,1] E^ y[1,-1] F^ y[1,0] G^ y[1,1] H^ y[0,0] Y^ x[0,0] X^

X A - abs A^
X B - abs B^
X C - abs C^
X D - abs D^
X E - abs E^
X F - abs F^
X G - abs G^
X H - abs H^
X Y - abs Y^
X X - abs X^

A B dup1 dup1 min swap2 max
C D dup1 dup1 min swap2 max
E F dup1 dup1 min swap2 max
G H dup1 dup1 min swap2 max
swap5 swap1 swap6 dup1 dup1 min swap2 max
swap5 swap1 swap2 dup1 dup1 min swap2 max
swap6 swap1 swap7 dup1 dup1 min swap2 max
swap3 Y dup1 dup1 min swap2 max
swap7 swap1 swap6 min
swap3 swap1 swap4 dup1 dup1 min swap2 max
swap6 swap1 swap7 dup1 dup1 min swap2 max
swap4 swap1 swap2 max
swap3 swap1 swap5 min
swap3 swap1 swap5 max
swap3 max
swap3 dup1 dup1 min swap2 max
swap3 swap1 swap2 dup1 dup1 min swap2 max
swap1 swap3 min
swap2 max
min","")

[wonkey_monkey]

pixels = "-1 -1-1

Is that correct?

mt_luts is hard to find documentation for...

[Dogway]

Oh my, can't believe it! It was wrong on the source (https://forum.doom9.org/showthread.php?p=1380495#post1380495)already. There are certain strange things on "*.mp4 guy" scripts, not used vars, redundancy, commented code... I'm mostly copying things as they are. Already ported ReCon, blah, MedSharp, and SSSharp.


EDIT: By the way, aside from source code, mt_luts() is also explained at tp7's hideout (https://tp7.github.io/articles/masktools/) for dummies like me.

[pinterf]

Here's a test script. You can change mt_square() with the other shapes as well.

BlankClip(width=640, height=480, pixel_type="YV12")
manyPlus_Pattern("dirac")
mt_luts( last, mode = "max", pixels = mt_square( 3, zero=false ), expr ="y" )
Thanks, you are right. zero=false is erroneously including only those (x,y) coordinates where x or y is zero. Fix is on the way.
That means for zero=false the mt_someshapexx functions were returning the coordinate pairs of a centerless cross - points where x=0 or y=0 but not (0,0) - instead of the correct shape with a hole in the center.

[real.finder]

EDIT: By the way, aside from source code, mt_luts() is also explained at tp7's hideout (https://tp7.github.io/articles/masktools/) for dummies like me.

I don't think you (nor most peoples here) dummy, they said "No one is born a scientist" and it's all about personal interest, language barrier, and other circumstances

it's not hideout, http://avisynth.nl/index.php/MaskTools2#Exernal_Links in fact it was in his website IIRC but then it was down so he move it to github

[pinterf]

Could you please test this build:
https://github.com/pinterf/masktools/releases/tag/2.2.27
Contains some other changes as well:
v2.2.27 (20210909)

- fix zero=false case for shape helper function (mt_rectangle, mt_circle, mt_diamond etc...)
- lut expressions: report obvious script error (unbalanced stack, invalid keyword or variable, etc)
- mt_lut: reuse LUTs across planes if they are the same like in e.g. mt_lutxyz.
- 1D LUT expressions: occupy only the necessary size for 10-14 bit LUT tables (was: buffer was always reserved for 16 bit data)
- mt_merge: error is luma=false, mask is greyscale but clip is not greyscale
- mt_merge new parameter hint for chroma placement when luma=true and 4:2:0: "topleft". "topleft" is a new option for 4:2:0 videos only
- Source syntax update for GCC (20201229)
- CMake build environment, builds on Linux

[Dogway]

Didn't notice the post. Thanks, just tested and works fine although I use my own tools anyway.

[tormento]

Could you please test this build
After updating to latest version, I am having a problem with the following script

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\1_48 Fantozzi\fantozzi.dgi",ct=24,cb=24,cl=0,cr=0)
ConvertBits(16)
Spresso(10,30).STpresso(10,30,4,22,8,49,1,mc=true) #last updates
fmtc_bitdepth (bits=8,dmode=8)
Prefetch(6)

with error

mt_lutxy : Error at position 3: cannot convert to number: 1.000000
(D:/Programmi/Media/AviSynth+/plugins64/STPresso-2020_0507.avsi, line 40)

with STPresso being

# STPresso by Didée, MC by SilaSurfer, r.f mod in 2020.05.07 for HBD
function STPresso(clip clp, float "limit", float "bias", int "RGmode", int "tthr", float "tlimit", float "tbias", float "back", bool "mc", bool "HD", int "radius")
{
sisavs26 = !(VersionNumber() < 2.60)
limit = default( limit, 3 ) # spatial limit: the spatial part won't change a pixel more than this
bias = default( bias, 24 ) # bias: the percentage of the spatial filter that will apply
RGmode = default( RGmode, 4 ) # the spatial filter is RemoveGrain, this is its mode
tthr = default( tthr, 12 ) # temporal threshold for fluxsmooth. Can be set "a good bit bigger" than usually
tlimit = default( tlimit, 3 ) # the temporal filter won't change a pixel more than this
tbias = default( tbias, 49 ) # the percentage of the temporal filter that will apply
back = default( back, 1 ) # after all changes have been calculated, reduce all pixel changes by this value. (Shift "back" towards original value)
mc = default( mc, false ) #
h = clp.height()
ishd = h > 720
HD = default( HD, ishd ) #
radius = default( radius, round(h/540.0) ) #

LIM1 = (limit>0) ? string( round(limit*100.0/bias-1.0) ) : string( round(100.0/bias) )
LIM2 = (limit<0) ? "1" : string(limit)
BIA = string(bias)
BK = string(back)
TLIM1 = (tlimit>0) ? string( round(tlimit*100.0/tbias-1.0) ) : string( round(100.0/tbias) )
TLIM2 = (tlimit<0) ? "1" : string(tlimit)
TBIA = string(tbias)

expr = (limit<0) ? sisavs26 ? "x y - abs "+LIM1+" scalef < x x 1 x y - x y - abs / * - ?" : "x y - abs "+LIM1+" < x x 1 x y - x y - abs / * - ?"
\ : sisavs26 ? "x y - abs 1 scalef < x x "+LIM1+" scalef + y < x "+LIM2+" scalef + x "+LIM1+" scalef - y > x "+LIM2+" scalef - " \
+ "x 100 scalef "+BIA+" scalef - * y "+BIA+" scalef * + 100 scalef / ? ? ?" \
: "x y - abs 1 < x x "+LIM1+" + y < x "+LIM2+" + x "+LIM1+" - y > x "+LIM2+" - " \
+ "x 100 "+BIA+" - * y "+BIA+" * + 100 / ? ? ?"
texpr = (limit<0) ? sisavs26 ? "x y - abs "+TLIM1+" scalef < x x 1 x y - x y - abs / * - ?" : "x y - abs "+TLIM1+" < x x 1 x y - x y - abs / * - ?"
\ : sisavs26 ? "x y - abs 1 scalef < x x "+TLIM1+" scalef + y < x "+TLIM2+" scalef + x "+TLIM1+" scalef - y > x "+TLIM2+" scalef - " \
+ "x 100 scalef "+TBIA+" scalef - * y "+TBIA+" scalef * + 100 scalef / ? ? ?" \
: "x y - abs 1 < x x "+TLIM1+" + y < x "+TLIM2+" + x "+TLIM1+" - y > x "+TLIM2+" - " \
+ "x 100 "+TBIA+" - * y "+TBIA+" * + 100 / ? ? ?"

bzz = HD ? clp.minblur(radius) : clp.removegrain(RGmode)
sisavs26 ? mt_lutxy( clp, bzz, expr, scale_inputs=limit<0 ? "floatf" : "none", use_expr=1, U=3,V=3) : mt_lutxy( clp, bzz, expr, U=3,V=3)
tthr==0 ? last : sisavs26 ? mt_lutxy(last,last.mt_makediff(mt_makediff(bzz,mc ? bzz.STPresso_FluxsmoothTMC(tthr) : bzz.fluxsmootht(tthr),U=3,V=3),U=3,V=3),texpr,scale_inputs=limit<0 ? "floatf" : "none",use_expr=1,U=3,V=3) : mt_lutxy(last,last.mt_makediff(mt_makediff(bzz,mc ? bzz.STPresso_FluxsmoothTMC(tthr) : bzz.fluxsmootht(tthr),U=3,V=3),U=3,V=3),texpr,U=3,V=3)
back==0 ? last : sisavs26 ? mt_lutxy(last,clp,"x "+BK+" scalef + y < x "+BK+" scalef + x "+BK+" scalef - y > x "+BK+" scalef - y ? ?",U=2,V=2) : mt_lutxy(last,clp,"x "+BK+" + y < x "+BK+" + x "+BK+" - y > x "+BK+" - y ? ?",U=2,V=2)
}


Function STPresso_FluxsmoothTMC(clip clp, int "tthr")
{

tthr = default( tthr, 12 )

super = clp.MSuper(pel=2, sharp=1)

bv1 = manalyse(super,isb=true, truemotion=false, delta=1,blksize=16,overlap=8)
fv1 = manalyse(super,Isb=false, truemotion=false, delta=1,blksize=16,overlap=8)

bc1 = mcompensate(clp, super,bv1)
fc1 = mcompensate(clp, super,fv1)

result=interleave(fc1, clp, bc1).FluxSmoothT(tthr).selectevery(3,1)

Return(result)
}

[real.finder]

tormento, it's work fine for me, maybe it's dot vs comma thing again?

[tormento]

tormento, it's work fine for me, maybe it's dot vs comma thing again?
I don't know, rolling back to MaskTools-2.2.26 solved the issue.

There is some mistype or regression somewhere.

EDIT: Jumped back to .27 and now is working fine. Hell, don't know what happened. Sorry guys.

[real.finder]

I don't know, rolling back to MaskTools-2.2.26 solved the issue.

There is some mistype or regression somewhere.

EDIT: Jumped back to .27 and now is working fine. Hell, don't know what happened. Sorry guys.

you may want to try .28 https://github.com/pinterf/masktools/releases

[Blankmedia]

you may want to try .28 https://github.com/pinterf/masktools/releases

I have the same problem than Tormento.

With .28 I get errors with a couple of script.

Example in HaloBuster:

mt_lut : Error at position 15 : cannot convert to number : 0.24

([...]/HaloBuster.avsi, line 19)

line 19 :

mask = mt_lut (mask, "x range_max / 0.24 - 3.2 * 0.0 max 1.0 min range_max *", use_expr=2)

[pinterf]

I have the same problem than Tormento.

With .28 I get errors with a couple of script.

Example in HaloBuster:

mt_lut : Error at position 15 : cannot convert to number : 0.24

([...]/HaloBuster.avsi, line 19)

line 19 :

mask = mt_lut (mask, "x range_max / 0.24 - 3.2 * 0.0 max 1.0 min range_max *", use_expr=2)
What is your input local, are you using "," as decimal separator?
Anyway, masktools always sets decimal separator to "." before parsing the number. I wonder if it got changed somehow.

EDIT: I have ',' in my input local as well but could not reproduce, anyway I have changed that part.
Check this, I hope it works:
https://github.com/pinterf/masktools/releases/tag/2.2.29