MaskTools 2.0a48

[jmac698]

manao,
Could you please update the documentation page on your webserver to a48, it's confusing several people. Thanks.

(again, my message above was updated to reference the new mt_line function)

[jmac698]

Another bug:

shift=stackvertical(src.blankclip(color_yuv=$000000,height=240),src.blankclip(color_yuv=$080000,height=240))
src=colorbars(pixel_type="YV12")
src_16=src.shift(-16,0)#shift to right 8 pixels
mt_lutxyz(src, src_8, shift, expr="z 8 & y x ?",chroma="process")

This should result in the bottom half shifted, but the chroma is acting like copy second even though I specified process. I should get chroma from either x or y.

[Manao]

jmac698 : This should result in the bottom half shifted, but the chroma is acting like copy second even though I specified process. I should get chroma from either x or y.No. color_yuv = $080000, so z 8 & for U & V is always false. Use color_yuv = $080808 instead (that is, if I understand what you're wanting to do...)

As for the rest :
- Zero parameter is buggy for all form creators. Instead of removing (0, 0), it only keeps pixels with x or y equal to 0.
- I'll remove default values from the form creators documentation.
- If you still need to find the minimum value on a line : try recursively do the following : src1 = mt_luts(src, src, mode = "min", pixels = "0 0 1 0").pointresize(src.width / 2, src.height)
src2 = mt_luts(src1, src1, mode = "min", pixels = "0 0 1 0").pointresize(src1.width / 2, src1.height)
etc...It'll even be faster with mt_inpand(mode = "horizontal").pointresize(width / 3, height), since that one runs in SIMD
- I'll try printing a nice error message whenever resolutions don't match.

[jmac698]

Manao,
Thanks so much! I was stuck at the problem. I think it would be nice to have a special luma mode just like in mt_merge. Anyhow, I'll have to copy the luma over to u,v to make it work.

Feel free to include mt_line in your package, if you want, I know that two people have found it useful at least. I declare is GPL. There, takes care of the formalities :)

Thanks for the speed tip, I see what you're doing there. You can see how nice it would be in this case if I could run the analysis just once and fill the entire line (pixels) with the min (mode) values. I can see other uses for this, such as blurring out faces or making a mosaic, what do you think? I think a flexible approach would be a stepX and stepY. So a mosaic would be mt_square(8), stepX=8, stepY=8, mode="avg". Now that's nice :)

Another thought - instead of luma modes, a really flexible approach would be to be able to refer to the other color planes in the expression, so I could do z.y & 8. You could also use this to do colorspace conversion. I've wished for this many other times too. I've wanted to do more than lutxyz and I could start using color planes as calculation proxies :) This is just from the user perspective; I don't know what this implies behind the scenes.

In general I'm getting to a point where I really need to start making plugins, but for now I still think scripting for prototyping is easier to develop.

[jmac698]

Bug?
I compared these

#mt_luts(w=256,last, last, mode="min", pixels=linecoord, expr="y")
mt_inpand(w=256, mode=linecoord)

I'm getting some weird issues, the entire screen was black even though the cursor showed y=255. I refreshed a few times and then the screen turned green. I also tried process chroma to make sure, it's still unstable.

[SSH4]

mod4, yv12?

[redfordxx]

Hi, after long time...
Manao, I have few efficiency questions.
1) I have no idea how fast is the lookup, so... is better to use two chained lutxy than one lutxyz when possible?
2) Do functions like mt_luts and mt_lutsx behave differently (more efficiently) when there is one variable missing in the expression, or it is always same procedure?
3) Is mt_lutspa calculated only once or every frame?

Thanx

R.
BTW: accidentally found out this:
mt_luts(mode="1 1 1 -1"), pixels="-1 0 0 0 1 0"...)
Interesting...I don't know whether that's feature or bug, but keep it...it can do nice things

[redfordxx]

Moreover, I have new feature proposal:
It would be some kind of "downscale" parameter for functions which operate on field of values (convolution, luts, lutf...not lutxy, lut)

