Hey guys,
As for naming, how about pix_foo_yuv for the yuv versions of the objects..
i initially started writing the yuv stuff like that. there is still a pix_filmYUV hanging around.
As for YUV in general I think it would only be used by more advanced users, mostely because the colorspace is imply that much more difficult to get your head around. As such I would say objects should be rgb by default and the yuv choice only comes in when you know you want it.
the complexity really depends on the operation. for proper chroma-keying and color adjustment one must know about yuv color space. other functions like blurring, mixing and masking are just like their rgb counterparts.
I think the waysoftVNS deals with colorspace is more as Johannes describes, with very fast conversion between colorspaces (altivec) I think you can specify the color space of a video source by send the source object a message. Perhaps something similar in Gem where the pix_ objects check what kinda of data they are getting and act accordingly, ie printing a message saying that pix_blah only supports YUV, and you must use pix_yuv to convert the rgba stream in order to use this object.
the GEM objects do detect which color space is being used by the bits-per-pixel of the pixmap. the conversion for every object just doesn't make any sense at all. let's say you want to luma-key two movies in DV or photo-jpeg codec, here's what would take place in the auto_conversion scenario:
pix_film (yuv->rgba) * 2 -> pix_luma-key (rgba->yuv->rgba) -> pix_texture
compared to keeping it in yuv:
yuv_film -> yuv_luma_key -> pix_texture
the first one is doing a hell of a lot of pointless work to get the same thing done. i pick the second method.
with all the efforts with coloured patchcords, how about changing the color of an object when it gets a datastream it does not support. Some of the other packages (eyesweb) only lets you connect compatible data types, otherwise it simply refuses to connect the objects.
those are both good ideas. i'm not sure about the state of pd's gui and how well such changes would be accepted. i haven't done any work on the tcl/tk end yet, so i don't even know how to do this.
Some ideas from my perspective anyhow.
thanks for all your ideas. i really like to hear input from GEM users.
cgc
Ben