MaskTools 2.0a48

[foxyshadis]

Originally Posted by Socio

Kind of OT:

Well I am thoroughly confused with Mano's new naming structure, there is no function called DEdgeMask. There is a function called " mt_edge" which along with mt_motion and mt_mapped "are the counterpart of EdgeMask,
DEdgeMask, DEdgeMask2 and MotionMask".

I tried changing the calls in LS from DEdgeMask to mt_edge and it did not work, so what function call do you use to replace DEdgeMask in LS?

EDIT: Didee it looks like you may need to completely re-write your DEdgeMask call in LS to make this new version of masktools work.

Just replace with mt_edge(mode="custom matrix",y1=....). The main change is that edgemask and dedgemask were merged, mode replaces both type and matrix. If there's a divisor, it's appended to the end of the custom matrix.

mt_mapped is dedgemask2 equivalent, I guess, replacing the y/c arguments with special clips.

[Socio]

I got it working in LS took a litle more than just subing the names though thx for the help foxyshadis.


I have another question does the "mt" prefix in the new function names stand for multi threading?

[Manao]

No, it's a shortcut for MaskTools. Since both version ( v1 and v2 ) had to be usable at the same time, I had to differenciate them.

[Manao]

*Bump*

New build is up : http://manao4.free.fr/masktools-v2.0a8.zip

Changes from alpha 7 to alpha 8 :

* fixed : mt_edge in custom mode wasn't working properly
* fixed : mt_edge in custom mode, optimized wasn't working properly either
* fixed : mt_lutxy was slow to load, it's better now

[AVIL]

@manao

mt_convolution don't work for me

myclip.mt_convolution(horizontal="0 1 0", vertical="-1 2 -1",u=3,v=3) left myclip x untouched.

myclip.yv12convolution(horizontal="0 1 0", vertical="-1 2 -1",u=3,v=3) does the convolution ok.

It's the same for :

myclip.mt_convolution("0 1 0","-1 2 -1",u=3,v=3)

BTW my version is 2.0 a8

[Manao]

AVIL : thanks for the report, it's fixed :

Changed from alpha 8 to alpha 9 :

* fixed : mt_lut, mt_lutxy : even faster loading
* fixed : mt_convolution : negative coefficients were offseted by 1
* fixed : mt_convolution : division by zero if the sum of the coefficients was 0.

[puffpio]

the link to a9 is broken..it looks like it's not on the server

[Manao]

Fixed

[AVIL]

@Manao

mt_lutxy and mt_lut (version 2.0a9) dont work :


mt_LUTxy(myclip,myclip,"x y - abs" , "128", "128",u=3,v=3)

gives a pale green clip

yv12LUTxy(myclip,myclip,"x y - abs" , "128", "128",u=3,v=3)
gives a black clip, as spected.

mt_lut(myclip,"x 25 < 255 0 ?" , "128", "128",u=3,v=3)
gives an uniform pale green clip also

yv12lut(myclip,"x 25 < 255 0 ?" , "128", "128",u=3,v=3)
gives a binary clip, as spected.

[Manao]

This time, it's not a bug. Arguments should always be named to avoid all confusion. In this case, you didn't notice that I added a fourth string, "expr", in addition to "yExpr", "uExpr" and "vExpr", whose purpose is to serve as default expression if one is missing. Order is expr, yexpr, uexpr, vexpr, so vexpr is missing, replaced by the first one, and yexpr is "128".

[AVIL]

@manao

Sorry.

Indeed, I must read the manual BEFORE use (not AFTER how I'm accustomed)

[Didée]

Just a note, if anyone is scratching it's head like I was ... the "equal" operator has been changed to "==" in MT 2.x , where it was "=" in MT 1.5.x ...
"x y = 255 0 ?" --> "x y == 255 0 ?"

It's fine that way, but isn't noted anywhere ... lut description refers to the old 1.5.x documentation.

[Manao]

Never use that operator anyway. Numbers are floats during the lut precomputation, and you should never do a =(=) b with floats. Rather use abs(a-b) < epislon instead.

But I'll update the documentation.

[Didée]

When checking the hyperbolic cosecant of a complex power against <value>, sure. /*earnest face*/

For direct checking of pixel values, "=" has proven to be quite handy.

"x 128 = [this] [that] ?" (a)

is readable. When instead writing

"x 128 - abs 0.00001 < [this] [that] ?" (b)

then, while we're at it anyways, why not make it completely unreadable like

"x 128 - 128 x - * 1 2.0 / ^ 1 10000 / < [this] [that] ?" (c)


Somehow I prefer variant (a), dunno ...

[Manao]

Then, I could change =(=) operator to act like x y - abs epsilon <, what do you think of that ?. Because I persist in thinking that =, as such, on float, is a bad idea. If you need, I can even export the epislon parameter ( though 0.001 should be OK for most purposes ).

[AVIL]

@Manao

I've found that mt_convolution lacks of parameters "total", "automatic" and "saturate".

Although I can emulate "total" parameter with a posterior mt_lut step, I don't know how to mimic saturate.

Is possible to implement this parameters in mt_convolution or i must
use yv12convolution? (or ¿they are an easy method to emulate them?)

BTW, I agree with the idea of the epsilon for the == operator. I think also that checking pixel identity is a must for the LUT tools.

Thanks.

[cwolf]

It seems that the parameter "offy" is being disregarded in mt_lutxy. It is assuming "offx" as "offy" because no matter what I put in "offy" it is considering the value in "offx", so the "home" point is always a square. Could you confirm this? I'm using the 2.0a9 version dated nov 8th 21:41.
Cecilia
[edit]forgot to post the script:
mt_LUTxy (last,levels(0,1,255,255,255), yexpr="y", uexpr="y", vexpr="y",offx=64,offy=344,w=120,h=64)
levels is being used here for debugging purposes only.

[Manao]

cwolf : well spotted, fixed, I'll soon release a new version.

AVIL : sorry for having taken so long to answer : I'll add them ( automatic will be useless though ).

[Manao]

*bump*

Changed from alpha 9 to alpha 10 :

 * fixed : offY was always set to offX
 * fixed : offset quirk
 * fixed : mt_convolution was crashing with floats
 * changed : luts' equal operator is now equivalent to abs(x-y) < 0.000001
 * added : bool saturate(true) parameter to mt_convolution
 * added : float total(1.0) parameter to mt_convolution

[Didée]

mt_convolution still has bugs. You can create weird output and access violations with

a =  last
b =  mt_convolution("1","1 4 6 4 1",U=2,V=2)
c =  mt_convolution("1 4 6 4 1","1",U=2,V=2)
d =  mt_convolution("1","1 4 6 4 1",U=2,V=2)
 \  .mt_convolution("1 4 6 4 1","1",U=2,V=2)
 
e = stackvertical(stackhorizontal(a,b),stackhorizontal(c,d)) 
f = stackvertical(stackhorizontal(a,c),stackhorizontal(b,d)) 

#a
#b
#c
#d
#e
#f

return( last )

so it seems mt_convolution goes crazy when it gets input that was already processed by mt_convolution.
Interesting: on its own, the single-processed clips "b" and "c" are OK. In the stacked() output of "e", the "c" clip is distorted, too. And "f" just crashes with access violation.


Then, a question about shape-strings and expand & Co:

a) inflate/deflate

The readme of mt_masktools states: "compute a local average by taking into account only the neighbourgh whose value is higher than the pixel.

The html of v1.5.x states: Inflate will compute the mean of the surrounding pixels, and will replace the value of the pixel by it only if this mean is superior to the original value of the pixel.

This is definetly not the same operation. Has the behaviour changed, or is one of the two descriptions just not correct?


b) shape strings

I don't get the right grip to them. I.e. according to the readme of mt_masktools, the string "0 0 -1 0 1 0" is equivalent to "horizontal" for inpand/expand.
How does this work? the string has 6 numbers, but expand is working on 3x3 pixels ... so I'd rather expect a string with 9 numbers. Or is this similar to the "vector" format of mt_convolution, with both strings packed into one?

Then, radii bigger than 1 are supposed to work, yes? However when producing accordingly long strings, the respective filters do ~something~, but for me it's not predictable. In the same breath, the strings produced by the helpers mt_circle, mt_square etc. I just do not understand. Perhaps the string creation is buggy, perhaps the way the strings get interpreted from other filters is buggy. Perhaps I am buggy.