Hi !
Zitiere bbogart@ryerson.ca:
Hey guys,
As for naming, how about pix_foo_yuv for the yuv versions of the objects..
what i just wanted to make clear, is that there should not be any difference between rgba- and yuv- processing (i have heard this before) rgba-objects are not called rgba_foo or pix_foo_rgba either, nor do grey-objects maybe i will have some christmas-days and come back with a completely changed mind. who knows ?
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.
kind of what i thought.
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.
this is exactly what i want. (and what it does now)
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.
well, i'm not part of the GUI-fraction of pd-users...
mfg.a.r IOhannes