The idea is, that I need only some of the values and not all in the frame...
I better start with example:
I need to calculate range of pixels every 8x8 block. How do I do it?
mt_luts(mode="range", pixels="mt_freerectangle(0,0,7,7),........)
PointResize(w/8,h/8)
PointResize(w,h)
Now I have what I needed....every block of the video has the "color of difference" of its max and min.
However, I needed only 1/64 values I calculated...which is very unefficient.
Better would be:
mt_luts(mode="range", pixels="mt_freerectangle(0,0,7,7),downscalex=8,downscaley=8........)
PointResize(w,h)

Thanx for considering it;-)
R.

[jmac698]

Yep, that's exactly the feature I need. I proposed a general stepx, stepy parameters to process in tiles.
In your case just stepx=8, stepy=8

[cretindesalpes]

I need to calculate range of pixels every 8x8 block. How do I do it?

Anything using pixels=... will be excessively slow. Try this, instead (set uv according to your needs) :
uv = 1

w = Width ()
h = Height ()

w1 = (w + 15) / 16 * 2
h1 = (h + 15) / 16 * 2

PointResize (w1 * 9, h1 * 9, 0, 0, w1 * 8, h1 * 8)
mi = mt_inpand (u=uv, v=uv)
ma = mt_expand (u=uv, v=uv)
mi = mi.PointResize (w1 * 3, h1 * 3, 1, 1, w1 * 9, h1 * 9)
ma = ma.PointResize (w1 * 3, h1 * 3, 1, 1, w1 * 9, h1 * 9)
mi = mi.mt_inpand (u=uv, v=uv)
ma = ma.mt_expand (u=uv, v=uv)
mi = mi.PointResize (w1, h1, 1, 1, w1 * 3, h1 * 3)
ma = ma.PointResize (w1, h1, 1, 1, w1 * 3, h1 * 3)
mt_lutxy (ma, mi, "x y -", u=uv, v=uv)
PointResize (w1 * 8, h1 * 8)
Crop (0, 0, w, h)

[jmac698]

Interesting... it seems you are performing inpand/expand on 3 different scales in order to cover an 8x8 area, then simply subtracting the results to get the range. It's very fast. Expand is the maximum in a 3x3 pixel area, inpand is the minimum.
There's still some redundancy however?

[redfordxx]

Anything using pixels=... will be excessively slow. Try this, instead (set uv according to your needs) :


Yep, but when there is more complex op...similar things won't help...

Btw, looking at your signature...just few days ago I found about dither..awesome stuff

[redfordxx]

stepx=8, stepy=8
even better idea....not always resize suitable...

[redfordxx]

Try this, instead (set uv according to your needs) :

At second look, it won't work for chroma...some shifting needed...maybe using mt_convolution ("0 0 1","0 0 1"...

I dont know how else to shift clip

[jmac698]

function shift(clip v, float x, float y) {
v#shift an image, x>0 shifts left, y>0 shifts up
bilinearresize(last.width,last.height,x,y,last.width,last.height)
}

[redfordxx]

function shift(clip v, float x, float y) {
v#shift an image, x>0 shifts left, y>0 shifts up
bilinearresize(last.width,last.height,x,y,last.width,last.height)
}

1]i dont think is more efficient than mt_convolution
2]i need to shift the chroma half the speed of luma

[redfordxx]

