MaskTools 2.0a48

[Manao]

Is that a question ?

[jeffy]

Is that a question ?

Yes, it is. Simply said: is the value of Round(1.5) in MaskTools equal to 1 or 2?

I would like to know as well, :thanks:

[Manao]

You shouldn't have to know. Any formula relying on 1.5 being specifically rounded to 1 or to 2 is ill designed. Masktools makes its computations in floats, which have a limited precision. 1.0 + 0.5 might not be exactly 1.5, thus you shouldn't care whether 1.5 is rounded to 1 or 2. You just know it rounds to the nearest integer.

[Nikos]

Sorry for the wrong phrase :(

Thanks for the clear answer :)

[yup]

Hi All!
I have problem with mt_masltools. When I changed
mcfmaskpl=mt_merge(mcfpl,fieldsfpl,mmaskpl,u=3,v=3)

to
mcfmaskpl=mt_merge(mcfpl,fieldsfpl,mmaskpl,luma=true)
Avisynth crashed. Script work YUY2 planar color mode, when script work at YV12 no problem.
With kind regards yup.

[foxyshadis]

Didn't you read the documentation? Luma and chroma aren't booleans (true/false), they're strings ("ignore"/"process"/"copy"/"copy first"/"copy second"/"copy third").

[Didée]

True for chroma, false for luma. :D

("chroma" argument of any mt-filter is string type, but "luma" argument of mt_merge is boolean, indeed.)

[yup]

foxyshadis!
documentation mt_masktools:
mt_merge

mt_merge : clip clip1, clip clip2, clip mask, bool "luma"(false)

It's the backbone of the framework. It merges two clips according to the mask. The bigger the mask value, the more the second clip will be taken into account ( the actual formula is y = ((256 - m) * x1 + m * x2 + 128) / 256 )
luma is a special mode, where only the luma plane of the mask is used to process all three channels.
u and v are defaulted to 2 (that way, the resulting clip contains the chroma of clip1, and looks right).
Didée I want use luma plane from mask to 3 plane clip2. It is right?
yup.

[Manao]

yup: mt_merge should report an error when trying to use luma=true with a 422 video, but it shouldn't crash.

[yup]

Manao!
I get message when see script in VirtualDub:
If change luma=tru to U=3, V=3 all work without problem for YUY2 planar colorspace. If You want i can upload my script.
yup.

[Didée]

I guess the problem comes from the fact that mt_merge needs to perform a resizing operation when luma=true, but Avisynth does not support resizing of "planar hacked" YUY2 input ... ?

However: yup, most probably you don't need luma=true. It seems that you're currently dealing with masks provided by MVMask(). Those masks contain the needed information on all three planes, so using the normal U=3,V=3 in mt_merge should do what you want.
If that's not the case, you have to construct your mask clip manually by means of YtoUV() operations.

[yup]

Didée!
mask=Planar2Interleaved(maskpl)
HorizontalReduceBy2(mask).YtoUV()
mask=Merge(mask)
maskpl=Interleaved2Planar(mask)
maskpl mask in planar colorspace
mask YUY2 in interleaved colorspace.
This will be work?
yup.

[yup]

Please advice:
mmask=Planar2Interleaved(mmaskpl)
YtoUV(HorizontalReduceBy2(mmask),HorizontalReduceBy2(mmask))
mmask=MergeLuma(mmask)
mmaskpl=Interleaved2Planar(mmask)
And use U=3,V=3 at mt_merge. This work like luma=true for YUY2 planar?
Now right?
yup.

[Didée]

Seems to be correct, yes.
Small nitpick: it does a little more work than necessary.
More efficient:
mmask = mmaskpl.Planar2Interleaved()
mmask2 = mmask.HorizontalReduceBy2()
mmaskpl = YtoUV(mmask2,mmask2,mmask).Interleaved2Planar()

[yup]

Didée :thanks:
My collection tip&trick grow one more :thanks:
yup.

[Alain2]

Hi Manao,

Is it normal that mt_edge doesn't output the same thing when using a named kernel and its equivalent kernel as defined in the html help file ? (like for instance "laplace" and "1 1 1 1 -8 1 1 1 1")

[Manao]

laplace is equivalent to "1 1 1 1 -8 1 1 1 1 8", while "1 1 1 1 -8 1 1 1 1" gets interpreted as "1 1 1 1 -8 1 1 1 1 16". The same applies to sobel ("0 -1 0 -1 0 1 0 1 0 2" and robert ("0 0 0 0 2 -1 0 -1 0 2").

[Alain2]

ok :thanks:

[LaTo]

Hi!

I have a little problem with the pi value... Maybe a bug!

In the documentation:
V) Reverse polish notation.
[...]
The constant "pi" can be used.

