MaskTools 2.0a48

[ChrisBeringB]

b and c are correct, but not that it matters - a,b and c are purely for illustrative purposes.
I imagined f(x,y,z) as a function that takes a mask as its first argument. So in b, when y=mask, all x'es are replaced with y's in f().

Chris

[ChrisBeringB]

MT_Adddiff and MT_Lutxy(yexpr="x y + 128 -")
doesn't yield the same results either.

Chris

[Manao]

Can you give precise examples ? Complete scripts ?

[ChrisBeringB]

q1=MT_Lutspa(BlankClip(width=256, height=256, pixel_type="YV12"), mode="absolute")
q2=q1.TurnRight
return Subtract(MT_Lutxy(q2, q1, yexpr="x y + 128 -"), MT_Adddiff(q2, q1)).levels(125, 1, 127, 0, 255, false).greyscale.converttorgb32

Shows that the two functions are indeed identical.

But in a complex script I have this line:
#mask2=MT_Adddiff(mask2, t)
mask2=MT_Lutxy(mask2, t, yexpr="x y + 128 -")

I get different, but consistent x264 encodings according to which line I use.
Very strange...

Chris

[Manao]

By default, both mt_adddiff and mt_lutxy (and actually, all filters from masktools, excepted mt_merge), create a random chroma channel (or, rather, U & V are malloc'd, but not memset'd). In order to have consistent encodings, you need either to add U=2, V=2 to both filters (that will copy the chroma channels from the source clip) or chroma="copy", or chroma = "128" (to set them to 128), or... Read the documentation, the part about common parameters (I know, it's easy to miss, everybody tends to jump directly to the filter list...)

My guess is that it also explains the behavior you're observing with mt_lutxyz.

[Manao]

As for mt_lutxyz cache coherency : the lut array is lut[x][y][z], so it's better if the first parameter is always constant. However, it's even better if you manage to avoid mt_lutxyz altogether...

[ChrisBeringB]

I've read your documentation carefully before using MT, and chroma isn't used at all in my script. Infact, after I first discovered the issue, I put greyscale on the output while doing further testing, just to be sure.

Thanks for the lut info - and yes, I try to use cascaded lutxy instead of lutxyz.

[ChrisBeringB]

mask2=MT_Adddiff(mask2, t, u=1, v=1)
mask2=MT_Lutxy(mask2, t, yexpr="x y + 128 -", u=1, v=1)
mask2=MT_Lutxy(mask2, t, yexpr="x y + 128 -")
Consistently gives the same result.
EDIT: also mask2=MT_Adddiff(mask2, t, u=0, v=0)

mask2=MT_Adddiff(mask2, t)
Consistently gives a different result.
EDIT: putting u=0, v=0 on every MT function in my script also yields this result.

In my script atleast.

Chris

[yup]

Originally Posted by Manao

As for mt_lutxyz cache coherency : the lut array is lut[x][y][z], so it's better if the first parameter is always constant. However, it's even better if you manage to avoid mt_lutxyz altogether...

Yes when I replace one mt_lutxyz to two mt_lutxy my script load faster and VirtualDub consume less memory.
mt_lutxyz use very big table 256*256*256*4 by comparing to 256*256*3 for mt_lutxy and do not have chance place this at cache.
May be I wrong about size for table but I hope You understand.
yup.

[Amateur]

Originally Posted by Dr.Khron

I tried using an older version, mftoon2 (mfToon-v0.54.avsi), but it keeps telling me that the "Unsharpmask" function cannot be found... I can't this function anywhere. Is it part of an older package I might be missing?

i too am getting this error and i didn't see an answer to his problem in this thread. i got the newest version of mask tools from manao's signature so where can i find unmask?

[Didée]

You go here, download the ZIP for "warpsharp package". From that archive, you extract *only* the warpsharp.dll file to your plugins folder. (Do not extract any other files, unless you're asking for problems!)

I'm not quite sure if that dll is compatible with auto-loading. In case it's not, load it manually with LoadPlugin().

[Amateur]

i have warpsharp.dll in the proper folder and still no luck. even tried adding a manual load plugin but i get the same error.

it says it's from line 78 of mftoon. do i have to actually change the mftoon script?

[Amateur]

any more advice? i still haven't found a fix for this...

[Didée]

Hmh. Maybe you get trapped by the plugin overloading feature. Empty your plugin folder from ALL plugins that smell like "warpsharp". Then manually load the warpsharp.dll from the linked package. (Here, locally, I've renamed the DLL to "warpsharp_package.dll" to avoid confusion with other warpsharp DLLs.)

[Amateur]

so i got your warpsharp package and now it's saying there is no maskedmerge. guess i'll try adding back things one by one to see if i can ever get this to work

edit: after adding everything back to my warpsharp package it now says that there is no function named YV12Layer from mftoon line 93.

edit 2: well replaing my previous warpsharp with the one you linked me to seemed to fix my problem with vmtoon (used to give me lots of white spots in all of my lines). maybe i'll see how that helps me. would still like to fix my mftoon problem though if possible

[Didée]

Well, yeah ... YV12Layer belongs to an outdated revision of the outdated v1.x branch of MaskTools (YV12Layer was in v1.4, and has been removed in v1.5 of MaskTools ... while the whole v1.x branch usually isn't used anymore.)

Short of saying mftoon is outdated. Get a time machine and travel 7 years back.

[Amateur]

oh so i should just stick with vmtoon? is that the improved mftoon? the guides i have found are probably old in that case. maybe you could pm me a list of your usual filters so i know what to read up on? that would be awesome

[jmac698]

I have a request that would make my life a lot easier. I'd like logic arithmetic operators available in the polish notiation, and I'd like to set the rounding mode to also truncate.
Try adding two 16 bit numbers with mt_lut, it's really a pain! I can't get a high byte because /256 will round, and there's no AND, so my only choice is to subtract expr 256 % 256 / to do it. Now try testing for carry from adding two 16bit numbers. That's a huge expression.
It seems like you could just not limit &. ie 255 15 & (should) gives 15 (but now 1) and still 1 1 == 0 0 == ^ gives 1, 1 1 == gives 1, so why limit & to 1 bit?

[Gavino]

Originally Posted by jmac698

It seems like you could just not limit &. ie 255 15 & (should) gives 15 (but now 1) and still 1 1 == 0 0 == ^ gives 1, 1 1 == gives 1, so why limit & to 1 bit?

The issue here is that the arithmetic is all done on floating point, so how would you interpret 246.1 & 14.8 ? There is also the question of backwards compatibility.

One possibility would be to introduce a separate integer mode, controlled by a new boolean parameter, in which internal values are manipulated as integers rather than float.

[jmac698]

That's easy, & only takes integers so cast it first, with truncate. There is perfect backward compatibility, the inputs to boolean are only 0 and 1 and a full range & handles this case. I see no problem.