[PD-dev] [GEM] proposal for color-space handling

[bbogart at ryerson.ca]

This sounds good to me Chris,

good work.

Ben

----- Original Message -----
From: chris clepper <cclepper at artic.edu>
Date: Tuesday, January 14, 2003 9:06 pm
Subject: Re: [PD-dev] [GEM] proposal for color-space handling

> Hi all
> 
> This is my proposal for how to handle different color-spaces in 
> GEM. 
> I'll try to lay it out in a formal, yet concise manner, so we 
> easily 
> can discuss the merits of various points.
> 
> 1) Objects that initialize the image rendering chain, like 
> pix_film 
> and pix_video, should handle the necessary color-spaces by 
> creating 
> image.data buffers in the requested format.  These objects will do 
> all the required decompression and conversion to deliver raw data 
> in 
> either RGB or YUV.  The user will be able to specify which 
> color-space by a message to the left inlet or an argument given at 
> creation.  There is a reasonable chance that the API or lib used 
> by 
> these objects will not use one of the color-spaces, so in that 
> case a 
> conversion will have to be done.
> 
> example of the messages: [colorspace yuv( or [colorspace rgb(
> 
> example code:
>     if (!strcmp(type->s_name, "rgb"))
>            m_pixbock.csize = 4;
>     else if (!strcmp(type->s_name, "yuv"))
>            m_pixbock.csize = 2;
>     else
> 	error message
> 
> 2) Pix processing objects will not do any conversions.  If an 
> object 
> does not support the color-space passed to it, then it will post a 
> single error message to the console and pass an unmodified buffer 
> to 
> the next object.
> 
> example error message:
> 
>  "pix_foo: No support for (rgb/yuv) color-space, insert 
> pix_(rgba/yuv) before this object to convert"
> 
> 
> 3) There should exist objects (pix_rgba, pix_yuv) for converting 
> color-spaces to be used in certain special cases.   These would be 
> used before and after objects that don't support a requested 
> color-space in order to make a functional processing chain.
> 
> 4) Texturing objects should support all available color-spaces.  
> If 
> the requested color-space is not possible then conversion is done 
> in 
> the object before texturing.  This will probably have to happen on 
> Windows and Linux for YUV at this point, but perhaps future 
> drivers 
> will support direct yuv texturing.  Perhaps an error could be 
> posted 
> alerting the user of this conversion an possible remedy as well.
> 
> 5) The default color-space will be RGBA.  The current byte 
> ordering 
> will stay the same for 'native' pixel types on Windows and Linux. 
> OSX will use ARGB for processing and BGRA for texturing as it 
> currently does.
> 
> The proposed system will allow for the transparent handling of 
> multiple color-spaces and yet still offeerr user control of the 
> process.  I welcome all comments and opinions on this proposal.
> 
> Thanks
> cgc
>