MaskTools 2.0a48

[Fizick]

I tried to model morhological dilation-erosion with MVtools2. Here is example script for structure element similar to circle with diameter=5.

avisource("football.avi")
converttoyv12()
mask=mt_motion(10,10,10,10,100)
circle5=" -2 -1 -2 0 -2 1" \
+ " -1 -2 -1 -1 -1 0 -1 1 -1 2" \
+ " 0 -2 0 -1 0 0 0 1 0 2" \
+ " 1 -2 1 -1 1 0 1 1 1 2" \
+ " 2 -1 2 0 2 1 "
mask.mt_expand(255,255,mode=circle5) # dilation
mt_inpand(255,255,mode=circle5) # closing=erosion(dilation)

It works as grey morphological closing with symmetrical (circle) black (=0) structure element.
Here is some links for curious persons.
http://www.cs.kun.nl/~ths/rt2/col/h11/11morphENG.html
http://www.ph.tn.tudelft.nl/Courses/FIP/noframes/fip-Morpholo.html
Thanks, Manao!
P.S. New MT_... names are not conflicted with MT (multy threaded) plugin by TSP?

[Manao]

Fizick : you should have a look at the mt_circle helpers, if you plan to use larger circles. Meanwhile I'll check whether names conflict with TSP's plugin

[tsp]

the only function I use in mt.dll is MT() as mt_ is just a prefix in masktool I don't think there will be any name conflicts problem.

[AVIL]

@Manao

A question about mt_edge and the rest of the mask. ¿What is the behaviour if the result of the convolution is negative or greater 255?. ¿Would be useful a parameter "bias" like in generalconvolution or "saturate" like in mt_convolution?.

Thanks

[Manao]

mt_edge computes the absolute value of the convolution. The kernel can be normalized, so it can be made in order not to go over 255. Default kernels are normalized that way. If you don't specify a normalization value in the custom kernel, a value is computed in order the absolute value not to go over 255, though it's overnormalized ( hence 255 most probably be reached )

[AVIL]

@Manao

Thanks

[Neil Lee]

This is a usage Q but Knowing this could be a potential bug
so I'll post it here. relocate if deemed to.

I tried to use merge funtion in MaskTool (both MaskedMerge & mt_merge)
but never got the result I expected, so I ran a simple test.
can anyone tell me what's wrong or maybe Mt_Merge/MaskedMerge has bugs?

