[PD-dev] [GEM] proposal for color-space handling
cclepper at artic.edu
Wed Jan 15 03:06:25 CET 2003
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(
if (!strcmp(type->s_name, "rgb"))
m_pixbock.csize = 4;
else if (!strcmp(type->s_name, "yuv"))
m_pixbock.csize = 2;
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-dev