MaskTools 2.0a48

[Richard Berg]

Ok. The version of LimitedSharpen I have works ok on that script.

[foxyshadis]

Manao, would you mind putting masktools html docs on your site as well, so it could be more easily linked to?

[Manao]

Done : http://manao4.free.fr/mt_masktools.html

[foxyshadis]

Posting again, you probably know why by now... Thanks for the docs though!

Looks like vmtoon shows a bug in some sources; I'd seen it reported before but now that I could repro it, I have a nice simple test case.

http://rapidshare.de/files/15864704/...muxed.m2v.html

mpeg2source("Inuyasha_Macroblocking.demuxed.d2v")
mt_Expand()
greyscale

It causes sliding diagonal lines on every frame, looks like some kind of off-by-8 error. Occurs with at least expand and inpand.

[Manao]

I still can't reproduce it .

Two things to try on your side : add a greyscale() in order the chroma not to trouble what you're seeing ( since with your script, chroma is completely randomized ), and try to add "mmx=false, isse=false, d3now=false" in mt_expand(), to see if results are still the same. If not, screenshots would be welcomed ( with them, with some luck, i might be able to find the possible bug ).

[foxyshadis]

I was using greyscale, so it wasn't chroma. isse=false fixes it. Oh, and the lutxy had nothing to do with it, just: mt_Expand() does it for me. Hm. (But not on all sources, especially smaller ones.)



This is a core duo, I don't recall it ever happening on the Pentium M, or the AXP. (Testing now.) Hope it's not a processor bug. >_<

Edit: Tested both, no error on AXP, same error on P-M. Main difference is P-M is SSE2 and AXP is not.

Edit2: Tested with 2.5.6a and it does not show. The AXP uses it, which also explains that. I normally use 2.5.7-cvs from tritical, versions at least since january show this. So now I guess I should take the report over to tritical and IanB?

It only shows on all 720x480 sources, not 320x240 or 704x480 so far.

[foxyshadis]

From PM:

Originally Posted by tritical

I'll look, but I'm guessing off hand that it is a pitch/width problem. In 2.5.6 planar frames by default get 16 byte aligned pitch on Y and 8 on chroma, but in 2.5.7 chroma gets 16 and Y gets 32 which on a 720 width frame means the pitch no longer equals the width (736 vs 720). Whereas on a 704 or 320 width frame pitch will still equal width since both are divisible by 32.

[Manao]

Ok, thanks again for that nice report, I found the bug as soon as I installed avs 2.5.7.

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

Changelog :

Fixed : asm optimizations for mt_inpand/mt_expand/mt_edge ( mostly )

[IanB]

As noted by Tritical, 2.5.7 defaults to mod 16 alignment (SSE2 ready) for the chroma planes and mod 32 (chroma * 2) for the luma planes. This feature was introduced in 2.5.6 but is not enabled by default.

This feature is controlled by the SetPlanarLegacyAlignment(clip, bool) control function, bool==True -> Legacy mod 8 chroma, bool==False -> Advanced mod 16 chroma.

2.5.6 developers should test their plugins for future compatibility with the feature by putting a SetPlanarLegacyAlignment(False) at the end of their script.

In 2.5.7 for non-conformant old pluggins the feature may be restored to legacy mode by putting a SetPlanarLegacyAlignment(True) after the call to the problem pluggin.

In 2.6.0 the default alignment for all planes is 16. The alignment of each plane is independant of the other planes. i.e. your code must get the pitch for each plane independantly, pitch>>=1 will not work! SetPlanarLegacyAlignment only effect YV12 chroma plane alignment, forcing it to be half that of the luma plane.

[redfordxx]

@Manao

Is the speed of
mt_convolution("1 1 1 1 1 1 1 1 0 0 0 0 0 0 0","1 1 1 1 1 1 1 1 0 0 0 0 0 0 0")
and
mt_convolution("1 1 1 1 1 1 1 1 0","1 1 1 1 1 1 1 1 0")
same?

Tnx

[Manao]

No, the filter isn't smart enough to see that zeroes are useless ( and won't, ever ).

[Manao]

Ok, I fixed the bug described here

Changelog :

 * fixed : intern float to integer conversion that were badly rounding negative number.
That resulted in -1.0 been rounded into 0 (!). Most notably affected was mt_convolution.
Thanks redfordxx for pointing that out.

[redfordxx]

