MaskTools 2.0a48

[yup]

Didée
full script
http://forum.doom9.org/showthread.php?p=1478030#post1478030
Source VHS capture YUY2 colorspace.
Grey point give my mask and after using Your code I see grey line at place grey point and white line at place white point.
I am using only hard threshold with If statement and planing use Your code for mask creation for long black or white line (as noise) with tail from separated pixels.
Please advice.
yup.

[Didée]

I don't see it. For me it works correctly.

Input image: (random TV show, simple "bob()", followed by "sharpen(1)" so that some pixels get full white)

http://img715.imageshack.us/img715/2305/framewithwhitepoints.th.png (http://img715.imageshack.us/i/framewithwhitepoints.png/)


Result of the script I posted at last:

http://img510.imageshack.us/img510/1460/framewithwhitepointssca.th.png (http://img510.imageshack.us/i/framewithwhitepointssca.png/)


Everything like it should be. The white lines are only there where the input has Y=255 pixels. No grey pixels anywhere. The mask contains only Y=0 and Y=255 pixels. Nothing else.

[yup]

Didée!
Problem related with my script (see link at previous my post). Your solution work fine. I can not understand how I can get grey value after If statement with output 0 or 255 and after median filtering and series inpand expand call.
yup.

[Mini-Me]

Manao, I did a quick search on edge-detection kernels tonight to determine which I should use, and I actually stumbled across a new edge-detection kernel you might be interested in. In fact, it's so new that it seems it was just published a day ago or so. (I feel all warm and fuzzy inside being one of the first to see it! ;)) It seems to significantly improve upon the resolution of older edge-detection kernels by leveraging the {1/4, 3/4, 3/4, 1/4} convolution kernel that I think you may be familiar with from your YV12 conversion code. Anyway, you can check it out here:
http://assassinationscience.com/johncostella/edgedetect/

EDIT: FYI, it seems the rest of the website, especially the main page, is...um, highly unrelated and quite political, to say the least. :eek: The kernel itself seems interesting though.

[Didée]

Interesting presentation of hot air.

(I didn't look at the source code .... and I wouldn't expect to find miracles in there.)

The "magic upsizing" is strikingly similar to what you get with a plain BicubicResize. (Mitchell+Netravali, b=0.333,c=0.333).

Regarding the "magic kernel", compare to this:

imagesource("original.png")
bicubicresize(600,800)
converttoyv12(matrix="PC.601") # keep full range without loss
mt_edge("prewitt",0,255,0,255) # standard.
mt_lut("x 1 1.16 / ^ 1.62 *") # basically not needed. It's just to make local intensities more similar to the comparant
converttorgb32(matrix="PC.601") # undo again
return(last)

The result: (please compare for yourself to what is presented on that site)

http://img26.imageshack.us/img26/1817/magicunmagicked.th.png (http://img26.imageshack.us/i/magicunmagicked.png/)

Aahh - magic!!

:rolleyes:

[Mini-Me]

Interesting presentation of hot air.

(I didn't look at the source code .... and I wouldn't expect to find miracles in there.)

The "magic upsizing" is strikingly similar to what you get with a plain BicubicResize. (Mitchell+Netravali, b=0.333,c=0.333).

Regarding the "magic kernel", compare to this:

imagesource("original.png")
bicubicresize(600,800)
converttoyv12(matrix="PC.601") # keep full range without loss
edge=mt_edge("prewitt",0,255,0,255) # standard.
mt_lut("x 1 1.16 / ^ 1.62 *") # basically not needed. It's just to make local intensities more similar to the comparant
converttorgb32(matrix="PC.601") # undo again
return(last)

The result: (please compare for yourself to what is presented on that site)

http://img26.imageshack.us/img26/1817/magicunmagicked.th.png (http://img26.imageshack.us/i/magicunmagicked.png/)

Aahh - magic!!

:rolleyes:

Interesting. I wasn't really sold on the "magic" aspect of his upsizing kernel either, but I was under the impression that the upsizing itself was only one aspect of the resolution increase, the other being the upsize's ability to get identical vertical and horizontal gradient sampling positions out of naive finite differences (which operate over single pixel boundaries instead of skipping one, like blurry central differences). The latter is a real issue with finite differences in fluid simulation (which is why MAC grids are generally used), so I thought his method might have made an improvement in that area for edge detection too. Your own result is extremely similar to his though (e.g. the "Uptown" text on the right), so the improvement must be coming primarily from the upsizing alone.

