MaskTools 2.0a48

[martin53]

I am very happy to find the MaskTools2 b1 wiki page (http://avisynth.nl/index.php/MaskTools2) - thanks! tp7, Kurosu, Manao, mg262 -
and have a question and a feature request.

The question is: do all of the filters in the AviSynth 2.6 version now support all planar 2.6 formats (or at least YV24)? Explicitly it is only stated that mt_merge supports YV24.

The feature request is a new value 6 for u and v and chroma = "follow" setting u = v = 6.
The meaning of 6 should be "process the same U and V pixels as the luma pixels". Maybe my memory tricks me, but when I last worked with the package, I think that edge masks and all that worked completely independently on the three planes when I chose u = v = 3.
Given the problem that I want to isolate areas with not too sharp luma change, I can use the edge function on the luma plane. But then I was interested to also set the U and V components of these same pixels to 128 (or maybe 0 as a special hint value for the next function) for the further processing, and I found that this was hard to achieve: only with a separate Y8 mask clip which was then used on three other Y8 clips, previously separated from the YV24 clip. I hoped that one single function call with u = v = 6 could do the thing much faster.
Sorry what I write remains a bit vague here, will try to find another specific example where it gets clear and edit the post or add a new one.

EDIT I think I cancel the feature request at least for the moment. mt_merge has the 'luma' parameter which fulfills it for mt_merge. It had to do with mt_lutxy etc, where I found it would be useful if one were able to choose, whether for U and V planes, U and V from the 2nd clip are taken, too, or for U Plane of result, U only of clip 1, but Y of clip 2 were used (for V plane of result, V plane of clip 1 and Y plane of clip2). That could simplify some operations, when clip2 is a control clip, but it is possible to create a YV24 control clip with 3 identical planes with YToUV(3 times the same Y8 clip), and surely this is not a widely needed feature.

[Reel.Deel]

The question is: do all of the filters in the AviSynth 2.6 version now support all planar 2.6 formats (or at least YV24)? Explicitly it is only stated that mt_merge supports YV24.

In the last sentence of the introduction (http://avisynth.nl/index.php/MaskTools2#Introduction) it says:
All filters only work with planar colorspaces (Y8, YV12, YV16, and YV24 (AviSynth 2.5.8 only supports YV12!).

It's easy to miss, whenever I get some time I'll make it more obvious.

[martin53]

Thanks, you're right. Not that I Intend to use YV411 ;) but... not YV411?

[Reel.Deel]

Yup, no love for YV411 (I've yet to see anyone complaining, maybe it's because no one really uses it :)) . Anyways, I tried it with YV411 and I got this message:
unsupported colorspace. masktools only support planar YUV colorspaces (YV12, YV16, YV24) (https://github.com/tp7/masktools/blob/master/masktools/common/base/filter.h#L161)

Kind of odd it doesn't mention Y8 since it's indeed supported. :confused:

[LouieChuckyMerry]

Hello, and Happy Saturday! I'm trying to get AviSynth running on my oldest laptop--Windows 7 x64, AMD Turion II M500, 4GB RAM; why waste any encoding time, ha ha--but I'm having problems with MaskTools2. AviSynth is seemingly properly installed, as I can use this setup to successfully encode sources with x264 and no added filters. However, any call requiring MaskTools2 results in the error message "Script error: there is no function named 'mt_xxx'"--"xxx" varies depending on the call--despite the fact that the MaskTools2 .dll is in my plugins folder. I've tried using the newest tp7 and Vit modded .dlls, as well as the standard version, but all result in the same error, like the .dll isn't in my plugins folder even though it is. Perhaps the processor is too old? Is there a simple MaskTool2 call I can use to test things? Thanks for any help.

[Groucho2004]

Hello, and Happy Saturday! I'm trying to get AviSynth running on my oldest laptop--Windows 7 x64, AMD Turion II M500, 4GB RAM; why waste any encoding time, ha ha--but I'm having problems with MaskTools2. AviSynth is seemingly properly installed, as I can use this setup to successfully encode sources with x264 and no added filters. However, any call requiring MaskTools2 results in the error message "Script error: there is no function named 'mt_xxx'"--"xxx" varies depending on the call--despite the fact that the MaskTools2 .dll is in my plugins folder. I've tried using the newest tp7 and Vit modded .dlls, as well as the standard version, but all result in the same error, like the .dll isn't in my plugins folder even though it is. Perhaps the processor is too old? Is there a simple MaskTool2 call I can use to test things? Thanks for any help.
You could run my Avisynth Info Tool (http://forum.doom9.org/showthread.php?t=170647) to see what's wrong. Probably some runtimes missing.

[LouieChuckyMerry]

I actually ran your AviSynthInfoTool before posting, but nothing seemed horribly wrong, which of course means nothing given my ignorance. I probably missed something. What should I look for? Your AviSynthInfoTool indicates that all is well, as far as I can tell.

[feisty2]

got msvcr2012?

[Groucho2004]

What should I look for? Your AviSynthInfoTool indicates that all is well, as far as I can tell.
Did you run Plugin info from the "Tools" menu?

[LouieChuckyMerry]

Did you run Plugin info from the "Tools" menu?

I'm embarrassed to admit that I did not :o . Now having done so, and after staring at the Dependency Walker GUI for a goodly stretch while dreaming of deciphering the hieroglyphics therein, I was ready to return here seeking more help. Then my eye caught feisty2's comment and, after repeating it slowly a few times until my mental switch flicked, I installed Microsoft Visual C++ Redistributable 2012 and solved the problem. A fine way to really enjoy a slight hangover ;) . Anyway, thanks for your help, and AVSInfoTool, and thank you too, fiesty2 :) .

[Groucho2004]

Now having done so, and after staring at the Dependency Walker GUI for a goodly stretch while dreaming of deciphering the hieroglyphics therein, I was ready to return here seeking more help. Then my eye caught feisty2's comment and, after repeating it slowly a few times until my mental switch flicked, I installed Microsoft Visual C++ Redistributable 2012 and solved the problem.
Next version I'll add hints for these MS VC Restributable issues so the user can try these before consulting Dependency Walker.

[LouieChuckyMerry]

Next version I'll add hints for these MS VC Restributable issues so the user can try these before consulting Dependency Walker.

That would certainly make AVSIntoTool even more useful. Perhaps you'd consider a dedicated GUI button, bright and obvious, for "Tools/Plugin Info..." ;) .

[real.finder]

can someone make makstools 2 linked with avstp (http://forum.doom9.org/showthread.php?t=164407) in order to control the number of threads or even turn multithreaded off

I think this will solve QTGMC slowdown issue (http://forum.doom9.org/showthread.php?p=1747055#post1747055) and avs mt crashes

[AzraelNewtype]

can someone make makstools 2 linked with avstp (http://forum.doom9.org/showthread.php?t=164407) in order to control the number of threads or even turn multithreaded off

I think this will solve QTGMC slowdown issue (http://forum.doom9.org/showthread.php?p=1747055#post1747055) and avs mt crashes

The problem was solved on avisynth+ by wildly rewriting its internal buffering code, so I sort of doubt fixing a plugin will do it on its own for vanilla.

[real.finder]

The problem was solved on avisynth+ by wildly rewriting its internal buffering code, so I sort of doubt fixing a plugin will do it on its own for vanilla.

it still there http://forum.doom9.org/showthread.php?p=1744902#post1744902

[TurboPascal7]

Masktools 2 doesn't use threading internally and in fact doesn't know anything about it. So linking it against avstp will solve absolutely nothing.

[StainlessS]

Think I know the answer to this already but,

Is there any way to expand (as in mt_expand()) white on black mask only in 1 direction, ie expand white upwards, or , white downwards ?

(well you can hope, can't you:) )

EDIT:
I am aware of the horizontal and vertical only modes, maybe some kind of convolution would work, if so could you please give solutions for all four directions.
Results need to be 0,255 only.
EDIT: So only originally black pixels should be affected.

[StainlessS]

What, nobody, no idea? EDIT: Clues welcome !

[raffriff42]

maybe some kind of convolution would work...
so only originally black pixels should be affected.
How about mt_expand(mode=something) ?

http://manao4.free.fr/mt_masktools.html#mt_expand_mt_inpand
...
mt_expand, mt_inpand
mode select the local neighbourhood. It can take the values : "square" : 3x3 square neighbourhood - isse optimized. [default]
"horizontal" : 3x1 horizontal neighbourhood.
"vertical" : 1x3 horizontal neighbourhood.
"both" : a 3-long cross ( "horizontal" + "vertical" ) neighbourhood. [like default but with rounder corners]
a custom mode, where you give a list of coordinates. "0 0 -1 0 1 0" is for example equivalent to "horizontal".
OK, the custom mode documentation is pretty unclear, but this is what I found through trial and error:
mt_expand(mode=" 1", chroma="-128") ## shift left
mt_expand(mode="-1", chroma="-128") ## shift right
mt_expand(mode=" 0 1", chroma="-128") ## shift up
mt_expand(mode=" 0 -1", chroma="-128") ## shift down
mt_expand(mode=" 1 1", chroma="-128") ## shift left+up
mt_expand(mode="-1 -1", chroma="-128") ## shift right+down
mt_expand(mode=" 0 0 0 1", chroma="-128") ## expand up
mt_expand(mode=" 0 0 0 -1", chroma="-128") ## expand down
mt_expand(mode=" 0 0 0 0 1", chroma="-128") ## expand left
mt_expand(mode=" 0 0 0 0 -1", chroma="-128") ## expand right
mt_expand(mode=" 0 0 -1 0 1", chroma="-128") ## expand left+right (same as 'horizontal')
mt_expand(mode=" 0 -1 0 1 0", chroma="-128") ## expand up+down (same as 'vertical')
mt_expand(mode=" 0 0 0 1 1", chroma="-128") ## expand left+up
mt_expand(mode=" 0 0 0 -1 -1", chroma="-128") ## expand right+down

EDIT please ignore this...scroll down

[StainlessS]

RaffRiff42, you are my hero

Ta very much :)

[StainlessS]

There seems to be a MaskTools bug when using Expand Left as posted in RaffRiff42 post, two posts ahead #570.
This line

mt_expand(mode=" 0 0 0 0 1", chroma="-128") ## expand left

Assuming that the line is not in error.

This script weirdly exhibits the problem

BlankClip(pixel_Type="YV12")
Subtitle("Whats the recipe today Jim ...",align=5)
mt_expand(mode=" 0 0 0 0 1", chroma="-128") # expand left
Greyscale


Load into VDubMod, and repeatedly press one of the refresh keys (F5 or F7)

You will sometime get one of the below results, sometimes the other,

https://s20.postimg.cc/p5qwj5u2l/One_zpsrvcxitha.png (https://postimg.cc/image/4lm2koebd/)

https://s20.postimg.cc/u5sy4up31/Two_zpszptq3tfn.png (https://postimg.cc/image/5pasadoc9/)

There is something not quite right somewhere :confused::confused:

EDIT: XP32. AVS v2.6. Masktools latest on Wiki.

[Gavino]

There seems to be a MaskTools bug when using Expand Left as posted in RaffRiff42 post, two posts ahead #570.
This line

mt_expand(mode=" 0 0 0 0 1", chroma="-128") ## expand left

Assuming that the line is not in error.
Since (as the docs state) the numbers represent coordinates, there should be an even number of them.
Here you have (0,0), (0,0), (1,?), with one coordinate incomplete (and the other two being equal).
This probably gives rise to undefined behaviour within MaskTools.
Try "0 0 1 0", or "-1 0 0 0".

[StainlessS]

Thanx big G, that explains it just fine :)
Was drivin' me nuts because I kept gettin' different results.

[raffriff42]

OK sorry, I had mt_convolution arguments on the brain there.
So mode seems to be a list of (x,y) coordinates, relative to the current pixel (0,0).
The coordinate system is as follows (EDIT: updated in light of Gavino's post #582 (http://forum.doom9.org/showthread.php?p=1780550#post1780550))Above,left
-1,-1 0,-1 1,-1
-1,0 0,0 1,0
-1,1 0,1 1,1
Below,rightThe coordinates can extend beyond what's shown here (±1 horizontal & vertical), to at least ±1000. The list of coordinates can be in any order.

Each pixel is replaced by its local maximum : the brightest pixel in its "local neighborhood," as defined by the mode argument.

For example, mt_expand(mode="0 0 -1 0") defines a local neighborhood of two pixels: the source pixel itself (0,0) and the one to its left (-1,0). In the output, bright areas will appear to "expand" to the right.
(end of edit)

So my previous post should have been something like:mt_expand(mode="-1 0", chroma="128") ## shift right
mt_expand(mode="-1 0 0 0", chroma="128") ## expand right

mt_expand(mode=" 0 1", chroma="128") ## shift up
mt_expand(mode=" 0 1 0 0", chroma="128") ## expand up

mt_expand(mode=" 0 -1", chroma="128") ## shift down
mt_expand(mode=" 0 -1 0 0" , chroma="128") ## expand down

mt_expand(mode=" 1 1", chroma="128") ## shift left+up
mt_expand(mode=" 1 1 0 0", chroma="128") ## expand left+up

mt_expand(mode="-1 -1", chroma="128") ## shift right+down
mt_expand(mode="-1 -1 0 0", chroma="128") ## expand right+down

mt_expand(mode=" 1 0 0 0 -1 0", chroma="128") ## expand left+right (same as 'horizontal')
mt_expand(mode=" 0 1 0 0 0 -1", chroma="128") ## expand up+down (same as 'vertical')

[StainlessS]

You are still my hero Raff, we got it sorted now. :)

You might want to copy over the fixed list to the original post.

EDIT: You seem to have missed out

mt_expand(mode=" 1 0", chroma="-128") ## shift left
mt_expand(mode=" 1 0 0 0", chroma="-128") ## expand left

[raffriff42]

Didn't miss it - omitted it on purpose! My trick seems to have worked!

OK let's have some demo images, and experiment with mt_square, mt_diamond and mt_circle
These func's generate strings you can use as mode arguments. So there's no longer any need for...mt_expand.mt_expand.mt_expand.mt_expand.mt_expand.mt_expand # ...etc

https://www.dropbox.com/s/qz1wuqhmcf6usmc/mtexpand-test-00-org.png?raw=1 https://www.dropbox.com/s/hpuiiwpvymlqe2d/mtexpand-test-01b-down-x3.png?raw=1 https://www.dropbox.com/s/tszsgb7wwxqgzkv/mtexpand-test-02-sq-x4.png?raw=1 https://www.dropbox.com/s/19wfasc2lmsmi0u/mtexpand-test-03-sq-x16.png?raw=1 https://www.dropbox.com/s/8l9h1wzwoxvyuue/mtexpand-test-04-dia-x16.png?raw=1 https://www.dropbox.com/s/vzuzxl7zz3ipuir/mtexpand-test-05-circ-x16.png?raw=1


BlankClip(width=260, height=120, pixel_type="YV12", color=$0)
Subtitle("M A S K\n- - - -", size=Height/3, align=5, text_color=$ffffff, lsp=0)
AddBorders(8, 8, 8, 8, $ffffff)
AddBorders(48, 32, 48, 32, $0)

return Interleave(
\ EvalShow2("""# (input)""")
\ , EvalShow2("""mt_expand(mode="0 -1 0 0", chroma="-128") # down""")
\ , EvalShow2("""mt_expand(mode="0 0 -1 -1 -2 -2 -3 -3", chroma="-128") # down-right x3""")
\ , EvalShow2("""mt_expand(mode=mt_square(radius=4, zero=true), chroma="-128")""")
\ , EvalShow2("""mt_expand(mode=mt_diamond(radius=4, zero=true), chroma="-128")""")
\ , EvalShow2("""mt_expand(mode=mt_circle(radius=4, zero=true), chroma="-128")""")
\ , EvalShow2("""mt_expand(mode=mt_square(radius=16, zero=true), chroma="-128")""")
\ , EvalShow2("""mt_expand(mode=mt_diamond(radius=16, zero=true), chroma="-128")""")
\ , EvalShow2("""mt_expand(mode=mt_circle(radius=16, zero=true), chroma="-128")""")
\ )

### execute a script snippet and show it on screen
function EvalShow2(clip C, string s)
{
C
Eval(s)
Subtitle(s, size=12, align=1)
return Last
}

[colours]

These func's generate strings you can use as mode arguments. So there's no longer any need for...mt_expand.mt_expand.mt_expand.mt_expand.mt_expand.mt_expand # ...etc

What?

The mt_expand chain is good because the square and diamond modes are SIMD-optimised, whereas the custom modes aren't. (And obviously using a chain is O(n) whereas specifying all the pixels is O(n^2), so even if SIMD optimisations weren't relevant, you still lose out.)

Just for comparison, mt_expand_multi(sw=10,sh=10) runs about 477 times as fast as mt_expand(mode=mt_square(radius=10)) on my old and flaky laptop (815.2 fps versus 1.709 fps).

There's also a constant-time algorithm for the specific case of rectangular erosion and dilation (http://www.sciencedirect.com/science/article/pii/016786559290069C), but practically speaking, the O(n) algorithm is fast enough for reasonable radii.

[StainlessS]

Very sexy :)

But how would cope with something like,

HALO_L = 3 # Left Halo width in pixels
HALO_R = 4 # Right Halo width in pixels
HALO_T = 5 # Top Halo height in pixels
HALO_B = 6 # Bot Halo height in pixels

Above, as now implementing the subtitle detector.

[raffriff42]

@colours, I spoke before testing it. You are right of course, thank you.

@StainlessS, this seems to be accurate ± one pixel:
(EDIT rewritten with mt_expand_multi, part of Dither_tools (http://avisynth.nl/index.php/Dither_tools#Content))
https://www.dropbox.com/s/cjj7vzqaclf3p6q/mtexpand-test-10-3456-over.png?raw=1#M=mt_expand(255, 0,
#\ mt_rectangle(
#\ Round(0.5*(HALO_L+HALO_R)),
#\ Round(0.5*(HALO_T+HALO_B))),
#\ chroma="copy") ## 32fps
M=mt_expand_multi(
\ sw=Round(0.5*(HALO_L+HALO_R)),
\ sh=Round(0.5*(HALO_T+HALO_B)),
\ chroma="copy") ## 220fps
M=M.UUOffsetF(HALO_R-HALO_L, HALO_B-HALO_T)

## test - show semitransparent mask
return Overlay(M, mode="lighten", opacity=0.75)

## shift a clip up-down and left-right (sub-pixel shift)
function UUOffsetF(clip C, float offh, float offv) {
return C.BilinearResize(Width, Height, -offh, -offv, Width, Height)
}

Here is a function to work with half-size custom masks for an approximate 10x speedup. (EDIT deleted it; use above)
StainlessS, you could hack this for your needs.
Note the built-in "free" blurring; you're gonna want that, or something like it. (EDIT use GaussianBlur or something)
https://www.dropbox.com/s/11wj55lb9fbisj9/mtexpand-test-11-ex2.png?raw=1

[StainlessS]

Dear me !!!
You seem to have the bull by the horns :)

I cant actually feather until after detection with RT_YInRangeLocate(), so we need full size masks.

I'll have another look in the morrow, got to get some sleep before I fall down.

EDIT: Rethink, maybe I can.
Edit, nah, forget that.

[Gavino]

So mode seems to be a list of (x,y) coordinates, relative to the current pixel (0,0). The coordinate system is as follows:Above,left
1,1 0,1 -1,1
1,0 0,0 -1,0
1,-1 0,-1 -1,-1
Below,rightThe coordinates can extend beyond what's shown here (±1), to at least ±1000.

The pixel value at (0,0) is copied to each relative coordinate point in the list. If there are overlaps, the brightness values are OR'd together.
Perhaps you already know this, but your description works only for masks that contain just 0 and 255.
More generally, what the filter actually does is to replace each pixel by the maximum from its local neighbourhood, which is defined according to the mode.
The coordinate system used for mode is the other way round:

Above,left --> x
-1,-1 0,-1 1,-1 |
-1,0 0,0 1,0 v y
-1,1 0,1 1,1
Below,right

In the case of (0,255) masks, the overall effect is the same as with your description, but that's not how the filter actually works.

[raffriff42]

Thanks Gavino. Re-reading the documentation (http://manao4.free.fr/mt_masktools.html#mt_expand_mt_inpand)now, it actually makes sense. If you could similarly elucidate mt_hysteresis ("Grows the small mask into the big mask by connex components"), I would really appreciate it.

[StainlessS]

Thanks Gavino... If you could similarly elucidate mt_hysteresis ("Grows the small mask into the big mask by connex components"), I would really appreciate it.

++ on that :)

[Gavino]

If you could similarly elucidate mt_hysteresis ("Grows the small mask into the big mask by connex components"), I would really appreciate it.
I could never understand that one either, so I asked the question myself some time ago.
Here is the reply by cretindesalpes:
mt_hysteresis will keep each solid areas of the second mask depending if there is at least one pixel of the first mask in these areas. It's like a fill function trying to color the second mask from each pixel set in the first mask. Masks are considered as binary, so you'll need some mt_merge wizardry to restore the shades of grey.
See also this thread: Use spots from one mask to select spots on another mask

[StainlessS]

That hit the spot (so as to speak) big G. :thanks:

[blaze077]

Could someone explain to me how mt_luts and mt_lutsx work?

From what is written in the documentation:
It computes the mode operation on the result of the function defined by expr, where x is the pixel from clip1, and y a pixel from the neighbourhood in clip2, defined by pixels.

I do not understand how the neighbourhood value is calculated. Does it take the value of the central pixel or does it calculate the average of all the pixels?

Also, is there a description of mt_lutsx somewhere?

Thank you.

[Gavino]

I do not understand how the neighbourhood value is calculated. Does it take the value of the central pixel or does it calculate the average of all the pixels?
The form of the neighbourhood is defined by the pixels argument of the filter.
The simplest way to supply this is to use one of the helper functions. For example, pixels=mt_square(1) defines the 3x3 neighbourhood surrounding the pixel being processed.
By default, the helper functions include the centre pixel - to omit it, add zero=false to the arguments of the helper.
If none of the helper functions give you the neighbourhood you want, you can instead supply for pixels an arbitrary list of relative coordinates to define your own neighbourhood. See post #581 above for how these coordinates work.

The function mt_luts() itself works as follows.
For each output pixel:
1) Set x = corresponding pixel in input clip1
2) For each pixel in the corresponding neigbourhood of input clip2, set y to the value of that pixel and compute the relevant expression (from expr, etc). This give a set of results (one for each neighbourhood pixel).
3) The mode function (eg avg) is then applied to that set to give the value of the output pixel.

Also, is there a description of mt_lutsx somewhere?
It's in the MaskTools docs - here's my understanding of it.
mt_lutsx() has three input clips (clip, clip1 and clip2) and works differently from mt_luts().
Here, for each pixel:
1) Set x = pixel from clip
2) Set y = result of computing the mode function on the neighbourhood pixels of clip1
3) Set z = result of computing the mode2 function on the neighbourhood pixels of clip2
4) Compute the relevant expr to give the value for the output pixel.