played a little and made it more general...on block size 27 I really tested it its more efficient than luts
may not work correctly when bx != by
w = c.Width
h = c.Height
w1 = ((w + 2*bx-1) / bx/2) * 2
h1 = ((h + 2*by-1) / by/2) * 2
bx1=int(Pow(3,Ceil(log(bx)/log(3))))
by1=int(Pow(3,Ceil(log(by)/log(3))))
#min max per block
c1=c.PointResize(w1 * bx1 , h1 * by1 , 0, 0, w1 * bx , h1 * by)
mi = c1.mt_inpand (y=y, u=u, v=v).mt_convolution("0 0 1","0 0 1",y=2,u=u, v=v).PointResize (w1 * bx1 / 3, h1 * by1 / 3, 1, 1, w1 * bx1, h1 * by1)
ma = c1.mt_expand (y=y, u=u, v=v).mt_convolution("0 0 1","0 0 1",y=2,u=u, v=v).PointResize (w1 * bx1 / 3, h1 * by1 / 3, 1, 1, w1 * bx1, h1 * by1)
mi = (bx1<9) ? mi : mi.mt_inpand (y=y, u=u, v=v).mt_convolution("0 0 1","0 0 1",y=2,u=u, v=v).PointResize (w1 * bx1 / 9, h1 * by1 / 9, 1, 1, w1 * bx1 / 3, h1 * by1 / 3)
ma = (bx1<9) ? ma : ma.mt_expand (y=y, u=u, v=v).mt_convolution("0 0 1","0 0 1",y=2,u=u, v=v).PointResize (w1 * bx1 / 9, h1 * by1 / 9, 1, 1, w1 * bx1 / 3, h1 * by1 / 3)
mi = (bx1<27)? mi : mi.mt_inpand (y=y, u=u, v=v).mt_convolution("0 0 1","0 0 1",y=2,u=u, v=v).PointResize (w1 * bx1 /27, h1 * by1 /27, 1, 1, w1 * bx1 / 9, h1 * by1 / 9)
ma = (bx1<27)? ma : ma.mt_expand (y=y, u=u, v=v).mt_convolution("0 0 1","0 0 1",y=2,u=u, v=v).PointResize (w1 * bx1 /27, h1 * by1 /27, 1, 1, w1 * bx1 / 9, h1 * by1 / 9)
mt_lutxy (ma, mi, "x y -", y=y,u=u, v=v)
PointResize (w1 * bx, h1 * by)
Crop (0, 0, w, h)

I wonder if using nonsquare morfology drops the efficiency..

When I am writing scripts, I always also wonder, whether avisynth is "smart enough" to ignore unused clips... so the lines bx1<27 and whatever more does not affect the processing when the bx is 9...

[Gavino]

When I am writing scripts, I always also wonder, whether avisynth is "smart enough" to ignore unused clips... so the lines bx1<27 and whatever more does not affect the processing when the bx is 9...
That's right.
The unused branch of a conditional is not even evaluated.

[redfordxx]

And how about this one:
function F (clip c, int b)
{

e=blabla..lot of something computing

d= (b==0) ? c : e
return d
}
Or even
function F (clip c, int b)
{

e=blabla..lot of something computing

d=c
return d
}Or
function F (clip c, int b)
{
c
blabla..lot of something computing

d=c
return d
}
Is "blabla" ignored in these cases?

[redfordxx]

fc1=c.mt_convolution(horizontal="0 1 1",vertical="0 1 1", y=y,u=u, v=v)
fc2=c.mt_convolution(horizontal="0 1 1",vertical="0 1 1.0", y=y,u=u, v=v)
gives different results. Namely the float version is mostly one bit darker.
I know that one is calculated in float and one not, but in this case, shouldn't it be same? Probably differently solved rounding or truncating the result?

[Gavino]

Is "blabla" ignored in these cases?
In each example, it will not be used at 'run-time', ie no video frames will be requested from the filters concerned. However, it is still processed at 'compile-time', which means the expression is evaluated and the filters are loaded, potentially taking time and memory. Some filters reserve memory on startup, others do not, and this is not necessarily related to the complexity of processing it would do later on to deliver video frames.

Note then the difference between
e=blabla..lot of something computing
d= (b==0) ? c : e
and
d= (b==0) ? c : blabla..lot of something computing
In both cases, if b=0, the blabla expression is not used at run-time.
But in the first case, it is evaluated at compile-time with the potential consequences I described.

Since this is the MaskTools thread, it's worth mentioning that mt_lutxyz is a prime example of a filter that uses a lot of time and memory at startup, and so if it is to be used only conditionally in a script, is best called in a conditional statement.