Posting it was still worth it though, since I learned a simple upsize might do the trick for what I'm trying to do today. ;)

[Didée]

Small note - of course, once again I destroyed the script while making it "readable" in the post editor.:D - In the "edge=mt_edge(..." line, the "edge=" must not be there.

Original script corrected.


Btw, if I interpret the text correctly, assassinscience states that the edge detector was run on the small (=original) image, and only the result was upscaled by x2. But frankly, I'm not fully conviced. When looking closely, there are several locations in his edgemask with very thin strands of black, surrounded only by a few antialiasing pixels. (I.e. similar to 1-pixel-width lines.) It's a bit hard to imagine that this characteristic could be present when the mask was created on x1, then upscaled to x2. If I had to guess, I'd rather suppose that he did the masking on the x2 image in fact. But I might be wrong here.

[Mini-Me]

Small note - of course, once again I destroyed the script while making it "readable" in the post editor.:D - In the "edge=mt_edge(..." line, the "edge=" must not be there.

Original script corrected.


Btw, if I interpret the text correctly, assassinscience states that the edge detector was run on the small (=original) image, and only the result was upscaled by x2. But frankly, I'm not fully conviced. When looking closely, there are several locations in his edgemask with very thin strands of black, surrounded only by a few antialiasing pixels. (I.e. similar to 1-pixel-width lines.) It's a bit hard to imagine that this characteristic could be present when the mask was created on x1, then upscaled to x2. If I had to guess, I'd rather suppose that he did the masking on the x2 image in fact. But I might be wrong here.

I think he was talking about two separable steps:
1.) Take a naive (biased, adjacent) first difference in the x-direction and upsize (and eliminate the top and bottom rows, I guess).
2.) Take a naive (biased, adjacent) first difference in the y-direction and upsize (and eliminate the top and bottom rows, I guess).
(I'm not sure if he really means to eliminate the top and bottom rows for both the x and y images, or if you're supposed to remove the first and last columns for one of them...but whatever.)
The two upscaled images would then be combined like with any separable edge-detection filters. Since the upscaled x and y gradient images had exactly coinciding sample positions (due to his sampling kernel), that is supposed to account for the resulting high resolution.

That's my understanding, at least. It's clever assuming his math is correct, but it's kind of useless if upscaling and using a Prewitt kernel is just as good (unless there are advantages after downscaling again with the same kernel or something).

[Didée]

I'm viewing simply from a "common sense" point of view. Look closely at the following, and *think* about it.

http://img830.imageshack.us/img830/8381/detailq.png (http://img830.imageshack.us/i/detailq.png/)

The claim is that this B/W mask was created on the small image. What we see ^here^ is a 200% upscale. Do you really think you'd get such narrow features in a 200% upscale? If the upscale contains 1-pixel-thin features, how would the representation have been at half the size (i.e. "original" size)?? Take into account that the proposed upscaling method apparently is rather "soft", or at least not particularly sharp, as can be seen in the upscale of the base image.

If he upscales a natural image with a given algorithm, then the result is very blurry. But, if he upscales a B/W edgemask with the same algorithm, then the result is ultra-sharp, producing 1-pixel-thin features?

Seems strange to me. Nothing I would bet my money on. ;)

[Mini-Me]

I'm viewing simply from a "common sense" point of view. Look closely at the following, and *think* about it.

http://img830.imageshack.us/img830/8381/detailq.png (http://img830.imageshack.us/i/detailq.png/)

The claim is that this B/W mask was created on the small image. What we see ^here^ is a 200% upscale. Do you really think you'd get such narrow features in a 200% upscale? If the upscale contains 1-pixel-thin features, how would the representation have been at half the size (i.e. "original" size)?? Take into account that the proposed upscaling method apparently is rather "soft", or at least not particularly sharp, as can be seen in the upscale of the base image.

If he upscales a natural image with a given algorithm, then the result is very blurry. But, if he upscales a B/W edgemask with the same algorithm, then the result is ultra-sharp, producing 1-pixel-thin features?

