[PD-dev] Re: [Gem] test: pix_yuv

[chris clepper]

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


--