rohrs@brahms.helios.nd.edu (533) (01/22/91)
Many questions: Can anyone explain just what you're getting with 4-bit, 8-bit, 16-bit and 24-bit color? Do they allocate so many bits per color (e.g. 8-bits of Red, 8-bits of Green, and 8-bits of Blue)? How does this relate to the chrominance and intensity signals in the NTSC color tv standard? And just why *do* they call it *32-bit* color quickdraw? What sort of software packages make use of color? How many colors can you display at one time? Given that you want color, how adequate is the Mac IIlc? And... On another note, can the lc be easily outfitted with a pmmu and fpu? Are the sockets there on the mother board, just waiting for a chip to be popped in or will it require a card in the processor direct slot? Thanx in advance! --jon (jon@trc.tellabs.com)
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (01/22/91)
Hopefully the following overview will answer some (though perhaps not all) of the questions raised by rohrs@brahms.helios.nd.edu: On the members of the Mac family that don't have built-in monitors, you have a connector for hooking up a monitor. This connector is either part of the on-board video (if the Mac monitor has video circuitry built-in) or it's on a video card. In all cases, this connector supplies an analog RGB signal. That means that the pins directly supply (among other things) three continuously-variable signals, one for each of the red, green and blue components of the video image. A TV signal encodes these RGB components into chrominance and intensity signals primarily to a) reduce broadcast bandwidth and b) maintain compatibility with black-and-white sets. At some point inside your TV, the circuitry has to decode these into the analog RGB components, to feed to your picture tube. And if you're doing any kind of processing of the video signal, it's usually much easier to work with the unencoded RGB components directly anyway. As for the number of bits per pixel, I've read that the human eye can, under ideal conditions, distinguish about 10 million different colours. Assuming that you can have 256 independent levels of each of the red, green and blue components in your video signal, you can synthesize 16,777,216 distinct combinations of these signals--more than enough, in theory, for full photorealistic colour. 256 distinct levels requires 8 bits to hold each of the three RGB components, which makes for 24 bits per pixel. The QuickDraw architects don't like working with numbers that aren't powers of 2, so they round this number up to 32 and mark the remaining 8 bits as "reserved for future use". This is the ultimate in terms of colour quality. But, as you can guess, it requires a lot of memory to hold all that pixel information, and it can take a lot of processing power to move it around and do things with it. Hence the need for less ambitious video modes. The other "direct-RGB" mode that Color QuickDraw supports gives you 5 bits for each of the three RGB components plus 1 "reserved" bit, for a total of 16 bits per pixel, and 32,768 distinct colours. IBM's new super-duper XGA displays have just reached the level of quality of this mode. Then there's the so-called "colour-table" modes--8, 4, 2 and 1 bit per pixel. With these modes, there aren't really enough bits to directly represent RGB values. Instead, the entire pixel value is used as an index into a "colour table" in the display hardware, which can contain a full 24 bits of colour information per entry. For example, 8 bits per pixel gives you a total of 256 different simultaneous colours, 4 bits per pixel gives you 16, 2 bits gives you 4, and 1 bit gives you 2. Normally two of the available colours are reserved for pure black and pure white, so in 1-bit-per-pixel mode you don't usually get to have any colours at all. Apart from this, those entries in the colour table can take on any of the 16,777,216 possible values. Applications don't normally access the colour table directly: there are two separate layers of QuickDraw software--the Color Manager and the Palette Manager--which handle most of the details for you. The Color Manager handles the mapping from RGB colour specifications to pixel values. Unless you're writing a real-time animation package, you don't normally have to know which pixel values correspond to which colours. Instead, you simply say "I want to draw with a colour containing so much red, so much green, and so much blue", and the Color Manager will find the closest available match in the device colour table, and see to it that, when you draw, the pixels get filled in with the right index value. The Color Manager also provides calls to let you examine and alter the device colour table, but again, most applications do not need to use these calls. The main reason not to use them is because, under MultiFinder, there may be other applications running at the same time, which may also want to adjust the colour table for optimum display of their images. To save applications the hassles of having to coordinate their colour needs among themselves explicitly, Apple introduced the Palette Manager. Instead of having to know about device colour tables, you specify a "palette" of requested colours, and attach it to a window. Each window can have a different palette. As windows appear and disappear, get shuffled to the front or back, or moved from one screen to another, the Palette Manager will handle all the headaches of adjusting the device colour tables for optimum display of the contents of those windows. It also supports a few other tricks which I won't go into here. Regarding the other question, the LC has no in-built provision for adding a PMMU or FPU. I can't see that that would stop third parties adding such a provision, though. Claimer: I've been a proud owner of an LC for two weeks now. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00