Seems strange to me. Nothing I would bet my money on. ;)

When I really look at the image, the "1-pixel-thin" features actually look a little wider than that. There's some smoothing involved (the spacing between the centers of the white lines is ~5 pixels rather than 2), even if the darkest parts are only 1 pixel wide. Notice also that the darkest parts are usually some medium-dark gray, not black or very dark gray. I agree that the edges are very high-resolution though, perhaps "suspiciously" high-resolution, but it would be pretty silly of the guy to embarrass himself with a deliberate edge-detection kernel hoax, so I'm not ready to jump to that conclusion. ;)

I'm not at the point where I'd put money on it in either direction, but there's still an explanation that could account for the high resolution edges we're seeing: Most edge detection kernels, including the Prewitt kernel, use a central difference. Although it eliminates bias and lines up horizontal and vertical sampling positions, it inherently halves the resolution of the gradient/edges relative to the original image. Therefore, we're used to seeing half-resolution edge images, and that's our basis for comparison. In order to get full resolution edges, we actually need to upscale the original image and then perform edge detection, as you did in your script above.

In contrast, using a naive difference (like he does) gives us full-resolution edges in a single dimension, without having to upscale first. As an experiment, compare the following two operations:
Detect edges in the x-dimension ONLY using a naive first difference, then upscale. ([0 0 0 0 -1 1 0 0 0] edge-detection kernel, then upscale).
Upscale, then detect edges in the x-dimension ONLY with a central difference. (Upscale, then [0 0 0 -1 0 1 0 0 0].).
Actually, here's a script:

clip = Avisource("whatever.avi")
xedgesnaive = clip.mt_edge("0 0 0 0 -1 1 0 0 0", 0, 255, 0, 255).BicubicResize(clip.Width * 2, clip.Height * 2).Greyscale()
xedgescentral = clip.BicubicResize(clip.Width * 2, clip.Height * 2).mt_edge("0 0 0 -1 0 1 0 0 0", 0, 255, 0, 255).Greyscale()
return Interleave(xedgesnaive, xedgescentral)

You should get extremely similar results, just offset a bit. (You might need to brighten both up with luts or levels though.) In some areas the first clip does better, and in other areas the second clip does, but they're definitely of comparable quality. (EDIT: WROOOOOOOONG. ;))* As another experiment, do it without any resizes at all, and the naive version will have edges as narrow as half the width of the central version. This is because the naive first difference gets full resolution edges, whereas a central difference cannot (and upscaling first is necessary to accomplish that). The problem with naive first differences is that combining x-direction and y-direction edges doesn't usually work well. x-direction edges are shifted a half-pixel horizontally, and y-direction edges are shifted a half-pixel vertically. Without any clever resampling, the mismatched sampling positions will not fit together well, giving ugly combined x-and-y-direction edges. However, his goal was to cleverly upsample the x-direction and y-direction edges in such a way that the sampling positions lined up in the upscaled image (without blurring too much), and supposedly his kernel accomplishes this. If this is the case, I think it makes sense for him to be getting the results he's getting.

* EDIT: Actually, it turns out this is incorrect. I was getting comparable quality for my test clip, but using the test image he used and you used, the central difference in my comparison is WAY better. Upscaling a naive differenced-image looks like total crap. In short, you're right, and I have to agree with you that either:
a.) His description does not match his code.
b.) He's a wizard, or his kernel is way better at anti-aliasing than any of the upsizers I've tried (doubt it).

[ajp_anton]

You've "recently" added the function "mt_lutspa".
Wouldn't it make more sense to build it into the regular mt_lut(xy(z))? For example, "cx" and "cy" could return the x and y coordinates of the current pixel. Also, you could take it further and add "y-5,+1" which would return the value from clip y at a position (-5,1) from the current position ("y0,0" would be the same as old "y"). This way you could do basically anything (even simple blurring) with one function.
It may go beyond the original intention of *mask*tools, but does it matter? =)

[Manao]

Not really. I'm limited by the size of the LUT :
- mt_lut uses 3 * 256 bytes
- mt_lutxy uses 3 * 256 * 256 bytes
- mt_lutxyz uses 3 * 256 * 256 * 256 bytes
- mt_lutspa uses 1.5 * width * height bytes

