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

daniel heckenberg daniel at bogusfront.org
Thu Jan 16 02:03:17 CET 2003


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 at ryerson.ca writes:

> 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
> > 
> 
> 
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.kug.ac.at
> http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev




More information about the Pd-dev mailing list