green vid (10 K) (http://dabadee.hypermart.net/mvtool/green.avi)

red vid (10 K) (http://dabadee.hypermart.net/mvtool/red.avi)

bw vid (10 K) (http://dabadee.hypermart.net/mvtool/bw.avi)

Base
http://dabadee.hypermart.net/mvtool/green.jpg

Overlay
http://dabadee.hypermart.net/mvtool/red.jpg

Mask
http://dabadee.hypermart.net/mvtool/bw.jpg

Expecting a Green and Red vid but the OUTPUT IS An ALL RED

Result
http://dabadee.hypermart.net/mvtool/red.jpg

--------------------------------------------------------
loadplugin("C:\delogo-FTV\masktools.dll")
loadplugin("C:\delogo-FTV\mt_masktools.dll")

base=AviSource("G:\red.avi")
overlay=AviSource("G:\green.avi")
mask=AviSource("G:\bw.avi")

base=converttoyv12(base)
overlay=converttoyv12(overlay)
mask=converttoyv12(mask)

output=mt_merge(base , overlay , mask)

return output
---------------------------------------------------------

[Manao]

Channels Y, U and V are independant in the masktools, and, by default, chroma isn't processed. In your case, black amounts to Y=0, u=128, v=128, white to y=255, u=128, v=128, so U & V channels will be blended if they are processed.

A channel will be processed if you add the option y=3, or u=3, or v=3 in the filter's parameters ( for example, in your case, you'll want to do mt_merge(source, overlay, mask, y=3, u=3, v=3) ), have a deeper look in the (too short) documentation provided ( hint : the old documentation that comes with the masktools v1.5.8 explains the concept, you might want to get it ).

Finally, in your case, it's not a black & white mask that you want, but a dark green ( y=0, u=0, v=0 ) & bright pink ( y=255, u=255, v=255 ). Usually, when having a greyscale mask, you can obtain a mask that applies to all three channels by using ytouv.

[AVIL]

@Manao

I've found, using mt_merge, that chroma processing is the same using modes 2 and 3 for both u and v parameters.

i.e.

mt_merge(clip1,clip2,mask,u=2,v=2) and mt_merge(clip1,clip2,mask,u=3,v=3) yields the same result.

I've expected that in the first case, chroma comes from first clip and in the second case chroma where obtained from both clip according to the mask.
¿What is the actual processing of the chroma in this filter? (Chroma proccessing is not mentioned in the documentation for mt_mege nor for maskedmerge)

Thanks

[Manao]

Firstly, chroma is processed independantly from luma ( so the chroma mask applies, not the luma one ). Secondly, modes should work the same, i.e 1 trashes, 2 copies the first, 3 processes, and 4 copies the second. If you observe another behavior, it means there's a bug, but I'd be rather surprised, since I took care last time to check all that.

[Didée]

Quirk in chroma processing of in/expand & in/deflate:

wdth = 656 # <-- toy around & have fun
hght = 480

a = blankclip( width=wdth, height=hght, pixel_type="yv12" )
b = a.mt_expand( U=3, V=3 )

return( b )

This' my last nagging this year, promised. :)

[Manao]

Thanks a lot, once again

http://manao4.free.fr/masktools-v2.0a14.zip

Changes from alpha 13 to alpha 14 : * fixed : random crashes with some width and asm functions ( thx Didee )

[Didée]

Many thanks for fixing last year's bug ... now let's proceed with this year's ones ... :D

Bug in mt_inflate / mt_deflate:

somemask = blankclip(width=80,height=24,pixel_type="yv12").subtitle(" . o + !")
\ .greyscale.addborders(56,36,56,36)

expandold = somemask.expand().expand().expand().greyscale()
expandnew = somemask.mt_expand().mt_expand().mt_expand().greyscale()
inflateold = somemask.inflate().inflate().inflate().greyscale()
inflatenew = somemask.mt_inflate().mt_inflate().mt_inflate().greyscale()
deflateold = expandold.deflate().deflate().deflate().greyscale()
deflatenew = expandold.mt_deflate().mt_deflate().mt_deflate().greyscale()

expandoldD = yv12subtract(somemask,expandold)
expandnewD = yv12subtract(somemask,expandnew)
inflateoldD = yv12subtract(somemask,inflateold)
inflatenewD = yv12subtract(somemask,inflatenew)
deflateoldD = yv12subtract(expandold,deflateold)
deflatenewD = yv12subtract(expandold,deflatenew)

stackhorizontal( stackvertical( somemask.subtitle("source"),
\ inflateold.subtitle("inflate (old)"),
\ inflatenew.subtitle("inflate (new)").addborders(0,0,0,16,color=$FFFFFF),
\ expandold.subtitle("source2"),
\ deflateold.subtitle("deflate (old)"),
\ deflatenew.subtitle("deflate (new)")
\ ),
\ stackvertical( somemask, inflateoldD,
\ inflatenewD.addborders(0,0,0,16,color=$FFFFFF),
\ expandold, deflateoldD, deflatenewD)
\ )

http://img445.imageshack.us/img445/2407/bugmt2inflate4ef.png


BTW, may I suggest to rename mt_inflate to perhaps mt_inflate2 or something, and to restore the old functionality of inflate? While frankly i don't like either of them too much (old one's effect is too weak, new one's effect is too strong), the new behaviour of mt_inflate could severely break scripts when porting them from MT v1.5.8 to MT v2.0. (For example, mf's HQDering would become a joke when replacing inflate with the current mt_inflate.)

[Manao]

Damned you :p

http://manao4.free.fr/masktools-v2.0a15.zip

Changes from alpha 14 to alpha 15 : * fixed : bugs from inflate & deflate ( thx you know you )
* reversed : inflate and deflate now match their masktools v1 counterparts' behavior.
( if anybody used the new buggy one, let him speak quickly )

PS: Didee, you're a god send for a developper.

[Manao]

Yet another bugfix ( will it ever end ? )

http://manao4.free.fr/masktools-v2.0a16.zip

Changes from alpha 15 to alpha 16 : * fixed : some asm code used in invert, binarize and memset to a particular value.
Bug made the first 8 pixels of the picture to be incorrect. Also, avoid another nasty issue
that arise when cropping ( not my fault this time, though ).Thanks Lefungus for finding that one.

[Revgen]

Yet another bugfix ( will it ever end ? )


Not as long as it's called "alpha";)

[Manao]

I'll not deprive Didee of the pleasure of finding bugs :)

And there're still filters in the masktools for which bugs haven't been found. Since it's far too unlikely that they don't have bug, I can't decently rebrand it "beta" or something else.

[foxyshadis]

Hate t' bother ya, but I found a new discrepancy I'm surprised hasn't showed up yet. Can you compare the output of:

DEdgemask(0,255,0,255,"100 0 0 0 0 0 0 0 0")
and
mt_edge("100 0 0 0 0 0 0 0 0",0,255,0,255)

Then compare with 100 tacked on the end. It seems the new one uses 128 as the divisor for some reason.

[Manao]

Indeed, it does, but it's a wanted feature, for once :)

The thing is, 100 would require to divide by 100, while 128 merely require a shift, which is both faster and would enable mmx optimizations ( see later why it doesn't )

So, the hidden behavior of the filter is the following :
* If you specify a divisor, it'll use it. No mmx is allowed.
* If you don't, it'll use the closest next power of 2 of the sum of the absolute value of the coefficients. If that value is <= 64, a mmx version will be used. So in your case, it's not the mmx version that is used.

At the cost of a small unaccuracy in the division, I can do a mmx version with an emulated division. But when I designed the filter, I didn't want to bother with that ( and it would be slower than the shift one )

In any case, I can change the behavior so that if no mmx is possible, the "correct" divisor could be used. I can also correct the bug that you'd have noticed in the end ( if the sum is higher than 256, it chooses 1 as automatic divisor )

[foxyshadis]

Hmm, even using "8 0 0 0 8 0 0 0 0" I get much darker results than if I add a 16 to the end. It's using 32 for that one. "16 0 0 0 0 0 0 0 0" works fine however.

I did miss the power of 2 line in the readme, sorry about that.

[Manao]

I didn't even remember having written that in the readme, so don't feel sorry ( anyway, even in my best day, I wouldn't call that a readme )

Anyway, "ceiled to the closest power of 2" --> 16 is ceiled to 32. It was wanted, by design, but thinking about it, the reasons for which I wanted that aren't that good ( or, rather, I don't remember why the hell did I force such a constraint, it might have been something along the lines "they don't care about the normalization factor, so lets choose one that pleases me, and lets take a huge useless security margin to avoid to have to think about whether or not the computation overflows" ;) ).

So I'll think a bit more about it, and change it if it's useless.

[foxyshadis]

But... 16 is a power of 2. I think I see what you're saying about overflow though, is it actually a big danger? The way it is now it pretty much by design will never use the expected normalization. (And oops, I was comparing two different things, I guess "16 0 0..." is the same way.)

If I specify a power-of-two value, will it use the mmx codepath?

[Manao]

Yes, it will use mmx if it can.

I removed the silly limitation ( 16 isn't changed into 32 ), and added some candies.

http://manao4.free.fr/masktools-v2.0a17.zip

Changes from alpha 16 to alpha 17 : * changed : behavior of mt_edge with a custom kernel : the automatic normalization factor
is now the sum of the absolute value of the coefficients, ceiled to the next power of two
if that power is <= 128 ( else, it isn't ceiled ).
* added : cartoon mode for mt_edge
* added : modified mfToon script, for masktools v2. mfToonLite's speed goes from 30 fps
to 70 fps, mfToon from 4.5 to 6.5.

The script is based on mfToon v0.53, it doesn't give a binary identic output, because of the bug in the previous masktools that I definitely don't want to emulate. But it looks alike.

[Egh]

http://manao4.free.fr/masktools-v2.0a17.zip

* added : cartoon mode for mt_edge



A lamish question: what is cartoon mode for?

And more important: is there a mirror for new builds?
E.g. currently i can't access the site to grab last build... ^^

[Didée]

Temporarily mirrored: MaskTools 2.0a17 (http://home.arcor.de/dhanselmann/_stuff/masktools-v2.0a17.zip)

[mg262]

Manao,

I just saw this on another thread (http://forum.doom9.org/showthread.php?p=766793#post766793):

mt_merge(NR,some_other_clip,MyMoMask.fity2uv(),U=3,V=3)

And it made me think that actually this is quite a common usage... having a grayscale (i.e. ideally Y8, luma only) mask and wanting to use it to merge all the planes of two other planar clips. Would you consider it as an addition to MaskTools :)?

[Manao]

I might. It doesn't go well into the framework I designed, but that can be changed, and I'll have to write another mmx function to process efficiently the chroma channels, so it may take some times. Most of all, I'll have to think of a new parameter name (*sigh*).

[Manao]

Ok, new version is up. I asked mg262 if I could include his LimitedSupport filters into the masktools, and he kindly agreed. Hopefully, the conversion was made without new bug.

In addition, I put inside the zip "Limitedsharpenfaster.avsi", adapted to these filters. Finally, mg262's great idea about a "chroma" parameter has also been added.

I didn't forget his request for mt_merge, it'll come soon I guess.

http://manao4.free.fr/masktools-v2.0a18.zip

Changelog from alpha 17 to alpha 18 : * added : mt_makediff, mt_adddiff, mt_average and mt_clamp, ported from mg262's
limitedsupport plugin. The asm code is his, though it has been ported to nasm. They
respectively amount to MakeDiff, AddDiff, SimpleAverage and Clamp.
* added : mt_edge : "prewitt" kernel, taken from mg262's Prewitt filter. Unlike mg262's filter,
there's no multiplier ( it's always 1 ), but mt_edge's thresholds still apply. Results,
and speed, are identical except for the borders, which are now filtered.
* added : "chroma" parameter, taken from mg262's excellent idea. It's a string that,
if used, overrides U and V values. It can be either "process", "copy", "copy first",
"copy second" or a number. "copy" and "copy second" work alike.
* added : vmToon-0.74, adapted to masktools 2.0.
* added : LimitedSharpenFaster, with LimitedSupport functions imported into the masktools.

[aberforthsgoat]

Say Manao,

I'm getting an error message now: "there is no function named 'mt_average.'" I'm guessing that this is one of the parts you have ported from mg262 - have I done something wrong?

Mike

[Manao]

Did you properly replaced the old mt_masktools.dll by the new one ? Because I don't have the problem on my computer.

[aberforthsgoat]

Did you properly replaced the old mt_masktools.dll by the new one ? Because I don't have the problem on my computer.

Aaargh!! - I just checked the timestamp on the new dll - and I think I pulled a pretty swift trick: Instead of copying the new dll into my plugin directory, I think I copied the old dll into the download directory, overwriting the old one. A downloaded again, and life seems to be improving.

Sorry for the mix up,

Mike

[Didée]

Hi again,

and today's bug is ... drummroll ... none! (I didn't search :D )

But I've a suggestion for a certain computation, which should or could fit well into mt_edge:

One thing I seem to do rather often is the following:
mt_lutxy(clp.mt_expand(),clp.mt_inpand,"x y - [factor] *")
(at times also for chroma).

Basically this is an edge mask, at least it looks like one. But in contrast to most other edgemasks, this one delivers a well defined result: the "span", or the value range, that is covered by the pixels in a 3x3 neighborhood.
While at times it deals well as a simply-an-edgemask, it might be of interest when doing comparisons between two clips. (Actually it is, surprise ;) )

Scripting it is obviously no problem. But I think it would run *way* faster with a dedicated implementation. When scripted, there are two 3x3 kernel operations to be done, plus a 2-clip lookup. But the required minimum is only one 3x3 kernel operation, anything more is unnecessary overhead. (And when doing lots of comparisons, it will count.)

What doesn't fit so well into mt_edge's framework is the [factor] thingy, I see. But then, that one most probably is only for purposes of visualization, hence could be done with an additional mt_lut, or later on when an actual comparison is done with mt_lutxy.
The important thing would be to do the funky "Lutxy(expand,inpand)" in one loop.

End of suggestion. :)

[Manao]

Suggestion noted. Actually, I rather like the edge mask built by expand - inpand, and used it back in the time when I was actually encoding things.

I'm still in the process of cleaning up a bit my framework, in order to make easily and cleanly possible mg262's mt_merge filter that applies directly the luma mask to all three components, so it might take a while ( well, actually, i don't know, it might be fast too ^^ ).

BTW, I was also thinking of another filter, more generic this time. Lets say you give it a list of pixels, a lut ( to apply to all these pixels, taking the central pixel's value into account ), and a way of collecting the result ( average, median, min, max, variance, whatever ( why not even a matrix )). You end up with a filter that gives you quite a lot of liberties, though it'll be slow. But I'm sure you would find a use to such a thing, wouldn't you ? ;)

[Didée]

Heya, that sounds interesting. However much more complicated than anything I ever would even dare to suggest ;)
Though right now, I don't see what is "a list of pixels" ?

Smells like the way to a solution to a problem that's always buggin' me: evaluation of "spatial correlation" properties. (Imagine you build a signed difference of two clips - with the naked eye, you see immediately where the difference is just noise, and where there are real "structures" in the difference map ... but forcing a dumb-as-grass computer to properly reckognize this is not all that trivial.)

Go on, Manao. We're all on edge.

[Manao]