Merging mt_lutxy with mt_lutspa would take up 3 * 256 * 256 * width * height, which is more than 2GB.

Of course, I could go the generic way, and compute the results of the arithmetic expression for each pixels. But I shudder thinking how slow that would be (hint : a script mt_lutxyz takes a long time to open, and the longer the expression, the slower it gets. And that's just to compute 16 millions values, ie 8 frames in 1920x1080).

[ajp_anton]

Ah, didn't realize that's how it works.
It's just a lot of work to make a mt_lut that depends on for example the height... I have to make a gradient with mt_lutspa and use it as the second clip in mt_lutxy, and because the video is only 8-bit, for heights over 256 pixels I have to use another finer gradient as the 3rd clip in mt_lutxyz.

[jmac698]

Manao,
Thanks again for the features of a48 - but now I'm doing something else advanced. Do the lutf modes return full precision? It seems not. I really need this. I made a script to calculate a correlation, and it works great with std. But if I multiply std by 2 I always get even numbers, which shows there's no more precision.

#a source....
scriptclip("""
std=mt_lutf(x,x,"std",expr="x 2 *").averageluma
subtitle(y=80,"std="+string(std))
""")

The loss of precision is too much for me to use my correlation reliably. Note that the runtime variable averageluma does give a real floating point number.

[yup]

Hi All!
I find error
http://forum.doom9.org/showthread.php?p=1496587#post1496587
Today I tested with official 2.6 build, the same error message. 2.5 version masktools work fine. QTGMC script need use other conversion not Interleaved2Planar for 2.6 masktools version?
yup.

[Manao]

yup : both avisynth 2.6 and masktools 2.6 support planar YV16, so instead of using interleaved2Planar (which is a hack for avisynth 2.5) just use converttoyv16.

jmac698 : noted, I'll add a parameter to increase the precision of std/average when used in mt_lutf

[yup]

Manao :thanks: for clarification.
Will be waiting until other plugin writer will be support planar colorspace for Avisynth 2.6.
yup.

[jmac698]

Manao,
Would it be possible to create a corr mode in lutf? For correlation.

[Manao]

jmac698 : not really. To compute a correlation, I would need two sets of values. Right now, mt_lutf's mode works only on pixels that comes from one clip, then use the computed value in another lut, that uses pixels from another clip. What it seems you want to do is working on both clips in the first step, is that it ? I can do that, but it starts getting quite specific. Would you care to explain what you want to achieve ? What's the bigger picture here ?

[jmac698]

You're right, that doesn't work well with lutf. What I can see a need for is collecting the pixels of one or two clips to return a single (and internally high precision) value. This value can't necessarily be applied in a formula to the pixels of another clip.
In my case I'm using lutf(x,x) and never referring to y as a workaround. But there are even functions where it makes no sense to apply to y. This new command would retain some features of lutf and add more operations, like lutfx(mode,x) where mode is std, avg, median, min, max, peak, and lutfxy(mode, x, y) where mode is corr, sad, sub. Peak means to return the position of the brightest pixel in the clip. But how to return two values? I probably want to use the position information to do a shift in another clip. Maybe add a new "x y shift" operation in the strings?

As for the big picture, correlation returns exactly the same number between two lists/images even if:
-one has some constant value added to each pixel (differences in brightness)
-one has each pixel multiplied by some value (differences in contrast)
-each has the same type of noise (grain, noise, salt n pepper) (same expected value at least)
-one is shifted (line jitter, but the black filler adds some error)
The use of compariing two noisy and different levels pictures helps find same/different or duplicate frames, which can be used to find cuts/dropouts/insertions/dupes in film, or analog video.
I'm using it to find missing frames between two analog recordings where each has random (but sparse) frame drops, and different noise and horizontal shift and even recording levels. You can also use it to detect re-edits and censoring, frame rate conversion, IVTC.
I also use correlation to find relative spatial shifts of the same image. If I use known images, I can have the correlation give the pixel shift directly. I could record a short sine and then learn the horizontal line jitter precisely.
So I am using the output of the collected pixels of the clip(s) for raw calculations or to apply an image shift.

[StainlessS]

Manao :thanks: for clarification.
Will be waiting until other plugin writer will be support planar colorspace for Avisynth 2.6.
yup.

I've just come across similar breakage in a script of mine.
I sort of, rectified the problem by renaming the 2.5 dll from

"mt_masktools-25.dll" to "mt_masktools_25.dll"
(NOTE the underscore rather than hyphen)

and used eg:-

msadf = sadf.mt_masktools_25_MT_Binarize()


to select the Planar YUY2 functional dll.

Also, renamed 2.6 with underscore, unfortunately, calling
2.5 dll with the dll name made a second anadorned call
(without dll name specification) also call the 2.5 dll.
Looks like the pluginin call order will then default to the
2.5 dll, so you would need to make all calls using the
extended calling convention.

Documentation for extended calling convetion in :-

Avisynth 2.5.8 help / AviSynth Syntax - Plugins /
Plugin autoload and conflicting function names v2.55

Suggest ALL future dll's use names valid for script variables and
script functions (with the ".DLL" appended).
From Avisynth help:

A variable name can be a character string of practically any
length (more than 4000 characters in Avisynth 2.56 and later)
that contains (English) letters, digits, and underscores (_), but
no other characters. The name cannot start with a digit.

Not any kind of convienient fix, doubt it will be of any help, but thought I should mention the above.
Shame that the dll name has a hyphen in it, ALL similarliy named dll's will break the above calling convention.

EDIT:- There does not seem to be any indication in the
MaskTools Changelog about the point at which the
interleaved2planar hack was removed, presumably, all
2.6 versions are without it.

[leeperry]

Bonjour,

Thanks for the great masktools, all my fav plugins use it :)