[redfordxx]

Hi please can anyone tell me, why the two following methods to calculate SAD (average of absolute differences in this case) over block give different results? And significantly, not just rounding error...function SAD(clip o)
{
y=3
u=3
v=3
#dimensions prep
bx=8
by=8
w = o.Width
h = o.Height
w1 = ((w + 2*bx-1) / bx/2) * 2
h1 = ((h + 2*by-1) / by/2) * 2
hor=(((bx % 2)==0) ? "0 " : "")+RightStr("1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1",bx*2-1)
ver=(((by % 2)==0) ? "0 " : "")+RightStr("1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1",by*2-1)
#sad method 1
c1= o.PointResize(w1*bx, h1*by, 0,0, w1*bx, h1*by)
c_avg= c1.mt_convolution(horizontal=hor,vertical=ver, y=y,u=u, v=v)
c_avg= mt_luts (c_avg,c_avg,mode="min",pixels=string((bx+1)/2-1)+" "+string((by+1)/2-1), expr="y", y=y,u=u, v=v)
c_avg= c_avg.PointResize(w1, h1, 0, 0, w1*bx, h1*by).PointResize(w1*bx,h1*by)
c_sadc= mt_lutxy(c_avg,c1,"x y - abs",y=y,u=u,v=v)
c_sadc=c_sadc.mt_convolution(horizontal=hor,vertical=ver, y=y,u=u, v=v)
c_sadc= mt_luts (c_sadc,c_sadc,mode="min",pixels=string((bx+1)/2-1)+" "+string((by+1)/2-1), expr="y", y=y,u=u, v=v)
c_sadc=c_sadc.PointResize(w1, h1, 0, 0, w1*bx, h1*by).PointResize(w1*bx,h1*by).Crop(0,0, w, h).Subtitle("sadc")
#sad method 2
c1= o.PointResize(w1*bx, h1*by, 0,0, w1*bx, h1*by)
c_avg= mt_luts(c1 ,c1,mode="avg", pixels=mt_freerectangle(0,0,bx-1,by-1), expr="y",y=y,u=u,v=v)
c_sadl= mt_luts(c_avg,c1,mode="avg", pixels=mt_freerectangle(0,0,bx-1,by-1), expr="y x - abs",y=y,u=u,v=v)
c_sadl=c_sadl.PointResize(w1, h1, 0, 0, w1*bx, h1*by).PointResize(w1*bx,h1*by).Crop(0,0, w, h).Subtitle("sadl")
Interleave(c_sadl,c_sadc)
return last
}

I have the results of the functions interleaved for better visual comparision and labeled. sadc is much faster than sadl...

EDITED: now I tested sadc gives correct results and sadl wrong

[redfordxx]

In each example, it will not be used at 'run-time', ie no video frames will be requested from the filters concerned.


Well, to be exact on this, I ended up with millions of conditions. Messy.
So I decided to write everything with Eval function.

I believe Eval() is processed at startup time, so there will be no inefficiency, right?

[Gavino]

Well, to be exact on this, I ended up with millions of conditions. Messy.
So I decided to write everything with Eval function.

I believe Eval() is processed at startup time, so there will be no inefficiency, right?
That's right.
I take it you mean you are doing things like:
condition ? Eval("""
... statements ...
""" : Eval("""
... other statements ...
""")

You might find it useful to use the if-else construct of GScript, which is less ugly and allows arbitrarily nested conditions.

[redfordxx]

So, back to my question some time ago...I did some performance testing...lutspa renders every frame again and again...is tiny piece faster than lut and twotimes slower than eg merge or makediff. So, before this is fixed this is the workaround with zero processing demand:mt_lutspa(o1,"x", y=3,u=3,v=3).trim(1,1).Loop(o1.framecount,0,0)

[IanB]

Nitpick:-).trim(0,-1).is preferred over).trim(1,1).The 1,1 fails for 1 frame clip case and requests frame 1 from the downstream graph instead of frame 0.

