[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