This sounds good to me Chris,
good work.
Ben
----- Original Message ----- From: chris clepper cclepper@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.
- 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
- 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"
- 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.
- 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.
- 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
Hi chris, ben, list
Yes - I think this looks great too... very workable.
Useful messages when 1) an image generator has to do a conversion 2) a texture object has to do a conversion 3) a processing object can't operate on the current format will help guide the end user through the complications.
Daniel
bbogart@ryerson.ca writes:
This sounds good to me Chris,
good work.
Ben
----- Original Message ----- From: chris clepper cclepper@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.
- 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
- 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"
- 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.
- 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.
- 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
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
-
bbogart＠ryerson.ca -
daniel heckenberg -
zmoelnig＠iem.at