[GEM-dev] YUV processing

[B. Bogart]

Hey all,

Thanks for clarifying this Chris, I appreciate it. (when will yuv files 
be removed from cvs?)

As for my own use of pix_mask... I've always used pix_mask to create an 
image where the RGB channels are from one image and the alpha channel 
the average of the RGB channels from a second image.  For example:

Since I can't load pngs w/ alpha channels (can we now with osx??) and I 
want a soft edge on an image, or a cut-out for example. For this effect 
I need to add an alpha channel to the image, where the alpha channel is 
a matte or mask (white opaque, black transparent). In order to create an 
alpha channel I created the matte in a second image and use pix_mask to 
apply the matte to the image.  Note that the matte's I have used are 
always been 8 channel greyscale mapped to RGB so R, G and B channels are 
identical.

This is the best way I could figure out how to do this, what is the 
proper "gem" way?

The problem with keying is the edges and the matte generated from the 
colour/luma in the original image. I'm not at all interested in the data 
that can be extracted from the image, I know what parts I want visible 
and what parts should be opaque, so I design the matte myself. This 
matte is always perfect and is never dependant on the quality of the 
image being "masked". This is all to get around the (past) inability to 
load images with alpha channels and having gem interpret the alpha 
channel properly.

So in a land without pix_mask.. and assuming we can't load png's with 
alpha channels, how can I design my own matte for an image? A awful 
example would be video with a soft "feathered" edge.

I used pix_mask in oracle (www.ekran.org/ben/oracle) because before FSAA 
gem text looked terrible. So I made an image file (which was solid 
white)  and a mask/matte (white letters on black BG), and used these to 
generate the effect of smooth text... (see video for example)

pix_mask is there to have full control of the per-pixel alpha channel of 
an image, and I know of no other way of doing it. (obviously averaging 
the RGB is pretty ugly, but does generate a fair matte representation of 
the orginal image.

I would indeed be quite unhappy without this feature. (whether it is 
techically "keying" or not. To use the compositing terminology pix_mask 
does luminance keying based on a matte.

In the film world people don't actually use the "green" screen channel 
from the original (because it sucks). This data is simply used as the 
starting point for the creation of a matte that is then used in the 
compositing process, but at which point its is completely independant of 
the original image. (and only resembles the green-screen channel)

what pix_chroma_key does is exactly how the weather person on TV gets 
mapped onto the map, this is not a high-quality key nor does it need to 
be, because its live. (ie corrections to the matte are not possible) but 
I *want* full control of my matte! This would only be an issue if I was 
using a live video source, rather than pre-recorded footage.

So thats what pix_mask did, and I deem it a very important feature. (not 
as important ad png's importing with alpha channels!) Say, is there a 
video-file that actually included the alpha channel in each frame? 
(bloated it would be) I remember I used to have to export my videos as 
png sequences to maintain the alpha channels for each frame...

Ok thats enough of me.
Ben.

PS: if pix_rgba worked (osx) I could get around it. ;)



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 at iem.at
>> http://iem.at/cgi-bin/mailman/listinfo/gem-dev
>
>
>