Though right now, I don't see what is "a list of pixels"It's the list of the surrounding pixels you want to take into account. Basically, it's the same thing than inpand/expand's custom kernels. But instead of doing what inpand / expand do ( ie, finding the min / max of the list of surrounding pixels ), that one will let you choose what you want to find ( well, almost ).

[Manao]

Ok, finally, it was sooner than later. Here's a new version :

http://manao4.free.fr/masktools-v2.0a19.zip

Changes from alpha 18 to alpha 19 : * code refactoring
* fixed : bug with asm and width lower than 64
* fixed : doesn't prepend (0, 0) pixel to the forms helpers
* added : "min/max" mode to mt_edge. The edge value is local max - local min ( taken on a
3x3 square ).
* added : mt_lutf : a frame lut
* added : mt_luts : a spatial lut
And here is the documentation for the new filters * mt_lutf : clip, clip, string mode("avg"), string expr("y"), string yexpr("y"), string uexpr("y"), string vexpr("y")
+ mt_lutf takes two clips into account. It'll compute the "mode" operation over the
pixels of the first clip, and then apply the lut on the second clip, with x = computed "mode"
value, and y the usual lut variable. "mode" can be "avg", "std", "min", "max", and
"range" = "max" - "min".

* mt_luts : clip, clip, string mode("avg"), string pixels(""), string expr("x"), string yexpr("x"), string uexpr("x"), string vexpr("x")
+ mt_luts takes two clips into account. It'll compute the "mode" operation over the
result of the lut expression, with the pixel of the first clip as x, and the neighbouring
pixel of the second clip as y. Since that doesn't make any sense when explained so bluntly,
lets give some examples :
- mt_luts( c1, c1, mode = "avg", pixels = mt_square( 1 ), expr = "y" ) does a convolution
by a 3x3 kernel filled with ones.
- mt_luts( c1, c1, mode = "min", pixels = mt_square( 1 ), expr = "y" ) does an inpand
- mt_luts( c1, c1, mode = "range", pixels = mt_square( 1 ), expr = "y" ) does a
mt_edge( mode = "min/max" )
- mt_luts( c1, c1, mode = "std", pixels = mt_square( 1 ), expr = "y" ) gives the local
standard deviation of the clip
- mt_luts( c1, c1, mode = "max", pixels = mt_square( 1 ), expr = "x y - abs" ) gives
the maximum difference between the surrounding pixels and the center.
As you can see, the "modes" play a great part in the behavior of the filter. I wasn't really inspired when I created those 5 modes, so feel free to bug me whenever you find an interesting idea for them.

