B. Bogart wrote:
Prehaps the pix_film object could print out a message when trying to load a rgb codec in yuv space?
well, this is a bit complicated. there is no such thing as a "yuv space" into which an "rgb"-object (e.g. movie) is loaded.
the idea is that a pix-source supplies the image in a "native" way. you should be able to override this "native" way with a "colourspace" (or "colorspace" if you prefer...) message.
all modifying objects should have methods for all colorspaces (if this is possible); if such the needed method has not been implemented (yet), an error-message is sent to the console.
Any plans for automatic colourspace switching?
this has been discussed once; chris has argumented (and by now i agree) that automatic switching would be a sincere performance penalty: the problem is, that the system will choose to convert for you and you will not know why it get's sooo slow; if you have to do the conversion "manually" then you might optimize it easier
(but we could do automatic conversion + output to the console that conversion is done! this would tell the user what is going on (so slow) and it still would work)
pix-sinks (like [pix_texture]) should handle all colour-spaces. since windos and linux don't know yuv-textures (at least i wasn't able to convince them to display correctly) they are automatically converted on these platforms. on OSX, yuv-textures should theoretically be possible, however there are bugs in (older releases of) the drivers (for nvidia). i don't know any failsave method to detect such bugs (except for looking at the green image, of course) and solve them on the application side (btw, i don't think that solving driver's bugs is a task for an application)
mfg.as.dr IOhannes