<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [PD-dev] [GEM] proposal for color-space
handling</title></head><body>
<div>Hi all</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>example of the messages: [colorspace yuv( or [colorspace
rgb(</div>
<div><br></div>
<div>example code:</div>
<div><tt><font size="+1"
color="#000000"> </font></tt><font color="#760F50">
if</font><font color="#000000"> (!strcmp(type->s_name,</font><font
color="#891315"> "rgb"</font><font
color="#000000">))</font></div>
<div><font
color="#000000"><x-tab>
</x-tab> m_pixbock.csize = 4;</font></div>
<div><font color="#000000"> else</font><font
color="#760F50"> if</font><font color="#000000">
(!strcmp(type->s_name,</font><font color="#891315">
"yuv"</font><font color="#000000">))</font></div>
<div><font
color="#000000"><x-tab>
</x-tab> m_pixbock.csize = 2;</font> </div>
<div><font color="#000000"> else</font></div>
<div><x-tab> </x-tab>error
message</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>example error message:</div>
<div><br></div>
<div> "pix_foo: No support for (rgb/yuv) color-space, insert
pix_(rgba/yuv) before this object to convert"</div>
<div><br></div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>Thanks</div>
<div>cgc</div>
</body>
</html>