[blaze077]

Thank you for your explanation, Gavino. But I'm still not clear about one thing.

2) For each pixel in the corresponding neigbourhood of input clip2, set y to the value of that pixel and compute the relevant expression (from expr, etc). This give a set of results (one for each neighbourhood pixel).

So if a pixel is not included in the neighbourhood, then are the expression and mode both not carried out on that excluded pixel, or is the expression carried out and not the mode or vice versa?

[StainlessS]

Dont know if this will help at all, but this Didée post seems to be the one upon which mt_lutsx is based:- http://forum.doom9.org/showthread.php?p=987955#post987955

[Gavino]

So if a pixel is not included in the neighbourhood, then are the expression and mode both not carried out on that excluded pixel, or is the expression carried out and not the mode or vice versa?
My understanding (just from the docs - I can't remember ever actually using it!) is that if a pixel (from clip2) is not in the neighbourhood, it is simply ignored and does not contribute to the result.

For a given output pixel, the expression is evaluated for each clip2 pixel in the corresponding neighbourhood positions, and then the mode function is applied to the set of results obtained.

So in the case of a 3x3 neigbourhood and mode="avg", it evaluates the expression separately for each of the nine neighbourhood pixels, then takes the average of those nine expression results to compute the value of the output pixel.

[blaze077]

Thank you, Gavino. Now I understand how it works.

Dont know if this will help at all, but this Didée post seems to be the one upon which mt_lutsx is based:- http://forum.doom9.org/showthread.php?p=987955#post987955

Indeed, that looks like mt_lutsx. Seems I will have to improve on my Math to understand a lot of new things. :)