[Manao]

Mmm, I borked something just before releasing it. I erased some files and restored them to an incorrect version. That resulted in most filters being mainly borked...

I'll correct that ASAP.

[Manao]

Fixed : http://manao4.free.fr/masktools-v2.0a20.zip

[Didée]

Huh, that was fast! And what nice things to play with - if I only think of how dreadful it was to juggle around with masks to get something ~similar~ like standard deviation ... :rolleyes:

A bunch of new possibilities has opened (... though it might take some time to actually realize all of 'em).

Many many thanks, Manao!

[foxyshadis]

http://forum.doom9.org/showthread.php?p=772816#post772816

Can you check this out, Manao? I haven't had time to investigate whether it was a script translation error or actual filter error for certain.

[Manao]

Thanks for pointing it out

http://manao4.free.fr/masktools-v2.0a21.zip

Changed from alpha 20 to alpha 21 : * fixed : two & three input clips filters where requesting wrong frames
leading to ghost artefacts.

The script is ok, so whenever an issue arises, it's a bug on my side.

While debugging that issue, I found out something disturbing. The result of the script was fine, except for frames #89, #119, #149 and so on. I'll investigate some more, because I don't know yet what I'm doing wrong. The 2.0a18 version doesn't seem to suffer that issue ( though it's quite hard to found, and for all I know, might be somehow random ). So, except for those wanting to play with the new filters, I strongly advise to come back to that version. Else, using SetMemoryMax to increase avisynth's cache also solved the issue ( which means it would reappear with a bigger script... )

[Manao]

Ok, false alarm, it was my avisynth.dll that was buggy. Hint to everyone, use latest avisynth ( 2.5.6 RC2 ) when you use complicated scripts :p

So 2.0a21 is fit to be used ( till the next bug :p )

[AVIL]

@Manao

I'm playing with the new function mt_luts and I wish make some questions.

1st. If I use pixels=mt_square( 2 ), the neighbouring chosen is a 5x5 matrix?
2nd. The center pixel of the second clip is used in the operation?.
3rd. What is the formula for mode "std"

Thanks

[Manao]

If I use pixels=mt_square( 2 ), the neighbouring chosen is a 5x5 matrix?YesThe center pixel of the second clip is used in the operation?Yes - though it might change if needed. I actually think both way have assets and drawbacks, so in the end, both might get chosen. Also, the center pixel is always taken into account. By the way, thinking of it, you can include twice a pixel, if so, it'll be used twice by the operator - which is useless if you're using min, max or range operator, but acts like weights if used with average and standard deviation.What is the formula for mode "std"square root(average(sum of (x - average(x)) ^ 2))

[Manao]

http://manao4.free.fr/masktools-v2.0a22.zip

Changelog : * added : "med"/"median" mode to luts/lutf
* changed : luts doesn't necessarily consider the center pixel
* changed back : forms helpers prepends (0, 0).
* changed : forms helpers now have a bool "zero" parameter, defaulted to true
* added : bool "luma" parameter to mt_merge, which makes it use the luma mask for
all three planes, and which forces chroma modes to "process" ( u=v=3 )

No bug fixes for once :p

[Mug Funky]

oops, found one :)