a=mt_luts(o1,o1, mode = "avg", pixels = "-1 0 1 0", expr = "y" )
b=mt_luts(o1,o1, mode = "avg", pixels = "0 -1 0 1", expr = "y" )
c=mt_luts(o1,o1, mode = "avg", pixels = "1 -1 -1 1", expr = "y" )
d=mt_luts(o1,o1, mode = "avg", pixels = "-1 -1 1 1", expr = "y" )
e=mt_luts(o1,o1, mode = "max", pixels = "1 -1 -1 1", expr = "y" )
f=mt_luts(o1,o1, mode = "max", pixels = "-1 -1 1 1", expr = "y" )

a,b,e,f works
c,d==>blankscreen in VD-M2

[redfordxx]

BTW: Courious:
Why mt_lutf has no pixels parameter?
It would be useful.
Workaround is mt_luts("y") followed by mt_lutxy but wouldn't it be faster?

[Manao]

Ok, bug found, expect a release tomorrow.

mt_lutf doesn't have a pixel parameter, because its purpose is to adapt a local mask according to the value of the property of the whole picture. I fail to see how a pixels parameter would help. Can you give me an example of what you were thinking about ?

Finally, speed shouldn't be considered when playing with luts / lutf. I didn't inted these filters to be fast, only to be tweakable. Their purpose is to allow scripters who don't know how to code to have tools to make interesting scripts. From that, one could expect interesting filter's idea to come up, which, in turn, could be implemented into real filters, that would be fast.

[redfordxx]

Originally Posted by Manao

Can you give me an example of what you were thinking about ?

s=mt_luts(o1,o1, mode = "avg", pixels = "1 -1 -1 1", expr = "y" )
mt_lutxy(o1,s, expr = "x y > x y ?" )

could be same as

mt_lutf(o1,o1, mode = "avg", pixels = "1 -1 -1 1", expr = "x y > x y ?" )

which would reconstruct diagonal lines..

Their purpose is to allow scripters who don't know how to code to have tools to make interesting scripts. From that, one could expect interesting filter's idea to come up, which, in turn, could be implemented into real filters, that would be fast.

Yeah, that's 100% me.
My SmoothDeblock is slow as hell (0.25fps) and all I can do is to make it even slower. But, if I have time and am lucky, there will be something working from it, and maybe some1 will c-peed up it...

[redfordxx]

Well - throwing ideas:
How about making

mt_freerectangle : int left(0), int top(0), int width(2), int height(2)

So for example
mt_freerectangle(0,0,8,8)
would cover 8x8block right-down from pixel x inclusive

[Manao]

Ok, new version is up : http://manao4.free.fr/masktools-v2.0a30.zip

Changelog :

 * fixed : luts was crashing if some pixels didn't have any neighbours in the pixels list.
 * added : mt_freerectangle, mt_freeellipse and mt_freelosange helpers.

[Manao]

Concerning lutf, it doesn't work like you think. lutf collects information on the whole frame, and compute from that information a single value per frame, defined by the "mode". "avg", for example, will compute the average pixel value for the whole frame, while "range" will compute the difference between the max and the min on the whole frame.

Then, "expr" is a 2 variables lut which will be applied on the whole frame. In that lut, x is the value previously computed, while y is the value of the pixel. So I really can't add a pixel list parameter to lutf.

Concerning the mt_freeforms helpers, just a sidenote : mt_freerectangle(0, 0, 2, 2 ) will create a 3x3 rectangle ( 2 is included ), so if you want a 8x8 rectangle, use (0,0,7,7).

[redfordxx]

Originally Posted by Manao

Concerning lutf, it doesn't work like you think.

Well I already know how it works, but that's why I proposed it as a change. If parameter pixels would be added, then
pixels="" ... current behavior
pixels=someshape ... behaviour like reverse luts

By the way it seems to me now that many operations of luts on square can be done faster with inpand,expand, lutxy, pointresize combo.

For example I am making a function to fill n*n pixels block with its max value with expand-pointrezize combo, because I don't know any other way how to do it. It has nice property that the larger n the faster. (Well, this fact also means that there should be faster solution)

But generally there can be really awsome things done with mt. Nice.

Last question: only being curious, because for implementation is maybe late.
Once I realized that lut works strange and then I realized:
mt_lut("1","2","3")
is not same as
mt_lut(yexpr="1",uexpr="2",vexpr="3")

iirc the defaults in old masktools were different there were only 3 expr parameters. In new masktools are 4 expr. What was there a reason? IMHO something like
yexpr=default(yexpr,"x")
uexpr=default(uexpr,yexpr)
vexpr=default(vexpr,uexpr)
would be best....