I was wondering, I use LSF and GrainFactory3 in realtime in ffdshow, is there a way you could implement 16bit? like the hack recently added to SmoothAdjust() that I also use: http://forum.doom9.org/showpost.php?p=1504207&postcount=210

I run Avisynth 2.6 if that matters.

:thanks: for considering it!

[jmac698]

I second that. I think I am one of the first pushing for 16bit. Keep asking for any useful new plugin.
Also, I found a need for atan2, that would be finding the angle from cartesian coordinates. Wikepedia has a good formula for implementation. atan2(x,y)->-pi to +pi.
ps I can't tell you how useful this plugin is, especially since a48. I make a lot of weird scientific scripts, and always I need it for calculations. I would never be so productive if I had to compile all my ideas into plugins each time.

[LaTo]

Bonjour,

Thanks for the great masktools, all my fav plugins use it :)

I was wondering, I use LSF and GrainFactory3 in realtime in ffdshow, is there a way you could implement 16bit? like the hack recently added to SmoothAdjust() that I also use: http://forum.doom9.org/showpost.php?p=1504207&postcount=210

I run Avisynth 2.6 if that matters.

:thanks: for considering it!
I second that. I think I am one of the first pushing for 16bit. Keep asking for any useful new plugin.
Also, I found a need for atan2, that would be finding the angle from cartesian coordinates. Wikepedia has a good formula for implementation. atan2(x,y)->-pi to +pi.
ps I can't tell you how useful this plugin is, especially since a48. I make a lot of weird scientific scripts, and always I need it for calculations. I would never be so productive if I had to compile all my ideas into plugins each time.


For a simple LUT (mt_lut) you can use SmoothCustom16(Yexpr="...",Uexpr="...",Vexpr="...",smooth=0) in SmoothAdjust v2.0beta7

:)

[jmac698]

Hmm, if that does standard deviation in 16bit, you're my new BFF :) I need high precision std in order to do a correlation.
Hey, could you do a correlation function in your plugin? x y corr calculate the corr correlation returning -1 to +1.
There is a corr 2d plugin but it's mostly for finding spatial shift. You could read the pixel value at no shift but you'd only get an 8 bit value.

[um3k]

