[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 
>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
>

-- 




More information about the Pd-dev mailing list