[real.finder]

Annoying things in masktools

aside of 422 support lack in luma=true in mt_merge, that already support in dither_merge16

luma=true with Y8 in mt_merge, ex:- https://github.com/tp7/masktools/issues/19

it should be 'luma' parameter is ignored for input clip without chroma channel as tophf said there

and another annoying thing is if U=3 or V=3 with Y8 clip then I will get error message, it should (or better) u and v ignored in Y8/Y clip

[pinterf]

Good evening. Hey, I have successfully compiled tp7's project under vs2015.

@real.finder:
mt_merge: luma=true with 422 is done, autofallback to chromaless mode on Y-only clip is done.

Just saying, that the work on 16 bit masktools has been started, using tp7's 16bit branch which was unfortunately abandoned much earlier than the final 8 bit release but nevertheless, quite usable.

The high bit depth addition to the framework is done, all avs+ color spaces, including planar rgb will be supported, though float will going to be supported only in phase two I think. Now come the filters one by one. The original code was aimed to work on 16 bit data only, I have to support 10-16 bits.

The first bird, binarize_16 is working nice in native 10-16 bits. Next is mt_merge16, these are classic filters, no expressions, they are very good for getting into closer relationship with the code.
You can follow the project here (https://github.com/pinterf/masktools)

[real.finder]

Good evening. Hey, I have successfully compiled tp7's project under vs2015.

@real.finder:
mt_merge: luma=true with 422 is done, autofallback to chromaless mode on Y-only clip is done.

Just saying, that the work on 16 bit masktools has been started, using tp7's 16bit branch which was unfortunately abandoned much earlier than the final 8 bit release but nevertheless, quite usable.

The high bit depth addition to the framework is done, all avs+ color spaces, including planar rgb will be supported, though float will going to be supported only in phase two I think. Now come the filters one by one. The original code was aimed to work on 16 bit data only, I have to support 10-16 bits.

The first bird, binarize_16 is working nice in native 10-16 bits. Next is mt_merge16, these are classic filters, no expressions, they are very good for getting into closer relationship with the code.
You can follow the project here (https://github.com/pinterf/masktools)

:goodpost:

just wonder, the existing script that use 0-255 range (in lut or other) will work in more than 8 bit? or we will need to edit hundreds of .avsi?

[DJATOM]

Guess it's sane to introduce option for automatic range scaling or implement it by default.

[pinterf]

New toy, but do not delete your existing masktools versions, although the previous (2.0b1) version had a rather nasty bug.
Report back how it works, speedwise, new bugs, etc., and a big thanks to tp7.

I actually spent more time with coding than doing tests, but nevertheless the filters were tested to give visually identical results for 8 bit, stacked 16 bit, native 10 and 16 bit processing.

Masktools v2.2 - test (https://github.com/pinterf/masktools/releases/tag/2.2.0)

### MaskTools 2 ###

Masktools2 v2.2.0.0 (20170212)

Test version

Changed:
- mt_merge accepts 4:2:2 clips when luma=true
- mt_merge to discard U and V automatically when input is greyscale
- Some filters got native 10-16 bits support with recent Avisynth+ versions for YUV and planar RGB data
(no alpha plane at the moment)
- 16 bit filters accept stacked clips. Specify stacked=true for them.
Stacked support is not intentional, but since tp7 did it, I did not remove the feature.
Filters that will be ported later, probably will not support stacked format.
- Compiled with Visual Studio 2015 Update 3,
with XP support in mind
(but it does not work :(
remark: it seems that mt_infix and mt_polish uses boost spirit vc140 library, if these
boost libs (named vc140) are linked to the masktools dll, then it is not loading in XP.)
Require VS2015 Update 3 redistributables.

Fix
- mt_merge (and probably other multi-clip filters) may result in corrupted results
under specific circumstances, due to using video frame pointers which were already released from memory

New filters that work for 10-16 bit data on Avisynth+ or stacked data on previous Avisynth versions
- mt_binarize16
- mt_lut16
- mt_logic16
- mt_merge16
- mt_average16
- mt_makediff16
- mt_adddiff16
- mt_clamp16
- mt_inflate16, mt_deflate16
- mt_inpand16, mt_expand16

Notes:
- There is no automatic range scaling in expressions.
- In future versions the base filters (e.g. mt_merge) will accept any-format clip automatically.
No separate mt_merge16 will be necessary for non-8 bit clips.

Masktools2 info:
http://avisynth.nl/index.php/MaskTools2

Project:
https://github.com/pinterf/masktools/tree/16bit

Original version: tp7's MaskTools 2 repository.
Thanks tp7, you did a great job.
https://github.com/tp7/masktools/

[yup]

pinterf!
:thanks:
I am testing on my scripts and see some speed up. luma=true help me (for main filter), now I can full colour from my source (captured VHS YUY2) without additional trick. Some filter do not support YV16, but this not problem because I am using only luma plane for this plugin.
yup.

[real.finder]

Masktools v2.2 - test (https://github.com/pinterf/masktools/releases/tag/2.2.0)


:thanks:

I try it in VirtualBox with winxp but can't load it by loadplugin(), will get error 0x3e6

and something else, b1 and a48 don't supports yv411 and if anyone work with ntsc dv will need to convert color format just for this, so can we have yv411 supports too?

[tormento]

New toy, but do not delete your existing masktools versions, although the previous (2.0b1) version had a rather nasty bug.
Works ok here. Minor fps improvement ~1,5%, no visible artifacts or problems.

[DJATOM]

pinterf
Native mode is broken: http://diff.pics/fJ6BMfn0glF4/1