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

[chris clepper]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20030114/5005499b/attachment.htm>