At 6:09 PM +0100 12/16/02, IOhannes zmoelnig wrote:

YUV: again i would like to stress: please do not make [yuv_*] objects, but make [pix_*] objects with functions for YUV. The processImage() will then bail out, when images other than YUV want to be processed.

here is my reasoning for making the [yuv_] set objects:

- a separate set of objects would be easier to leave out of compiles for platforms that don't support it. i was way over optimistic in my estimation of how well platforms support the yuv color-space. as it stands right now you cannot texture yuv using openGL in windows or linux, and support for this might never even happen on those platforms! i guess we should consider the yuv_stuff mac only for the moment.

- there is not a one to one correlation between yuv and rgb color-spaces. in fact they are vastly different, and not compatible in any way. this means that there are certain pix_objects that make no sense for yuv, like anything dealing with the alpha channel. also controls and messages would have to be different for each color-space, for example changing color values in rgb would have 3 controls for red green and blue, but in yuv there are only two chroma channels u and v and the luma changes brightness. that looks like a mess to explain. also conversion between rgb to yuv just to get the same functionality can be slow and lossy if done too much.

- Gem already had the pix_ naming convention which made it clear that pix = image processing and that stringing pix_objects together would result in a functional chain. my initial attempts to extend pix to yuv seemed to destroy that, so i decided that yuv_objects would make their own chains to avoid confusion. i also want the name of the object to describe what the object does in fairly exact terms. i get really tired of trying to figure out what the hell an object named after a post-modern theorist or someone's cat is supposed to do. therefore yuv_luma_key does luma keying in the yuv color-space,etc.

i really did think about this quite a bit. honestly.

cgc

please, mac-people, test, whether the new [pix_yuv] (converter (RGBA) to YUV) works correctly. the inverse (YUV2RGBA) is in [pix_rgba]

btw: i just checked-in some new changes (GemPixObj, GemPixDualObj) which might crash some compilations (it works at least under linux) forgive me, but i consider Gem as alpha-software right now

i'll check it out, but i'm behind on the cvs updates since i don't have access to the cvs yet.

mfg.asd.f IOhannes