Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cmcl2!hsdndev!think.com!samsung!uunet!stanford.edu!neon.Stanford.EDU!ly
From: ly@neon.Stanford.EDU (Eric Ly)
Newsgroups: comp.sys.next
Subject: Re: bits per pixel (was: NeXT General Educational Disqucount?)
Message-ID: <1991May12.205753.23335@neon.Stanford.EDU>
Date: 12 May 91 20:57:53 GMT
References: <1991May12.044514.329@cbnewse.att.com> <1991May12.052853.27513@neon.Stanford.EDU> <2776@public.BTR.COM>
Distribution: usa
Organization: Computer Science Department, Stanford University, Ca , USA
Lines: 43

In article <2776@public.BTR.COM> death@public.BTR.COM (David Burrowes  death@btr.com) writes:
>>>> I think 4, 16, or 32 bit is more accurate.
>>>> or even 2+2, 12+4, or 24+8 bit.
>>>Why 4 bits???  There are only four diferent "shades" on the B&W monitor: 
>>The 4 bits, or 2+2 bits, refer to two bits of data and two bits of
>
>I condeed in advance that I may be way off in la-la land here, but it
>runs in my mind, from something I distantly remember reading back in the
>0.8, 0.9 or 1.0 docs that the 2 transparancy bits were allocated 'on the fly'.
>That is, by default, the screen is 2 bits deep, but when one needs to go
>do transparancy work, enough extra bits are allocated for this purpose
>by DPS or whoever.
>Obviously, even if this is so for the Megapixel monochrome/grey/whatever
>screen, it ain't true for the color machines!

This is my guess as to the way it works.  The frame buffers for the
Monochrome, NSC, and ND screens are indeed 2 bits, 12 bits and 24 bits
in depth, respectively.  What you talk about alpha, you talk about
them in the context of PostScript pixelmaps, which are independent of
screen display capabilities.  Depending on whether you choose to or
not, DPS will allocate an extra 2 bits, 4 bits or 8 bits to be
associated with each pixel in the pixelmap.  You probably don't get a
choice as to the number of bits allocated for alpha, as it depends on
which machine you're using.  These extra bits define the transparency
of the data for each pixel.  When two images are merged together, DPS
uses the transparency values associated with each overlapping pixel to
compute the resulting color for that overlap.  The alpha is used to
_derive_ the resulting color, but the resulting color is "opaque" in
the frame buffer.  This alpha information can also be saved with the
data portion of the pixelmap.

So, it's indeed possible to display a 32-bit (8+8+8+8) pixelmap on a
monochrome screen; it's just that the 8 bits of alpha cannot be taken
into full account during compositing beyond, say, the two high-order
bits of the alpha.  It's rather like trying to render an 8-bit data
image onto a 1-bit display, except in this case, it relates to alpha.

This may not be completely accurate, but it's the way I understand it.



						Eric Ly
						Stanford University