Ah, so when I change the chain to RGB via "colorspace rgb" to the src pix, the chroma_key object still expects YUV values? Even though the help patch clearly says you can use RGB values...

maybe only the YUV part is working?

using "value 16 16 16" and changing the "range" for all three channels does not cause any key at all.

I'll play with it more tomorrow.

.b.

On Mon, April 24, 2006 2:53 pm, chris clepper said:

If this is on a Mac the key values are in YUV. The green value is the lowest in the range (16,16,16) that's why the screen is green to begin with.

On 4/24/06, B. Bogart ben@ekran.org wrote:

...

Hey all,

I'm CCing a local artist, Teresa, who asked me this question.

In the process of playing with some keying footage she provided I seem unable to make pix_chroma_key actually work in this case...

We have two videos, a figure shot on a green screen (reading value 0, 240, 0), and a background to layer the figure into.

I'm using "value 0 240 0" to select the exact green of the background.

Now my understanding means that I should be able to see the green knocked out with a very low range, since it is more or less all the same exact color/shade, but instead I need to provide a very very high "range" to get a horrid result. I can start to see little bits of the figure with a range of "104 104 104", but going all the way up to "255 255 255" I don't see the whole figure (blacks parts are missing), and I get an approximate 1 pixel green halo around the figure. Some of this is due to compression, but that does not explain how bad this really looks. See attached screenshot of "value 0 240 0" "range 255 255 255"

Note I have sent colorspace RGB to both pix_film's so that I'm using RGB ranges and values.

It looks to me like the "range" I'm providing is trying to match not the green background, but the figure itself...

Since its a good green-screen, and pretty good footage, this should be a cinch to do, but I can't figure it out, after playing with the all the variables, direction, and which video goes to which pix_chroma_key inlet.

Please CC Teresa as it is her really trying to figure this out...

Thanks!

.b.

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

Since I don't understand YUV as a colorspace. Also I can load a video frame into gimp/photoshop and see what my key colour is in RGB, HSV, CMYK etc.. but not YUV.

Maybe a YUV colour picker in gem would help. ;)

I still could not get pix_chroma_key to key on "value 16,16,16" remember our green is 0,240,0 not 0,255,0. (which I guess is YUV 0,0,0)? what should the YUV range be like for this video?

Thanks for your help Chris, .b.

chris clepper wrote:

On 4/24/06, *B. Bogart* <ben@ekran.org mailto:ben@ekran.org> wrote:

Ah, so when I change the chain to RGB via "colorspace rgb" to the
src pix,
the chroma_key object still expects YUV values? Even though the help
patch
clearly says you can use RGB values...

maybe only the YUV part is working? 

No, it does RGB. But if it is a video source, why go RGB?

On Tue, 25 Apr 2006, chris clepper wrote:

On 4/25/06, B. Bogart ben@ekran.org wrote:

...

I still could not get pix_chroma_key to key on "value 16,16,16" remember our green is 0,240,0 not 0,255,0. (which I guess is YUV 0,0,0)? what should the YUV range be like for this video?

I may have bungled some of the code in that object. Try 128, 50, 50 and a range of 30 or so for a green background. I was able to key out a fairly typical green screen with that.

there's [rgb2hsv], [hsv2rgb], but do [rgb2yuv] and [yuv2rgb] exist yet?

There's [#rgb_to_yuv] and [#yuv_to_rgb] which works for both single pixels and whole pictures, but they use JPEG-style yuv, which goes 0..255 instead of the legacy range 16..239 (and such) which are due to NTSC/PAL voltage specifications. (Both ranges of YUV are in wide use).

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

On 4/26/06, IOhannes m zmölnig zmoelnig@iem.at wrote:

to make them compatible with [hsv2rgb], the values are normalized to 0..1; shouldn't we adapt this to the values [pix_chroma_key] takes too?

I thought raw 8 bit values would be more familiar to people coming from other applications. The normalized range would be more consistent though.