Overlay vs. MergeLuma.MergeChroma in averaging two clips

[Seed]

I understand that in order to average 2 clips (e.g. 2 captured footage of broadcast in 2 separate settings, or twice capture from VHS), we can use Overlay (or even Layer) and MergeLuma.MergeChroma:

1) Overlay(clip1, clip2, opacity= 0.5)

2) MergeLuma(clip1, clip2, 0.5)
MergeChroma(last, clip2, 0.5)

Is there is any fundamental difference in how Avisynth handle these two different method of averaging? And if there is, is there any difference in terms of quality (e.g. color space changes, interlace related problem) and speed? (Assume that both clips are the same in color space and are interlaced.)

[joshbm]

MergeLuma and MergeChroma is much faster than Overlay. Although I haven't noticed a difference in quality, there might be something I've missed.

Regards,
joshbm

[actionman133]

What a novel idea!! I never thought to use mergechroma/luma...

I often blend frames in YV12, and hate the thought of converting to YUY2 for Layer, or using Overlay, since it converts to full sample YUV, then back to quarter resolution YV12.

I always used layer in three passes. Do the luma in Layer (luma not affected in the YV12-YUY2 conversion). Then I use UtoY and VtoY and layer them (since their luma, no loss). Then use YtoUV and MergeLuma to put them back together.

But you're methods faster...

[mg262]

1) Overlay(clip1, clip2, opacity= 0.5)Are you mainly interested in the 0.5 case? The reason I ask is because there is an iSSE (=P3+) assembly instruction called PAVGB optimised to average bytes with 0.5 weighting...

[Seed]

MergeLuma and MergeChroma is much faster than Overlay. Although I haven't noticed a difference in quality, there might be something I've missed.

Thank you. I have used two keywords "overlay" and "mergeluma" to search on this issue. Surprisingly only 2-3 matches were found and they did not touch on the differences. Only by searching for "MergeLuma" did I find this most useful thread, where you elaborated on the speed difference:

http://forum.doom9.org/showthread.php?t=82127&highlight=MergeLuma

In this thread, the whole words "overlay" and "mergeluma" occurred several times, yet the search engine fails to show it in search results!

My video clips are mainly analogue captures (s-video) in yuy2 interlaced. I have done some limited testing and conclude myself:

1) Picture (quality): I can't make out any difference between these two methods.

2) Speed. Yes, MergeLuma.MergeChroma is faster than Overlay. In the above thread Vectrangle showed clearly that the relative speed advantage of merge over overlay. But I find in practice, as Vectrangle's example also showed, this ratio of more than 2 only translates to about 7-10% speed increase in absolute term. Meaning that, this averaging (either method) process actually does not take up much time in the whole chain of files read (+/- decoding) --> averaging filter --> output (to file, or in framserving, or on display in Vdub).

I have been accustomed to the use of overlay() for many functions. In this case, writing overlay() is also more convenient and "cleaner" than MergeLuma.MergeChroma. However, for the speed's sake, even though only 7-10%, I will consider using merge method from now on.

[Seed]

Are you mainly interested in the 0.5 case? The reason I ask is because there is an iSSE (=P3+) assembly instruction called PAVGB optimised to average bytes with 0.5 weighting...

Yes, mainly the equal weighting case, though at times by visually inspecting both clips and finding one clip somewhat better in quality than the other, I will use 0.4/0.6 or 0.3/0.7 etc.

I am interested to know you suggestion of "PAVGB optimised to average bytes with 0.5 weighting". How is it used in Avisynth?

[mg262]

I'm not sure that it is used anywhere at the moment, but it could be used in a 'AverageYV12' filter.

BTW, 'optimised' was a bad choice of word... averaging at 0.5 is the only thing it does and it does it fast! I had a quick look at the code for MergeLuma, etc. and AFAICS it's pure C, so using PAVGB would probably be a fair bit faster.

When you use MergeLuma, etc., is this step a bottleneck?

[Seed]

In this case, writing overlay() is also more convenient and "cleaner" than MergeLuma.MergeChroma.

Umm, perhaps I can just use a function, but I wonder if this function call costs some overhead in speed, which I dislike.


Function merge(clip c1, clip c2, float w) {
MergeLuma(c1, c2, w)
MergeChroma(last, c2, w)
}

[Seed]

I'm not sure that it is used anywhere at the moment, but it could be used in a 'AverageYV12' filter.

My clips are mostly in yuy2, so I guess a 'AverageYV12' filter won't suit mine.

When you use MergeLuma, etc., is this step a bottleneck?

As I said in an earlier post, this averaging (either method) process actually does not take up much time in the whole chain of files read (+/- decoding) --> averaging filter --> output (to file, or in framserving, or on display in Vdub). The relative speed advantage of "merge" over "overlay" of more than 2 fold only translates to about 7-10% speed increase in absolute term, in my usual workflow.

[mg262]

Sorry, those posts happened so close together that I missed the first one!

I would be amazed if using the script function caused any slowdown... the time spent in the avisynth parser, etc. should be dwarfed by even simple operations on video simply because there is so much video to process (typically gigabytes of data going through the filter chain) ... but you could test it and see.

[tsp]

I'm not sure that it is used anywhere at the moment, but it could be used in a 'AverageYV12' filter.

BTW, 'optimised' was a bad choice of word... averaging at 0.5 is the only thing it does and it does it fast! I had a quick look at the code for MergeLuma, etc. and AFAICS it's pure C, so using PAVGB would probably be a fair bit faster.

When you use MergeLuma, etc., is this step a bottleneck?

try take a closer look at the MergeLuma::GetFrame code. It uses mmx code(mmx_merge_luma) if mmx is enabled

[mg262]

my mistake.

[tsp]

but there isn't a special version for weight=0.5 so if you want it should be easy to implement using PAVGB/PAVGUSB(the 3dnow version for k6 processors) and should faster(at least for yv12). Although it might be faster to use yv12lutxy

[joshbm]

yv12lutxy is faster than merge? And what is this PAVGB version?

Regards,
joshbm