Hey Chris, and all.
I took a look at pix_compare and its close to what pix_mask did but the issue is the threshold. With pix_mask you have 8 bits worth of transparency data, where chroma-key and compare seem to only give you two choices per pixel, image1 or image2. This makes things like video noise really obvious and ugly. It would be great to have pix_mask functionality in*some* form.
We could use the YUV luminosity channel rather than averaging the RGB to get the mask. Though I suppose you can't use alpha channels in YUV since it is not YUVA? so the outgoing stream would have to be RGBA to contain an alpha channel...
A test I used for pix_compare was to create a mask/matte/alpha channel in the gimp, which was just a gradient from black to white. If I was using pix_mask I would see the left image fully opaque in the white parts of the mask, and fully transparent in the black parts. In between there should be a smooth transition from opaque to transparent, or from the left image to whatever is behind this object. By smooth I mean there is no point when you see a line deliniating the background from the left image.
Does this make things any clearer?
pix_mask is one of the few pix_ objects (other than pix_film/image/movie/texture) I actually use.
Ben
chris clepper wrote:
On Mar 23, 2004, at 4:31 PM, B. Bogart wrote:
So all that to say:
are the yuv* objects deprecated?
yes.
should pix_mask take YUV and it not doing so is some CVS update issue on my end?
No, pix_mask does some unknown type of processing, which averages R G and B and stuffs the result into the alpha. That's not representative of any known color-space and I can't imagine the output is all that useful. The note in the header file claims it does blue-screen, but that's clearly not the case. If you want to key two images together then try pix_chroma_key which does actual keying. Or perhaps pix_compare which will pass the greater or lesser of luminance values for both RGB and YUV.
Will pix_mask support YUV streams in the future??
I have no idea how it ever would.
cgc
Thanks all, Ben
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev