MaskTools 2.0a48

[IanB]

Someones got a bug in there code. This is typical when one doesn't clamp arithmetic results to 0 at the low end and 255 at the high end.

In 8 bit unsigned arithmetic 0-1=255 (0=black, 255=white)

[Manao]

New version : v2.0a31

Changelog :

    * fixed : mt_hysteresis was randomly crashing.
    * fixed : mt_polish is back.
    * added : round, clip, min, max and = for lut.
    * adapted : to msvc8 / yasm.

[Manao]

Didee : what you asked for isn't possible with a lut, it would require too big a lut.

Dr Khron, foxyshadis : does anybody still have the problem on the edges reported by Dr Khron ? If yes, can I have something to help me reproduce it ?

[Terranigma]

Thanks for the update Manao

[Terranigma]

Manao, was there some sort of speed tweak involved as well? Seems like it, but maybe i'm just off my engines.

[Manao]

I didn't do anything to make it faster.

[Manao]

New version : v2.0a32

Changelog :

 * added : mt_lutxyz
 * added : mt_lutsx
 * fixed : small memory leak in mt_luts

Basically, mt_lutsx is the filter Didee previously required, and mt_lutxyz is a three clip lut. I changed my position on what "too big" is for a lut. Those filters take some time to initialize ( 3*2^24 values to compute ), something like 5 seconds can be expected. Each instance of those filters takes up 48 MB too.

[check]

Just letting you know there's a typo in the filterlist in the .htm help. 'mt_rectange'

[Spuds]

Not so much a bug as an observation or just a plain mistake on my part.

I was using mt_lutf to see if a frame was over / under a very low threshold, something like:
lutf(mask,mask,mode="avg",expr="x 0.1 > y 0 ?")

and comparing the results to:
ConditionalFilter(mask, nullclp, mask, "AverageLuma()", "<", string(0.1),false)

I was getting different results on what frames got through and realized the mt_lutf was doing the comparison not on the float but on the rounded value of average. I know the final result is a round but expected the float to be maintained through the comparison.

Also found that the averageluma approach was about 30% faster.

[Didée]

Interesting finding on the rounding thing.
The speed difference probably isn't surprising: averageluma operates on just one single clip. LutF/LutS always operate on two input clips, could be this makes the internal pixel shuffling a bit slower.

[Manao]

LutF/S are completely unoptimized, so it doesn't suprises me if they are slow.

As for the rounding, I'll add that to the documentation. It makes sense for me, since the average becomes an entry to a LUT, it must be rounded, but I guess that a programmer's POV, not really a user's POV

[Fizick]

manao, why in your signature the stable version is 2.0a31 and not 2.0a32?

[yup]

Hi folks!
Can I use MaskTools V.2 in Avisynth 2.57 with planar YUY2?
I can get planar using SSETools.

AVISource("a.avi")#YUY2 source
SeparateFields()
Interleaved2Planar()
MaskTools V.2 function
Planar2Interleaved()
Weave()

This will be work?
yup.

[Boulder]

MaskTools requires YV12 input, so you need to convert to YV12 before using any MaskTools functions.

[yup]

Hi Boulder!
This sentence from document.

The filters have a set of common parameters, that mainly concerns what processing to do on each planes. They all work only in YV12 ( though with Avisynth 2.6, support for all planar format will be available ).

We need waiting Avisynth 2.6? I right?
yup.

[Boulder]

I don't know the inner workings of MaskTools, it could (and probably does) mean that the MaskTools code needs some rewriting too.

[Manao]

Internally, it supports everything from 4:0:0 to 4:4:4 planar. I'll see what I can do for avs 2.5 and interleave2planar. It already works for avs 2.6.

[Manao]

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

[XBoy]

How about x64 support?

[Manao]

I can quickly make a x64 version with assembly disabled. I don't think that's what you want, but without having a 64bit OS, I won't do anything more.