Would it be possible to implement 32-bit intermediates? This would make it possible to use multiple MaskTools filters without dropping to 8-bit in between them. Obviously it would need to be a bit of a hack, I'm thinking dividing up the 32 bit values into 8 bit by simple binary means, and then interleaving them horizontally. Should be pretty simple to support within MaskTools, I would think. Seems like it would be a simple matter of interpreting the image as 32 bit. Given, the intermediate images would look like garbage data, but with an additional filter to convert between 8 bit and 32 bit and vice versa (to be used on either end of a chain of masktools filters), it should be quite usable.

One possible use: Generating a high bit depth mask with mt_lutspa, then applying it with another MT filter.

[jmac698]

If you look at my deepcolor tools, you'll see there's a way to calculate the high then low bits of a result in the expression, but using 8 >> and 255 &&. I store my MSB and LSB in differenent clips, smoothlevels uses vertically stacked videos. Smoothlevels should be able to do what you want anyhow.

I'm thinking of writing a package for precise manipulation that handles all the details, with an extra line of video containing meta data like chroma sampling and colorspace, and you need to open the video with the package and also specify the destination codec so it can handle the chroma placement and colorspace conversions at the end, and also hold intermediates in high bit and even linear colorspaces. And no more "hints" being hidden in the low bits of the video like from dgindex (?).

[leeperry]

Would it be possible to implement 32-bit intermediates? This would make it possible to use multiple MaskTools filters without dropping to 8-bit in between them.
I already discussed this point w/ Manao as I'd love to be able to use a 16bit pipeline w/ SmoothLevels() and all...he told me that he was too busy atm and might think about it when time allows.

[jmac698]

Hey,
I have my first request that's actually a mask function! I've been reading up on algorithms and I need a Euclidean distance mask. How it would work is you have a white mask of some pixels, and an original clip. For each pixel, output the distance to the nearest mask pixel. This will be used as a weight.

[cretindesalpes]

I need a Euclidean distance mask.
Check Tritical's tcanny (http://web.missouri.edu/~kes25c/), it has a tdtrans() function doing exactly what you need.

[jmac698]

Thanks! I discovered that custom weights in luts doesn't take -ve numbers, but I found a workaround with lutsx. Can you support -ve weights?
Also found offx=1 doesn't work. Why can I have 1 pixel access in my other calculations, but not with offset? It seems like the offset handling could be moved into the pixel loop or something.
I'd really like to be able to access u,v in my formulas for y. Though I can fudge it with lutxyz(utoy,vtoy..), I run out of arguments, and also it would be faster.
I'm using some functions for the first time, masktools is just brilliant. I think it will be "finished" with just a few more tweaks.

[wonkey_monkey]

Could someone explain the following behaviour for me?

video=mpeg2source("loop.d2v") # yv12
blank=video.blankclip
mt_lutxy(video,blank,"x y +")
return interleave(video,last)


The output frames are lighter than the input, but I was expecting them to be identical. I assume it's some kind of 16-235 range thing - can I stop masktools behaving that way?

David

[ajp_anton]

It's because blankclip creates pixels with value 16 (TV-levels black).
Don't know if you can create PC-levels there, but otherwise you can tweak it down to 0 (using coring=false).

[um3k]

This:
video=mpeg2source("loop.d2v") # yv12
blank=video.blankclip
mt_lutxy(video,blank,"x 16 - y 16 - + 16 +")
return interleave(video,last)
Should give you the effect you're looking for. What it does is subtract 16 from both clips, making black=0. It then adds them, then adds back 16.

[Didée]

Or as a possible alternative, use mt_lut instead of blankclip

video=mpeg2source("loop.d2v") # yv12
blank=video.mt_lut(Y=0,U=-128,V=-128) # luma=black, chroma=grey
mt_lutxy(video,blank,"x y +")
return interleave(video,last)

[SSH4]

looks like mt_lut(Y=0,U=-128,V=-128) use less memory ot less buggy than blankclip. Because the changing blanclip to mt_lut stable my script in Setmtmode(2) mode Avisynth.

[yup]

Hi All!

Please advice how implement pixels set n-1 pixels from left and current, I can write '"0 0 0 -1 0 -2.... 0 n-1", but I want make n variable. It is need for xx_pand and mt_luts functions.

yup.

[jmac698]

@rean

the same operation
as "add", but only when the result is BRIGHTER than the
base the new values are used.

So it's something like x y + x > ? x y + x
In other words, if (x+y)>x ? x+y : x