Also the trim plus loop method affect the audio. FreezeFrame(0, FrameCount()-1, 0) may be a viable alternative if audio matters.

[redfordxx]

Also the trim plus loop method affect the audio. FreezeFrame(0, FrameCount()-1, 0) may be a viable alternative if audio matters.
Trim, understood, Freezeframe not OK.
Freezeframe doesnot kill the CPU time.

For example my measurements:
testclips o1,o2,o3=Blankclip YV12 8192x4096 500frames

Cpu time in seconds
o1...........................0
mt_merge(o1,o2,o3)....... ..16
mt_lutspa(o1)...............27
mt_lutspa.trim.freezeframe....27
mt_lutspa.trim.loop...........0
Freezeframe probably also can use some tweaking

[IanB]

:confused:

o1...FreezeFrame(0, o1.FrameCount()-1, 0)

o1...trim(0,-1).Loop(o1.FrameCount,0,0)

Should be identical sans the audio.

Did you have the correct end frame number to FreezeFrame or was it 1 (perhaps due to the Trim, FreezeFrame(0, 0, 0) will be a no-op.)

[redfordxx]

Did you have the correct end frame number to FreezeFrame or was it 1 (perhaps due to the Trim, FreezeFrame(0, 0, 0) will be a no-op.)I just copied exactly what you posted and tried again. Freezeframe eats CPU, Loop doesnot...

[IanB]

Very very :confused:

Add a "ShowFrameNumber()." to the front of the FreezeFrame call to confirm it is actually always hitting frame 0.

Whose Avisynth.dll are you using, in all of mine Loop and FreezeFrame result in functionally identical graphs and the cache functions correctly. All of the current MT builds are based on my old 2.5.6 very screwed cache code which misbehaves God know how.

[Gavino]

mt_lutspa.trim.freezeframe....27
mt_lutspa.trim.loop...........0
Is this a typo?
The freezeframe version should not have a trim before it.
You should be measuring o.mt_lutspa.freezeframe(0, o.Framecount-1, 0).

[redfordxx]

Is this a typo?
The freezeframe version should not have a trim before it.
You should be measuring o.mt_lutspa.freezeframe(0, o.Framecount-1, 0).
Yes, typo..i measured it correctly

[redfordxx]

Very very :confused:

Add a "ShowFrameNumber()." to the front of the FreezeFrame call to confirm it is actually always hitting frame 0.

Whose Avisynth.dll are you using, in all of mine Loop and FreezeFrame result in functionally identical graphs and the cache functions correctly. All of the current MT builds are based on my old 2.5.6 very screwed cache code which misbehaves God know how.
Me too :confused:
because with ShowFrameNumber the processor load is zero
without ShowFrameNumber there is noticable CPU usage.

[redfordxx]

My avisynth.dll is 2.6.0.2
Date modified 25.5.11. 11:10

[Gavino]

Just a thought, but I wonder if mt_lutspa does something strange to the cache, by implementing SetCacheHints(). By putting a filter (any filter) after it, you would then return to normal caching for the next filter, which seems to be what you are seeing.

[redfordxx]

