[PD-dev] [GEM] new postrender crashes OS X

chris clepper cclepper at artic.edu
Sun Dec 22 01:57:00 CET 2002

>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 

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.




More information about the Pd-dev mailing list