@yup

mt_rectangle : int hor_radius(1), int ver_radius(1), bool zero(true)

so mt_rectangle(1,n,true)

[yup]

jmac698!
mt_rectangle(1,n,true)
give rectangle with side 3 vertical pixel and 2*n+1 horizontal.
I need only line to left or right side n pixels length.
Can implement with recursive call but work slowly.
yup.

[jmac698]

Ok, easier way

n=2
LineStr="0 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 "
LineN=LeftStr(LineStr,n*4-1)

[SSH4]

Is this bug or limitation on latest mt_merge when i want overlay smaller size clip over bigger size with mask like i can made with Overlay(b,a,left,top,mask=z_mask)
when i try made this with mt_merge(biger,smaller,z_mask,luma=true,offX=left,offY=top)

i have this on AvsP:
Traceback (most recent call last):
File "AvsP.pyo", line 8071, in OnSliderReleased
File "AvsP.pyo", line 11075, in ShowVideoFrame
File "AvsP.pyo", line 11662, in PaintAVIFrame
File "pyavs.pyo", line 343, in DrawFrame
File "pyavs.pyo", line 320, in _GetFrame
File "avisynth.pyo", line 277, in GetFrame
WindowsError: exception: access violation reading 0x46688000
Traceback (most recent call last):
File "AvsP.pyo", line 9067, in OnFocusVideoWindow
File "AvsP.pyo", line 10493, in SetVideoStatusText
File "AvsP.pyo", line 10615, in GetVideoInfoDict
TypeError: %d format: a number is required, not float

biger clip have size about 1968x1064 smaller 1920x1080.

[cretindesalpes]

Actually I never could make the Masktools functions work with clips of different sizes. It always crashes.

[SSH4]

oh. this is my fault. mt_merge and overlay have different purpose of "offset".
and you right mt_merge work only with same size clips.

[jmac698]

@yup
I just discovered mt_rectangle(n,0) works
mt_rectangle(2,0) gives
-2 0 -1 0 0 0 1 0 2 0
If you really need left of current, just use something like
leftstr(mt_rectangle(n,0),5*n+3)
gives
-2 0 -1 0 0 0

[jmac698]

I wanted to find the min pixel per line. It was really slow, but you could do

mt_luts(last, last, mode="min", pixels=mt_rectangle(719,1), expr="y")

It would be really nice if you could do

mt_luts(w=1,offx=360,last, last, mode="min", pixels=mt_rectangle(359,0), expr="y")

Which would be instant. The theory being, you are processing only 1 pixel per line, at x=320. The relative coordinates refer to the entire line, +-360. So I am finding the minimum of the entire line and placing it in the output clip at x=360.
Instead, all computed coordinates out of bounds are ignored. This certainly makes sense for processing the full size clip, but I'd like to have a flag to include referencing pixels outside the window but still within the image.

[yup]

@yup
I just discovered mt_rectangle(n,0) works
mt_rectangle(2,0) gives
-2 0 -1 0 0 0 1 0 2 0
If you really need left of current, just use something like
leftstr(mt_rectangle(n,0),5*n+3)
gives
-2 0 -1 0 0 0
If n>9 need if statement.
yup.

[jmac698]

--UPDATED--

@all
Please see http://forum.doom9.org/showthread.php?t=162758 for new function, mt_line
mt_line(int hor_radius(1), int ver_radius(0), bool zero(true), int position(0))

@yup
The mt_line demo function is exactly what you need

[jmac698]

Bug:

mt_freerectangle

Gives invalid arguments, but the docs say they have defaults.

mt_freerectangle(-1,-1,1,1,false)

Gives
-1 0, 0 -1, 0 0, 0 1, 1 0
so the (0,0) is not taken out; it's also giving the shape of a cross! Amazing, I guess no one ever used this function before.
Using the zero=false for a rectangle makes it a cross and doesn't remove the (0,0); using zero=false for a line doesn't remove the (0,0)

[jmac698]

@yup

mt_freerectangle(-n,0,0,0)

Works directly.

[yup]

@yup

mt_freerectangle(-n,0,0,0)

Works directly.
:thanks:
i read old doc wo this function.
yup.