Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!haven.umd.edu!ni.umd.edu!sayshell.umd.edu!louie
From: louie@sayshell.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.next
Subject: Re: NeXTStation Color (again)
Message-ID: <1991Apr25.195907.29367@ni.umd.edu>
Date: 25 Apr 91 19:59:07 GMT
References: <1991Apr25.181814.19762@ux1.cso.uiuc.edu>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: University of Maryland, College Park
Lines: 24

This can't possibly be this hard to understand.  The user-level model
for color is you have 4 bits each R, G and B, plus 4 bits for the
alpha channel.  Deep in the guts of the hardware there is a mapping
function which takes the "ideal" RGB values and transforms them to
accomodate the non-linearity of the phosphers on the screen.  This
isn't something that user-level code gets to diddle or even see.

While the mapping function (color pallette) might have 8 bits of
resolution, that is irrelevant to you.  For all that we know, it might
have 9 and half bits of resolution.  It doesn't matter.  It's not
accessable.  If the response of the phosphers on the screen were
correct, you wouldn't need the thing in the first place.

This is like worrying how many bits are on your hard disk when you're
counting the "extra" bits used for sector identification, ECC
correction, etc.  It doesn't do you any good to worry about those bits
'cause you can't use them anyway.  You only worry about the formatted,
usable, capacity of the drive.

User-accessable Color pallettes are a kludge anyway IMHO.  I think
that its wonderful that you don't have to worry about screwing with
them in the first place on the NeXT.

louie