[GEM-dev] GemPixUtil.h confusion

[IOhannes m zmoelnig]

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