But if I try a simple expression:
mt_lut("pi 2 / sin 255 *")
It return a black screen instead of a blank screen...

It would be great to fix this :thanks:

[Manao]

Fixed in 2.0a36

[lilive]

Hi,
:thanks: very much for this job, and to share it.
I'm using it to produce some movies for a little dance show.
I hope I will do somedays something usefull like that !
Bye,
Et le bonjour de Toulouse :)

[adamhj]

bug in 2.0a36 : it seems that mt_polish can not recognize variable "z" for mt_lutxyz

[WorBry]

Any possibility that the MaskTools v2 developers could add a filter that translates reverse polish expressions to InFix notation - call it mt_Infix, if you will, or maybe make it an option in the mt_polish filter.

This would greatly assist non-programmers, such as myself, in deciphering and modifying the calculations/operations involved in scripted functions developed by others.

Thanks.

[Manao]

adamhj, worbry : see my signature for the new version.

[WorBry]

adamhj, worbry : see my signature for the new version.

Wow, that was fast. Really excellent. Thanks alot. :)

Although self explanatory, I guess the documentation needs to be updated to include mt_InFix in the filter list.

Thanks again.

[Zep]

I'm curious. what is the difference between the 25 and 26 dll's? :)


thx

[Manao]

One is for avisynth 2.5, the other one for avisynth 2.6

[Zep]

One is for avisynth 2.5, the other one for avisynth 2.6

ah thanks i thought that was the case so i used 25 but i wanted to make sure because i saw a lot of these scripts for denoising and what not and most state 26 is needed so i hoped there was nothing in 26 they truly needed that 25 didn't have. :)

better safe than sorry so i asked lol


thx!

[Gavino]

One is for avisynth 2.5, the other one for avisynth 2.6
It would be nice if this was made clearer in the documentation, as I see a lot of scripts posted that erroneously use mt_masktools26.dll with Avisynth 2.5.

In practice, what problems can arise from using the wrong version?

[Manao]

In practice, what problems can arise from using the wrong version? I have no idea. Somebody asked me once to release a 2.6 version, so I did. But I didn't test it, and neither did I test cross compatibilities. I'll try to add a note (which nobody will read...) and find a more explicit naming scheme for the next release.

[IanB]

In practice, what problems can arise from using the wrong version?You can use the 25 .dll for RGB24, RGB32, YUY2 and YV12 with any version of avisynth later than 2.5.0.

You can only use the 26 .dll with versions of Avisynth which were compiled with an avisynth.h that is compatible with the one used to compile the 26 .dll If the bit positions of the *needed attributes and pointers in the referenced structures do not match then you can expect incorrect behaviour and crashes.


* Stuff from the 2.5 feature set should be okay. Stuff that has not been shuffled since should be okay. Stuff like the VideoInfo pixel type bit definitions then maybe there is a problem.

[Zep]

It would be nice if this was made clearer in the documentation, as I see a lot of scripts posted that erroneously use mt_masktools26.dll with Avisynth 2.5.

In practice, what problems can arise from using the wrong version?

tell me about it and why i asked because i downloaded like 10 scripts and like most all said 26 or showed 26 being loaded :)

I just tested 26 with 258 avisynth and crashed right away so i can only assume all these scripters have 2.6 avisynth installed lol

[Zep]

I have no idea. Somebody asked me once to release a 2.6 version, so I did. But I didn't test it, and neither did I test cross compatibilities. I'll try to add a note (which nobody will read...) and find a more explicit naming scheme for the next release.

hey i would have read it because your docs were the FIRST place i went to try to figure it out and i saw nothing about it so i posted here :D
BTW - 26 crashed instantly for me on a 258 avisynth install. IIRC there was an out of bounds memroy read/write error.

anyway thx for the awesome plugin!

[Manao]

Hi everyone.

I'll need your help for that one, since I don't have a 64bits OS. here (http://manao4.free.fr/masktools-v2.0a38.zip) is a new set of dlls for masktools v2. There are four of them, 2 of them should work with 64bits avisynth (2.5 and 2.6, according to their filename)

Can anybody tell me whether the 64bits dll crashes or not ? Especially, try to use mt_edge (sobel or roberts would do) and mt_invert.

Also, I don't consider those dlls (even 32 bits) stable right now, since I had to rewrite most of the asm to make it 32/64 bits portable.

[Didée]

While you're at the compiler, may I note something?

function f4(clip c) { c.mt_inflate(Y=3,U=3,V=3) }
function f5(clip c) { mt_logic(c,c.removegrain(19),"max",Y=3,U=3,V=3) }

f4: 92 seconds :eek:
f5: 28 seconds :cool:
Seems that mt_xxflate() could need some optimization. (Are they still the plain C routines, maybe?)

[Manao]

mt_inflate/mt_deflate are plain c. I never bothered optimizing them, since I never noticed anybody using them. Now, if you start doing so, I might optimize them

[Didée]

Oh, be assured they have been used. All those years, all over the world. ;)

