Request for ShowAlpha function / plugin

[neily]

Hi,

Having been playing around with alpha channels recently, I have realised that many functions mess them up in unexpected ways, and there also seem to be some odd behaviour in the Layer function, but without a reliable way of displaying the alpha channel, it is impossible to know what is really going on.

It would be really handy if a new function or plugin could be compiled that simply assigns the values of the R, G and B channels to the value of the alpha channel in the RGB32 colourspace. This would also have the added bonus of providing a route for applying the alpha channel of one clip to another via the Mask function.

[Richard Berg]

Please test this new binary: http://www.avisynth.org/bin/avisynth-030724.dll

It contains a new filter ShowAlpha that I believe does what you need. No MMX optimization yet, but it's pretty fast as is owing to its simplicity. Example script:

src=AviSource("d:\video\samples\combing.avi")
mask=Mask(BlankClip(src), src)

#return mask # blank screen
return mask.ShowAlpha # a slower version of Greyscale (src)

[WarpEnterprises]

Ahh, he was faster :)
Here is my version.

http://www.avisynth.org/users/warpenterprises/files/mask2_20_dll_20030724.zip

I made it as
Mask2(dest_clip, source_clip, string "mode")

where mode can have:
LumaToAlpha: as does Mask
AlphaToAlpha: copy Alpha
AlphaToLuma: the same as ShowAlpha

Richard, isn't it more general to expand the existing Mask as I sketched?
(I named it Mask2 only to avoid conflicts)

[Richard Berg]

I only skimmed the thread in AVS Usage so I didn't catch on to your suggestion. I like it, so I'll implement something along the lines of your version when I return tonight.

[WarpEnterprises]

Maybe you can answer my little puzzle regarding the built-in Mask:

The out-commented C code reads:

src1p[x*4+3] = (cyb*src2p[x*src2_pixels] + cyg*src2p[x*src2_pixels+1] + cyr*src2p[x*src2_pixels+2] + 0x8000) >> 16;

which gives only luma from 0...127

So is the correct equation
... + 0x4000) >> 15;

??

It would be nice if we had a complete formula collection at hand for YUV <> RGB, I wasn't able to find a non-assembly but C optimized one like the one above.

Anybody has one in mind?

[neily]

Wow,

Thanks very much the both of you. I only really started looking at masks and layers when trying to respond to a question in the usage forum where someone was asking about selectively altering certain colours, i.e. toning down reds, and realised how deficient AVISynth is in this area.

http://forum.doom9.org/showthread.php?s=&threadid=57943

I am slightly curious Richard, that with your function, and with my own lame experiments using Layer and black or white BlankClips to try to achieve much the same thing, greater opacity seems to be represented by black on white, i.e. low pixel values, whereas you would sort of expect white on black, as whiter pixels have higher values than lower ones.

Without wishing to be cheeky, what would possibly be useful too is a simple InvertAlpha function / plugin. Also, given the rise of YV12, would some way of directly manipulating the RGB channels of a clip be a backward step? I am thinking along the lines of:

CopyChannel(dest_clip,channel,src_clip,channel)

where channel is "r", "g", "b", or "a".

[WarpEnterprises]

What would be uses of manipulating r,g,b?
And what should happen to the untouched channels?

Inverting the alpha (or an explicit,generic Invert) is indeed missing.

[neily]

OK,

I take your point. I don't have any specific examples. All I an say is that I do often find working with chanels useful in Photoshop, there is a range of functions for YUV channels, and it just seems like the kind of thing that should be there for completeness, and not too difficult (for others) to implement. The untouched channels would remain unchanged.

And thanks once again for the ShowAlpha function. As a debugging tool it is proving really useful.

[Bidoche]

I can make mask and/or planar RGB videoframes for 3.0 if it helps...

[neily]

Slightly off topic, but connected really, as I was looking at Mud Funky's experiments at blue / green screen matting, and in relation to possible RGB <> YUV conversion problems, and the usefulness of isolating individual RGB channels. The original thread was:

http://forum.doom9.org/showthread.php?s=&threadid=56277

I tried:

ColorBars(352,288)
RGBAdjust(0.00,1.00,0.00,1.00)
GreyScale()

but got pure black. A similar story with RGBAdjust or using BlankClip to produce other pure RGB colours. Pure red and pure blue turn to black on GreyScale, whereas pure green seems OK.

