Mask question

[Aludin]

I wanna merge two frames where the second one is cropped at the top and bottom so I gotta add black bars to it to match the first but then the result will be one frame with dark grey tints at the top and bottom. How do I make it so Merge() ignores the top and bottom borders?
Thanks.

[poisondeathray]

I wanna merge two frames where the second one is cropped at the top and bottom so I gotta add black bars to it to match the first but then the result will be one frame with dark grey tints at the top and bottom. How do I make it so Merge() ignores the top and bottom borders?
Thanks.

Crop the first one to match dimensions, thus removed from the merge() operation. And add back the original borders after the merge() if you want , or add back alternative borders (e.g. pure black, or whatever you want)

[Aludin]

I can't, I have 70 clips total and I have more crushed rather than stretched clips so I fix them to match the dimensions of the majority.

[manono]

...so I gotta add black bars to it to match the first...

Why?

How about this:

A=AVISource("video1.avi")###Or whatever source filter you're using
B=AVISource("video2.avi")
Overlay(A,B,Y=120,Opacity=0.5)###Set 'Y' for the amount cropped from the top of video2.avi

[Aludin]

Why? Because out of 70 clips, 50 are crushed and 20 are stretched. I'd rather do addborders on 20 clips than crop 50 clips. And I would be losing information from the top and bottom if I cropped.

I'd rather avoid Overlay because it doesn't correctly merge clips, it tints them green. And overlaying 70 times will make the clip look like it's been stained with alien slime.

[manono]

I'd rather do addborders on 20 clips than crop 50 clips.

...so I gotta add black bars to it to match the first...

Did I misunderstand you? Didn't you say they were cropped already but you were planning on using AddBorders to make them the same size as the one it's being merged with?

I'd rather avoid Overlay because it doesn't correctly merge clips, it tints them green.

Where do you get that? I have never in my life noticed that and I work almost entirely in black and white and do a lot of overlaying myself. Anything turning green would be even more obvious if beginning with black and white.

Maybe if you explain better what you're up to pdr or I or someone else can help better. I know of no way for the Merge filter to just ignore any black bars you might add. Maybe there really is a way and someone will show up to help.

[poisondeathray]

I think the "green shift" in layer and overlay were very old bugs. If you still see them, try updating avisynth

But you still have rounding errors because merge and overlay work in 8bit

Merge rounds up, overlay rounds down . You can't have 0.5 values expressed in integer 0-255 values

For example , if you have YUV 16,158,95 , and YUV 181,128,128 .
overlay gives 98,143,111
merge gives 99,143,112

You can use mt_merge() in 8bit with a mask. 100% Black will ignore the area you specify and take the base clip values (ie. the "overlay" will only function according to the mask), and a 128 grey mask will work like merge() (ie a 50-50 blend), yielding the rounded up values. The other option is Dither_merge16 with a mask which is more accurate in 16bit , but slower

[Aludin]

Did I misunderstand you? Didn't you say they were cropped already but you were planning on using AddBorders to make them the same size as the one it's being merged with?

Around 20 of them are permanently cropped already. So instead of cropping 50 clips to match those 20, I'd rather un-crop 20 clips to match the other 50. It's less work and I don't throw out parts of the video. Makes sense? Even if the situation was the reverse, I'd still rather keep the top and bottom chunks.

poisondeathray, how do I check which exact version I have? I could've sworn I updated a year ago. Also, I use Merge with RGB32, not YUV. It tends to be more accurate.

How would I properly substitute mt_merge for merge. My current script is something like

a1=v.trim(2,0).addborders(0,18,0,18).lanczosresize(640,480)
a2=w.trim(2,0).addborders(6,18,6,18).lanczosresize(640,480)

Merge(a1,a2)

Also, I don't put the clips in any particular order so I'm thinking that merging two clips that BOTH have black bars would be problematic. So I guess I'll have to properly sort them. One blackie for every whitey.

[poisondeathray]

how do I check which exact version I have?

You can check with simple one liner

version()

But conceivably, with multiple overlay() or merge() operations, you can see the rounding errors accumulate (The "0.5" rounding up or down), and so you might see a shift depending on what the values of the sources were .

There was another error a long time ago with layer and overlay but had been fixed. Same with some mvtools derivative functions like depan where there was clearly a green shift - that had been fixed more recently