try:

mt_expand(mode=mt_circle(7),y=3,u=3,v=3)

it seems the middle pixel isn't being processed correctly... try it on a contrasty clip (this works for any radius).

looks to be pretty minor though.

[mg262]

Manao,
* added : bool "luma" parameter to mt_merge, which makes it use the luma mask for all three planes, and which forces chroma modes to "process" ( u=v=3 )
Brilliant! Thank you.

[Manao]

With 2.0a22 ? Because it's supposed to be fixed in a22.

[Manao]

Mug Funky : i rechecked, the strings created by mt_circle contain the pixel (0,0), and mt_expand and mt_expand(mt_square(1)) return the same results. Were you using 2.0a21 ?

Anyway, new release because since I released a buggy & slow median mode. Thanks for tsp for the idea that allows to speed the search :

http://manao4.free.fr/masktools-v2.0a23.zip

Changelog from alpha 22 to alpha 23 : * fix & speed up : median mode, thanks to tsp's insightful remarks. Note to self : think
less like a mathematician, and more like a programmer. Simpler, faster & not bugged.

[Mr.Bitey]

Hi Manao,

Repost from Limtedsharpen thread:
Im getting graphedit errors in ZoomPlayer 4.51 (causing ZP to crash-out) using limitedsharpenfaster and mask_tools v2.0a21 after a second or two of dvd playback - no problems if I roll back to v2.0a18..

Cheers,
Bitey