If it's for throwing ideas - in the TGMC script, there is this winded "VCRep()" function. It basically does a "signed" variation of expand+inpand, in order to cancel-out high frequency parts from a 128-centered difference map. The implementation is a bit arbitrary, and surely it's rather slow. I'm not sure if there is a better/simplier way of doing such an operation, or if it's even worth considering to include something like that into the masktools ...

Thoughts are welcome. :)

[Terka]

Manao, please do!

[Manao]

New version (http://manao4.free.fr/masktools-v2.0a40.zip) in my signature. It should speed up mt_inflate/mt_deflate, and mt_inpand/mt_expand in the modes vertical/horizontal/both.

[Terka]

Thank you, it was done fast!

[MatLz]

Now my crappy functions will be 'faster crappy functions'...:D

Un grand merci!

[Manao]

To Didée and all the frenzy scripters out there : If you have some masktools-intensive script excerpts which might be optimizable, don't hesitate to share them here. I don't use any fancy script myself, so my knowledge on that matter is sorely outdated (think "when limitedsharpen became limitedsharpenfaster"...). For example, are there other examples of the like of vcrep() out there ? Are there any specific use of mt_luts / mt_lutf that could benefit from being specialized & optimized ? Are there some common combination of functions that are so often used together that they would merit their on filter (as mt_makediff / mt_average / mt_clamp / mt_adddiff did) ?

Also, I can most probably squeeze some more speed out of some of the filters (either using ssse3/sse4, or just rewriting assembly for mt_xxpand/mt_edge/mt_inflate and the likes), or make there assembly more versatile (most of them needs the width to be mod8). What are the filters that are used the most ?

[Boulder]

Hi Manao,

MCTemporalDenoise is one that uses MaskTools v2 functions quite a bit. Of course the MaskTools parts aren't the most time-consuming ones in the script but if you can provide any speedup, I am very happy to accept the offer :)

http://forum.doom9.org/showthread.php?t=139766

[Manao]

Hi,

Here (http://manao4.free.fr/masktools-v2.0a42.zip) is a new version, which adds new modes to mt_binarize and mt_logic.

For example, mt_lut("x "+string(cutoff)+" >= x 0 ?",U=1,V=1) can be replaced by mt_binarize(threshold = cutoff - 1, mode = "x 0")Andmt_lutxy(smP,i,"x y - abs "+string(maxdiff)+" <= x x y - 0 < y "+string(maxdiff)+" - x ? ?",U=1,V=1)bymt_logic(smP, i, th2 = -maxdiff, mode="max")

[Gavino]

Behaviour of mt_lutspa(relative=true)

According to the MaskTools docs, when relative=true is used with mt_lutspa, the expression variables x and y range from 0 to 1. However, it seems that the upper ranges are actually (width-1)/width and (height-1)/height, a value of 1 is never actually reached. Is this intended, or is it a bug?

To my mind it would be more useful, for creating accurate gradients etc, if the last pixel in a row or column corresponded exactly to 1. So I suggest pixel (m, n) should correspond to x=m/(width-1) and y= n/(height-1).

[Mug Funky]

i seem to not be having much luck with YV16 with masktools :(

i'm wanting to migrate my "workhorse" scripts that i've had for years to a 4:2:2 workflow.

i seem to be getting lots of unsupported colourspace errors.

[Manao]

Mug Funky : Fixed (http://manao4.free.fr/masktools-v2.0a43.zip)

Gavino : it was not intended, but neither was it a bug. Both [0, 1[ and [0, 1] make sense. So I added a "biased" parameter. relative=true, biased=true corresponds to the default [0, 1[, while relative=true, biased=false is [0, 1], what you want.

[Gavino]

Manao, thanks for your quick response and action.
:thanks:

[Mug Funky]

fantastic! thanks for the quick response. i'd been thinking i was missing something...

[Gavino]

Manao, the new biased parameter of mt_lutspa has been introduced between the parameters relative and expr.
This causes problems for existing scripts which have called mt_lutspa with positional parameters (eg see here).

Rather than have everyone affected update their scripts/functions, it would be better to make biased the last parameter in the list. It is generally good practice to do this when introducing new options, to preserve backwards compatibility.