Also, I use Merge with RGB32, not YUV. It tends to be more accurate.

You could argue with YUV sources, working in RGB is going to be less accurate. You incur YUV=>RGB conversion (and possibly back to YUV), and in 8bit many YUV color combinations do not even have a valid representation in RGB

And mt_merge only works in YUV . But if you still wanted to use it, you just make a mask with 128 grey everywhere, except the areas you don't want affected which are 100% black. So it would look like grey (128) except at the top and bottom which are going to black in your case

where "m" is the mask . Because "128" is 50% black, 50% white , you are getting the "merge()" effect along all pixels what have 128 value. areas that are "0" in the mask take only the "a" clip values

mt_merge(a,b,m,luma=true)

But it's more important to properly spatially align the clips according to the main content (ie. the central section), then you can use the mask to include or exclude from the blend operation


Here is an RGB source example:

RGB 75,15,126 , and RGB 192,192,192
merge RGB 134,104,159
overlay RGB 133,104,159

In this I would have expected overlay's "G" to be 103 if it was consistently rounding down. Overlay internally works in YUV444, so that might be the reason for some inconsistency with RGB source

[Aludin]

2.60, build: 3/31/2015. I knew I updated some time ago. Have new versions been released since? They don't come too often it seems.

I get that they don't round perfectly but after using both, Merge always looked more accurate while overlay consistently was tinted green.

Do I have to manually create the masks in photoshop? If so, I'm just gonna figure out another way.

But it's more important to properly spatially align the clips according to the main content (ie. the central section), then you can use the mask to include or exclude from the blend operation

Can you expound on this? I already have spatially aligned all the clips. Of course, it's always easier to crop away information than bring back something that doesn't exist.

[poisondeathray]

2.60, build: 3/31/2015. I knew I updated some time ago. Have new versions been released since? They don't come too often it seems.

I get that they don't round perfectly but after using both, Merge always looked more accurate while overlay consistently was tinted green.

The bug I was referring to predated that build by a long time

Yes - if you repeat the operation enough times, both merge and overlay will definitely give errors . But theoretically it can be just as bad rounding up . It might be in that specific case going one way was worse. OR. There might be other issues going on as well, if you can provide a clear example it would help with debugging what is going on

Do I have to manually create the masks in photoshop? If so, I'm just gonna figure out another way.

But it's more important to properly spatially align the clips according to the main content (ie. the central section), then you can use the mask to include or exclude from the blend operation

Can you expound on this? I already have spatially aligned all the clips. Of course, it's always easier to crop away information than bring back something that doesn't exist.

No, if it's just static "rectangle" shapes , it's easy enough to make the masks in avisynth . More complicated masks might require other workflows

e.g lets say "a" and "b" are 640x480 , where "a" is the base clip, but you only want the central 640x460 portion of b affected by the merge operation, for simplicity let's say it's evenly 10 top, 10 bottom excluded. The central 640x460 will be 128 grey, and the top,bottom 640x10 strips will be 0 black . You can use mt_lut to generate pixel values . Think of it as stacking 3 blocks together: top, middle, bottom.

a=whateversource()
b=whateversource()

#generate a black clip the same characteristics as clip "a"
black=blankclip(a)

#generate a 128 grey clip the same characteristics as clip "a"
grey=blankclip(a, color=color_white).mt_lut("128")

#crop the black clip to a 640x10 strip
strip=black.crop(0,470,0,0,true)

#crop the grey clip to 640x460
mid=grey.crop(0,20,0,0,true)

stackvertical(strip,mid,strip)

You can weight the clips too . 128 grey gives an even 50/50 (rounding up like merge() ) , but if you wanted higher "b", you could make it >128 grey for the mask areas. At "0", it's 100% A, at "255" it's 100% B

[Cornucopia]

You can never "add back" something that is no longer there, so you will either have to crop everything else or you will have to zoom+crop (on adjacent sides). Or stretch. Or add different material as padding.

Scott

[Aludin]

Thanks PDR and others, this worked fine but it took way longer than I expected. It took over 16 hours of messing around with the script. Definitely more effort than it was worth. I wonder if I could've saved time by simply merging them all together and then brightening the borders? Eh, it's over with.