[Openicc] Re: PseudoColor / was: Re: new version of xcalib

GSR gsromero at infernal-iceberg.com
Tue Mar 15 10:16:45 EST 2005


Hi,
roland.mainz at nrubsig.org (2005-03-14 at 1904.03 +0100):
> > I didn't mention Pseudocolor, simply because noone interested in
> > serious color display (where the depth of the colormap entries
> > would be important) would use it. Anyone with color quality ambitions
> > would expect at least 8 bits/component, == 24 bits/pixel,
> PseudoColor can do up to 16bits/component == 48bit/pixel while TrueColor
> is limited to 32bit per pixel by design - which means either 10/12/10
> TrueColor or 10/10/10 TrueColor (30bit TrueColor visuals as supported in
> the Sun XVR-1000/-4000 graphics cards. But even these cards suport
> PseudoColor (even with multiple active colormaps in one display) to
> allow applications to have high-precision colors while only using a low
> amount of memory to represent the image data).

You both lost me. I know newest SGI machines (still X11, right?) can
do 12 bit per component (48 bit RGBA, 36 if you only count RGB),
except at the RAMDAC where they do 10 (30 bit RGB). And iirc, X11
colour definitions allow 16 bit per channel. X11 docs also talk about
16 bit, like http://tronche.com/gui/x/xlib/window/visual-types.html.
So how does all this fit? Is SGI doing tricks behind the curtain? Or
just common implementations fall sort of what is allowed?

GSR
 



More information about the openicc mailing list