ColorKeyMask

[WarpEnterprises]

As dividee told me this filter sets the alpha-channel by comparing to the color. Each pixel with a color differing less than tolerance is set to transparent, otherwise it is left unchanged (it is NOT set to opaque).

Wouldn't it be good to set the alpha to opaque in the opposite case?
You could easily make a all-opaque mask with a tolerance of 255, or am I wrong somewhere?

[dividee]

My reasoning was that an all-opaque mask is the default, and you have other means of creating one anyway (BTW, tolerance at 255 will produce an all-transparent mask!)
I tought it could be more versatile this way, as it wouldn't destroy a previously applied alpha mask in non-keyed areas.

[WarpEnterprises]

And no way to argue you to add a set_opaque-Parameter?
Of course I know the

clip=Mask(clip, BlankClip(clip, color=$FFFFFF))

but it seems just a little ugly and I had hoped that ColorKeyMask would solve this.

[dividee]

But the modification you suggest won't work easily; it means you'll have to find a non-existent color in your clip and set tolerance to 0. Very ugly, I think.
What I can do is just add a straightforward ResetMask() filter.

[WarpEnterprises]

Agreed.

Btw have you or anybody else tested Layer with "lighten", "darken" and "mul"?
I mailed poptones about some diffent behaviour depending on colorspace (RGB seems ok, YUY2 seems strange). He told me that this is normal but then I can't really figure out the planned behaviour in YUY2 and I'm to bad in assembler to understand the code in that detail.
Can somebody explain it to me (I mean the "function" that is performed by those operators)

[poptones]

Lighten and darken just compare the luminance value of the two pixels being layered, and either applies the new layer (depending on lighten/darken and the threshold value) or it doesn't.

In YUY2 I do this simply by comparing the Y values of the two pixels - that's it, it's really straightforward. In RGB we don't have Y values, so I use RGB2Lum (the same constants and ops used elsewhere) to get the lum values of the two pixels, then do the rest the same as above.

I realize they aren't exactly the same. But to get the behaviours exactly the same one would need to do a full conversion. And there are already operators to do these conversions, so if you need a specific (ie either RGB or YUY2) behavior then you have that avenue. This way the filters are optimized for speed using either method.

If anyone can find a bug in these routines in this regard I'd seriously welcome your insight here. These three ops were difficult for me (hence there is still no "luminance only" mode in YUV mode - I know it seems odd, but this was harder than RGB) and if someone can provide better (more consistent?) code it would be great.

[WarpEnterprises]

@dividee: Thanks for implementing ResetMask.