[GEM-dev] GemPixUtil.h confusion

chris clepper cgc at humboldtblvd.com
Tue Apr 19 15:04:02 CEST 2005


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 at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>





More information about the GEM-dev mailing list