[PD-dev] [GEM] new postrender crashes OS X
cclepper at artic.edu
Sun Dec 22 01:57:00 CET 2002
>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
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