heya,
...while doing some further testing on the pdp2gem bridge, i'm getting confused by the rgba/bgra color channels! In our cvs GemPixUtil.h we have
/* RGBA */ #ifdef __APPLE__ const int chAlpha = 0; const int chRed = 1; const int chGreen = 2; const int chBlue = 3; #else const int chRed = 0; const int chGreen = 1; const int chBlue = 2; const int chAlpha = 3; #endif
...unfortunately this doesn't work on osx with just plain BGR: it kinda works, but I feel that it's actually writing the blue channel to the next pixel decoded!...this has made me realize that we actually have no rgb/bgr-only mode for pix_film (in osx), which is probably just a hope that no-one actually would think to use that after seeing the speed gains with yuv processing...
...I've also tried:
/* RGBA */ #ifdef __APPLE__ //tigital const int chAlpha = 3; const int chRed = 2; const int chGreen = 1; const int chBlue = 0; #else
...with no better results: the bgra is now screwed up...
...so this make me wonder if we need to have seperate channel designators for rgb and rgba? Or some other solution?
hmmm, jamie
james tittle wrote:
heya,
hi
next pixel decoded!...this has made me realize that we actually have no rgb/bgr-only mode for pix_film (in osx), which is probably just a hope that no-one actually would think to use that after seeing the speed gains with yuv processing...
the thing is: we should use as many colorspaces as is necessary, and as little colorspaces as is possible.
after the long discussions about yuv, i think we (at least: me;-)) settled on the following: "greyscale" for color-less images "YUV" for colored images "RGBA" for colored images + alpha.
an RGB-colorspace does not really give as any new features.
when we see it like this, RGBA is used far too often (still being the major color-space with windows+linux; but this is certainly due to the fact that i haven't got "native" yuv-texturing work on these platforms)
so brainstorming about RGB i get following: + widely used (esp. with images) + less memory than RGBA + better "color-resolution" (in terms of dpi, not depth) than YUV - yet another colorspace we have to handle! - not memory aligned (3bytes/pixel); makes writing fast code harder
i really don't think that RGB will ever be as fast as YUV (remember that YUV is memory aligned: that is what is making it fast); if i am totally out of my brains, please correct me
as for the better chroma-resolution, i think that it is not really necessary (YUV has downsampled chroma because of human perception capabilities)
and somebody would have to implement all the objects in the new colorspace (there are already some objects that understand RGB because of historic reasons) the conversions to/from RGB are only in GemPixUtil because mostly it was a somple copy'n'paste
i think, currently only one single object uses "toRGB": [pix_texture] when converting YUV to something readable (and i have never done any benchmarks)
so i think, writing SIMD for RGBA/BGRA has a higher priority than opening a new colorspace
(ah yes: that's why i don't think we should document the "RGB" colorspace at all (like in pdp2gem))
hmmm.mfg.sdft IOhannes
We discussed this a bit last night and neither Jamie or I could figure out what RGB can do over ARGB. I guess we are all in agreement that ARGB/RGBA covers the need just fine.
cgc
On Apr 19, 2005, at 2:12 AM, IOhannes m zmoelnig wrote:
james tittle wrote:
heya,
hi
next pixel decoded!...this has made me realize that we actually have no rgb/bgr-only mode for pix_film (in osx), which is probably just a hope that no-one actually would think to use that after seeing the speed gains with yuv processing...
the thing is: we should use as many colorspaces as is necessary, and as little colorspaces as is possible.
after the long discussions about yuv, i think we (at least: me;-)) settled on the following: "greyscale" for color-less images "YUV" for colored images "RGBA" for colored images + alpha.
an RGB-colorspace does not really give as any new features.
when we see it like this, RGBA is used far too often (still being the major color-space with windows+linux; but this is certainly due to the fact that i haven't got "native" yuv-texturing work on these platforms)
so brainstorming about RGB i get following:
- widely used (esp. with images)
- less memory than RGBA
- better "color-resolution" (in terms of dpi, not depth) than YUV
- yet another colorspace we have to handle!
- not memory aligned (3bytes/pixel); makes writing fast code harder
i really don't think that RGB will ever be as fast as YUV (remember that YUV is memory aligned: that is what is making it fast); if i am totally out of my brains, please correct me
as for the better chroma-resolution, i think that it is not really necessary (YUV has downsampled chroma because of human perception capabilities)
and somebody would have to implement all the objects in the new colorspace (there are already some objects that understand RGB because of historic reasons) the conversions to/from RGB are only in GemPixUtil because mostly it was a somple copy'n'paste
i think, currently only one single object uses "toRGB": [pix_texture] when converting YUV to something readable (and i have never done any benchmarks)
so i think, writing SIMD for RGBA/BGRA has a higher priority than opening a new colorspace
(ah yes: that's why i don't think we should document the "RGB" colorspace at all (like in pdp2gem))
hmmm.mfg.sdft IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Apr 19, 2005, at 9:04 AM, chris clepper wrote:
We discussed this a bit last night and neither Jamie or I could figure out what RGB can do over ARGB. I guess we are all in agreement that ARGB/RGBA covers the need just fine.
On Apr 19, 2005, at 2:12 AM, IOhannes m zmoelnig wrote:
(ah yes: that's why i don't think we should document the "RGB" colorspace at all (like in pdp2gem))
...yup, I agree: just wondering because of the option in pdp2gem, but it's obvious it's not really necessary anymore...
...maybe we're agreeing too much around here? :-)
...now, what else was I gonna do...?
jamie
-
chris clepper -
IOhannes m zmoelnig -
james tittle