I get similar results using your example, Richard, of a convoluted way of getting GreyScale using ShowAlpha (not ShowAlpha's fault I realise).

vid00=ColorBars(352,288).RGBAdjust(1.00,0.00,0.00,1.00)
vid01=BlankClip(vid00)
Mask(vid01,vid00).ShowAlpha

[Richard Berg]

I think your problem is that ColorBars sets the alpha channel to opaque (0) instead of transparent (255). That should be fixable, looking at the source now...

[Richard Berg]

Ok, got some stuff for you to play with. First off, a general (in RGB32, anyway) Invert (http://www.avisynth.org/index.php?page=Invert) function. Second, I altered ColorBars (http://www.avisynth.org/index.php?page=ColorBars) to have a transparent alpha channel by default; I also gave it some default parameters, since it would crash if you forgot to give it height/width.

Maybe you can answer my little puzzle regarding the built-in Mask
You are right, it should be >>15. I can't tell just yet whether the MMX code is correct, but it seems to give correct results.

greater opacity seems to be represented by black on white, i.e. low pixel values, whereas you would sort of expect white on black, as whiter pixels have higher values than lower ones.

I thought it was odd at first too, but I believe it is the standard way of representing alpha.

I tried:
[snip]

Your scripts should work now, neily.

http://www.avisynth.org/bin/avisynth-030725.dll

Haven't finished integrating WarpEnterprises' Mask2 yet. I want to have an excuse to brush up on SSEMMX.

[Richard Berg]

I've reconsidered, and changed ColorBars back to all-opaque; adding transparency here could cause unintended side effect. (The default size remains in place). Neily -- add Invert("A") to your scripts and they should work.

No new binary until I get Mask2 working.

[neily]

Richard,

Good stuff, everything seems to work as it should.

I think I may have been wrong before when I said that GreyScale and Mask were not working properly with pure reds and blues. Having used ImageWriter to analyse the output, what looked like pure black on screen was in fact just a dark grey.

All the new functionality that you are introducing is of course very handy for matting. The only function missing would be a ColorKeyMask where the mask is proportional to the selected colour rather than thresholded, ignoring colour psychological weighting. I realise this can be got around, but it is rather convoluted, involving RGBAdjust, Greyscale, Levels, Mask.

[Richard Berg]

Do you mean just changing (via an optional parameter) the comparison to be X% different from the given color instead of X values? That can be done easily enough.

It seems there should be even more options here. For instance, you could have a summed threshold instead of doing it channel-by-channel; currently, you can't permit (0,0,5) to key to a (0,0,0) background without also admitting (5,5,5). I've never worked in a commercial post-house, though, so I need input on what's important here.

Now that you have me looking at the source, of course, there are some obvious bugs. It skips the green channel completely in the C code; as for the MMX, I can usually read Avery's code, but poptones didn't include any comments...if I get around to editing the ASM before sh0dan comes back, I'll be sure to indicate register state & such for future readers!

[neily]

Richard,

I am really pleased you are taking an interest, and acting upon it. I guess the model that I am thinking of is that of "Select..Color Range" in Photoshop. Only problem is I haven't yet worked out how Photoshop does it yet. In Photoshop, if you start with a gradient fill of pure red to black, and do a Select..Color of pure red, and plot the difference from pure red against the resultant alpha you end up with a sigmoid curve. Adding green or blue seems to act by simple summation, but red and blue seem to have twice the weight of green.

I guess there are potentially 2 approaches, either summating the differences or multiplying the differences of the pixel channels from the reference color channels, and either having different threshold ranges for each method, or scaling it to an arbitrary figure.

Excusing my pascal, I guess the simplest approach is:

val:= thresh - (abs(R1-R2) + abs(G1-G2) + abs(B1 - B2));
if val < 0 then val:=0;
alpharesult:=round(val / thresh) * 255);

where thresh has a range of 1 to 765, and an alpharesult of 255 gives full opacity. Alternatively:

RVal:=(thresh - abs(R1-R2))/thresh;
if RVal < 0 then RVal:=0;
GVal:=(thresh - abs(G1-G2))/thresh;
if GVal < 0 then GVal:=0;
BVal:=(thresh - abs(B1-B2))/thresh;
if BVal < 0 then BVal:=0;
alpharesult:=round(RVal*GVal*BVal*255);

where thresh has a range of 1 to 255.

[Richard Berg]

I don't see the value in making the alpha value a gradient. Usually when you're doing a chroma-key you want objects to either be in the foreground or not.

[neily]

I am no expert, so cannot say how it is done normally in post-production video. But surely there has to be some degree of fall off at the edges otherwise the results are always going to be very obvious. The only alternative would be to smooth the mask, though I guess this would help with noisy sources. With the multiplying method the fall off would be pretty rapid. Similar functionality is offered in Adobe Premiere. In fact all sorts of options are available.

Besides, there are probably uses beyond matting.