[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