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