eric@batcomputer.tn.cornell.edu (Eric Fielding) (02/06/88)
In a recent article olson@endor.UUCP (Eric K. Olson) wrote: >In early Mac II documentation, there are references to 16 and 32 bit modes. >It's a pity these were eliminated, since the 24-bit cards now becoming >available have a painful programming interface... >Then again, a full 16-bit color lookup table would be about 524K. A 32-bit >one would be about 34 Gigabytes-- perhaps these resolutions were never >intended to be used with color-lookup tables. >The same document referred to 1-1-1, 2-2-2, 4-4-4, and 8-8-8 chunky-planar >pixel organizations (the 8-8-8 would have been perfect for the OpCode or >SuperMac 24-bit cards). >Eric K. Olson olson@endor.harvard.edu harvard!endor!olson D0760 I asked the net a little while ago how the new 24-bit cards are working now, and all of the responses were that they looked good, but were slow. Someone (I don't have it handy) said that the cards have special graphics processors that are not yet being used by the software (I assume to draw lines, etc.). My experience is with special-purpose image processors that organize the video memory into 8-bit planes, and then have three separate LUT's one each for the red, green, and blue guns. As Eric O. points out, it is very expensive to have one giant 24-bit LUT, but for anything I am interested in, the 3 8-bit (actually I think ours are 12-bits internally) work perfectly. It sounds like this is exactly what some manufacturers have done for their cards. It is a severe disadvantage if the QuickDraw routines do not support some kind of R-G-B "chunky" pixel organizations. Maybe the special purpose image processors will be around for a while longer. ++Eric Fielding eric@tcgould.tn.cornell.edu cornell!batcomputer!eric
howard@cpocd2.UUCP (Howard A. Landman) (02/17/88)
In article <3634@batcomputer.tn.cornell.edu> fielding@geology.tn.cornell.edu writes: >I asked the net a little while ago how the new 24-bit cards are working now, >and all of the responses were that they looked good, but were slow. >My experience is with special-purpose image processors that organize the >video memory into 8-bit planes, and then have three separate LUT's one each >for the red, green, and blue guns. As Eric O. points out, it is very expensive >to have one giant 24-bit LUT, but for anything I am interested in, the >3 8-bit (actually I think ours are 12-bits internally) work perfectly. No no no! The main reason to have lookup tables is so you can have more potential colors displayable than there are color codes available. This makes perfect sense with up to about 12 bit-planes. But with 24 bits, YOU DON'T NEED A LOOK-UP TABLE! You can actually just say how much RGB you want, independently, for each pixel. This is the ideal solution for many image-processing applications, and saves endless horrible kludges (like special programs to calculate what the best 256 colors are to represent a given picture). Now, there are SOME applications where you still want lookup. An IC layout system like Magic is one example: it is easier for the software to allocate one bitplane per mask layer, and be able to do screen manipulations with one bitplane active and the others write-protected. But even in these applications, you're losing a lot of power because of the separate LUTs. Three 8-bit LUT's give you at most 768 available colors, but direct 24 bit (no LUT) gives you 16M colors simultaneously displayable (if your display has that many pixels!). So, the hardware should really support both modes, but any given program usually only needs one. It's interesting to note that the X graphics library originally assumed that LUTs were being used, but is now being written to handle direct 24-bit color as well. Hope we see X Windows under AUX soon ... -- Howard A. Landman {oliveb,hplabs}!intelca!mipos3!cpocd2!howard howard%cpocd2.intel.com@RELAY.CS.NET "Over the lights and through the fires, we went surging down the wires"
cantrell@Alliant.COM (Paul Cantrell) (02/24/88)
In article <1118@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes: >No no no! The main reason to have lookup tables is so you can have more >potential colors displayable than there are color codes available. This makes >perfect sense with up to about 12 bit-planes. > >But with 24 bits, YOU DON'T NEED A LOOK-UP TABLE! You can actually just say >how much RGB you want, independently, for each pixel. This is the ideal >solution for many image-processing applications, and saves endless horrible >kludges (like special programs to calculate what the best 256 colors are to >represent a given picture). > >Now, there are SOME applications where you still want lookup. An IC layout >system like Magic is one example: it is easier for the software to allocate >one bitplane per mask layer, and be able to do screen manipulations with >one bitplane active and the others write-protected. But even in these >applications, you're losing a lot of power because of the separate LUTs. >Three 8-bit LUT's give you at most 768 available colors, but direct 24 bit >(no LUT) gives you 16M colors simultaneously displayable (if your display has >that many pixels!). I have to disagree with you about this. There are many uses for lookup tables besides allowing selection of a subset of colors out of a larger color space. Your example of Magic was a good one. Another example would be imaging applications which want to do color correction without having to change megabytes of image memory. I think you may misunderstand how a 3x8-bit lookup table can work (or you have used one that is braindamaged). Each entry in the 8-bit lookup table has 24 bits of RGB information. So you have the full 16M colors available to each of the three lookup tables. Since each 8-bit lookup table produces a full RGB value, the hardware must combine the three RGB values. One method would be to just sum them. So the final value of the RED gun would be R1 + R2 + R3 where R1 is produced by the #1 lookup table, R2 by the #2 table, etc. You will notice that you have simultaneous access to all 16M colors, if you so desire. To do this, you can just set lookup table #1 to produce 256 different red values, table #2 to produce 256 different green values, table #3 to produce 256 different blue values. So at a cost of 2304 bytes of lookup table (3 tables * 256 entries * 3 bytes per entry) you can make it work just like a direct mapped frame buffer. Is this useful? You bet. Lets assume you want to change the contrast of the image. How do you have to do this with a direct mapped frame buffer? Rewrite 24 megabytes of image memory. Pretty time consuming. How do you do it with the 3x8-bit lookup table? Rewrite 2304 bytes of lookup table. Effectively instantaneous. What if you have an image with only 6 bits of red, green, and blue (for a total of 18 bits of depth). With a direct mapped frame buffer, you still have to use the full 24 bits to produce the image, so the extra 6 bits are wasted. Using the 3x8bit lookup tables you could use the extra 6 planes for overlay graphics, mouse cursors, etc. The only problem with color maps that I really detest is that there is usually only one color map, when there may be several applications sharing the screen. Applications typically do a really poor job of sharing color maps. They frequently stomp on each other. Therefore, if I had to come up with a proposal for a color map system for the mac with access to 16 million colors, it would look something like this: 32 bits deep, arranged as follows: 5-bits ->color map selector 3-bits ->overlay graphics 8-bits ->lookup table #1 8-bits ->lookup table #2 8-bits ->lookup table #3 The color map selector selects which of 32 different color maps is used. Each application (or window) gets assigned a unique color map. For each of these 32 different color maps, you get a full 3x8-bit lookup table. This way each application can have complete control over how its image gets mapped into colors. You can run Magic and an true-color imaging application simultaneously (incase you happen to be a VLSI designer with interest in the graphics arts). The overlay graphics is for use by the system software for mouse cursors, etc. Of the 8 colors, I can think of: 0 = transparent (application image shows through) 1 = black 2 = white 3 through 7 various primary colors (red, blue, green, yellow, etc). Each lookup table entry would look like: +--------+----------+---------+-----+-------+------+ | RED OP | GREEN OP | BLUE OP | RED | GREEN | BLUE | +--------+----------+---------+-----+-------+------+ bits: 2 2 2 8 8 8 So you get 8 bits for each color, plus 2 bits of operation which is used to determine how the hardware combines the color with the other two color values (from the other two 8-bit lookup tables). I havn't thought out exactly which operations you need, but here is an example. Lets assume we are talking about the RED-OP field: OPERATION 0 -> Sum this value with the other two RED values OPERATION 1 -> Subtract this value from the other two RED values OPERATION 2 -> Logical OR this value with the other two RED values OPERATION 3 -> Use this value as an AND mask for the other two RED values. Total cost in memory of this color map scheme would be: 4 bytes per lookup table entry 256 lookup table entries per 8-bit lookup table 3 8-bit lookup tables per color map 32 color maps 98304 bytes of expensive high speed memory. Additional cost is 1 byte per pixel of image memory, so on a 640x480 screen this would be 307200 additional bytes, or on a 1280x1024 screen this would be 1310720 extra bytes. Yikes.