Merge Luma/Chroma filter v1.1 Released.

[sh0dan]

Hi folks.

I've just finished some improvements on the Merge filter, which some of you may know.

What is it?
The filter makes it possible to merge the Luma or Chroma channel of one source into another. It is also possible to blend the channels together at a given percentage.

v1.1 improvements
- All resolutions allowed.
- Fallback to C-code, if Integer SSE is not present. Only mmx is required, if no weight is specified.
- Documentation has more (correct) examples. ;)

So all in all it should just have become easier to use.

Documentation and source is included for those interested.
Comments here are welcome.

(File is attached, so it must be validated before it will appear here)

[avih]

sounds cool. i wonder if it can be used to make pal->ntsc /vice versa accurate conversion.

cheers

[Richard Berg]

When I ported the 1.0 code into Avisynth I remember thinking, "couldn't you just implement MergeChroma(foo, bar) as MergeLuma(bar, foo)?" As the code gets more complex, I think any way to simplify it is a good thing...

[dividee]

sh0dan, apparently you didn't see the modifications to your filters I did in avisynth2. I posted about it in the "leadership" thread, but sorry I should have made it more obvious.
The more important changes were:
* you can't call functions such as GetWritePtr or GetPitch before MakeWritable, since it can allocate a new buffer.
* arbitrary width (duplicate work, doh! )
* removed some unnecessary tests and moved some to the constructor
* revamped the mmx_weigh_luma & chroma functions; shorter loop (maybe not faster) and better rounding.

You can get the source from the avisynth2 CVS.

I'll add your non SSE weigh_luma ASAP.

[dividee]

@Richard
It already does!
But when the optional weight argument used, it doesn't work:
MergeChroma(foo,bar,0.5) != MergeLuma(bar,foo,0.5)

[sh0dan]

@dividee: No - I didn't see it - just saw that RB was using implementing it into AVS2, so I decided to make it more robust. Thanks for the clearup on MakeWriteable! I'm perhaps too interested in the basic algorithms to get this right. :/

Looking forward to seing your optimizations too :)

[sh0dan]

<sigh> - Why do you have to be a rocket scientist to figure out WinCVS (sorry - just had to blow out some steam).

[edit]
OK - got it!

@dividee: Your changes are very nice, nothing bad to say about them (expect perhaps many dependency stalls - just kidding). Also implementing the remaining pixels in assembler is something I just was to lazy to do :)

@RB: Yearh - I know the code is somewhat duplicated, but I did it to make it easier for the user to know what result they could expect, by making the usage more meaningful. IMO a seperate mergeluma/chroma is the most meaningful.
I haven't got access to my work computer (due to holidays), but when I do, I'll contact you for CVS-access and so on.

[Richard Berg]

I just went through that whole CVS rigmarole earlier this week...email me if you're having problems.

[dividee]

For me WinCVS was too much pain, I now use Tortoise CVS, works great so far.

[sh0dan]

Damn you guys are fast - see my response above :)

So this is the last plugin-version, before AVS2 is released! After that, be happy and use the merge from that.

[Richard Berg]

Well for better or worse, I won't need to worry about Merge anymore once Layer is optimized for YUY2. Guess it's just a race to see if poptones finishes it before I decide to release 2.0.2 :)

[dividee]

CVS updated with v1.1 enhancements

[poptones]

Well I dunno who will win that race, but it won't be done today, that's for sure. Ironically, they YUY2 version of layer is only on par (on a clock cycle basis) with the RGB version even 'tho it moves half as much data! The greatest diff is between layer(rgb, use_chroma-false) and layer(yuy2, use_chroma=false) where the YUY2 version uses ~19 clocks/pixel pair vs. ~23 clocks/pixel pair in RGB32!

Hopefully this will also lend itself to making convertToYUY2 run in something around 55 clocks/pixel pair. Should make the whole package a LOT faster. I know I was pretty blown away by the speed of my own "torture test" once I got the mmx optimization in there.

Anyway, it's getting incredibly hot. Supposed to be 101 with 90% humidity today, and the air conditioning can't even keep up in this damn brick house (what kind of idiot builds a brink house in mississippi? I already know what kind of idiot buys one).

Too hot to do anything but sleep. See you at eight.