[PD-dev] [GEM] proposal for color-space handling
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.
bbogart at ryerson.ca writes:
> This sounds good to me Chris,
> good work.
> ----- 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
More information about the Pd-dev