I am working on a set of filters in this (http://forum.doom9.org/showthread.php?t=163018) thread and I made my own merge filter (name is RMerge).

I compared it in performance to mt_merge.
The test clip was 8192x4096 and have about 1.5GB free memory.
Then I realized it was about 50%... well thats too much difference.
The hard numbers are about 9GByte/s for RMerge and 6Gbyte/s for mt_merge.
So I digged deeper and my rookie guess is that the thing which is slowing down mt_merge is calling MakeWritable method.
I am pretty sure that this speed difference is not caused by the algorithm but by the memory transfer limitation. So there is maybe room for improvement.

But of course, this is just only newbie guess

[Dogway]

I know YUY2 is not officially supported but I found this to crash the application:

interleaved2planar
SeparateFields()
mt_lut(yexpr="x", expr="x 2 +", y=3, u=3,v=3)

The trigger is processing chroma in this scenario. It's strange because everything else works for planar YUY2.

edit: funnier facts; adding removegrain(0,planar=true) before mt_lut makes it workeable...

[wOxxOm]

a48, yv12: when width specified is one mt_lut(y=-255,w=1) the result is either two lines being affected or an access violation exception.

[jmac698]

width isn't really working :(

[mastrboy]

The documentation "documentation/mt_masktools.html" for masktools has not been updated since 2.0 alpha 43, i was wondering about all the CPU instruction values, are they all autodetectable? Or do i have to set f eks: SSE4=true to initiate SSE4 instructions?
This info is missing from the documentation...

[jmac698]

The docs that come with it are more up to date.

[canuckerfan]

Anybody know how to change this old function so that it's compatible with MaskTools2?
function Deflicker(clip clp)
{
o = last
screen = mt_lutf(o,o,mode="average",yexpr="x",U=1,V=1) #.greyscale
screenTS = screen.temporalsoften(1,9,0,9,2).merge(screen,0.249).temporalsoften(2,5,0,5,2)
calmed = o.mt_makediff(mt_makediff(screen,screenTS),U=2,V=2)
masky = o.mt_lut("x 32 < x 16 - 16 * x 204 > 255 204 x - abs 255 30 / * - 255 ? ?").removegrain(11,-1) #.greyscale
final = o.mt_merge(calmed,masky,U=2,V=2)
return final
}

[Didée]

That script *is* in MaskTools2 syntax. What problem do you face with it? I don't see anything that would cause a problem.

[canuckerfan]

avisynth gives me " Script error: invalid arguments to function "mt_lutf" "

[Didée]

Oh, what's that? Just tried, getting the same error. Sorry, can't help ATM. The syntax should be correct, as far as I can see.

A temporary workaround would be to replace the mt_lutf with

bicubicresize(24,16).bicubicresize(o.width(),o.height(),1,0)

which I would prefer anyway, since it gives a little bit of localisation. (I remember that using the naked plane-average could - unter certain circumstances - sometimes even increase the flicker locally.)

[Didée]

Ah, forget the above post. Well, not the suggested change, which is still true and valid. But for the error, it's very simple ...

function Deflicker(clip clp)
{
o = last
screen = mt_lutf(o,o,mode="average",yexpr="x",U=1,V=1) #.greyscale
[...]

That can't work. It must be

function Deflicker(clip clp)
{
o = clp
screen = mt_lutf(o,o,mode="average",yexpr="x",U=1,V=1) #.greyscale

That should work now. (Though, I'd really prefer the way via bicubicresize.)

[canuckerfan]

Changing "last" to "clp" did the trick. I tried replacing the mt_lutf line with the bicubic line and I get a different error that says invalid arguments to function "bicubicresize". Here's my script: function Deflicker(clip clp)
{
o = clp
screen = bicubicresize(24,16).bicubicresize(o.width(),o.height(),1,0) #.greyscale
screenTS = screen.temporalsoften(1,9,0,9,2).merge(screen,0.249).temporalsoften(2,5,0,5,2)
calmed = o.mt_makediff(mt_makediff(screen,screenTS),U=2,V=2)
masky = o.mt_lut("x 32 < x 16 - 16 * x 204 > 255 204 x - abs 255 30 / * - 255 ? ?").removegrain(11,-1) #.greyscale
final = o.mt_merge(calmed,masky,U=2,V=2)
return final
}

[Gavino]

screen = o.bicubicresize(24,16).bicubicresize(o.width(),o.height(),1,0)

[canuckerfan]

screen = o.bicubicresize(24,16).bicubicresize(o.width(),o.height(),1,0)
:o thanks

[Granit]

Hello, my first question on this board. I'm wondering about "mt_LUTs", the documentation for this filter seems off from the actual behavior of the filter. So I ask here to be certain that I'm not the error... Is this correct?
mt_square(1)?

y | y | y
y | x | y
y | y | y

mt_diamond(1)?

| y |
y | x | y
| y |
If this is correct, then why two input clips?