scott@CIE.UOREGON.EDU (11/25/89)
I need to work with images with lots of color information and I'd like to have as much resolution as possible and remain standard. I see lots of Super VGA boards that handle 1024x768 with 16 colors and 800x600 with 256 colors. Are there any boards out there that can handle something like 1024x768 or 800x600 with 16.8 million colors? It would be great if such boards could also handle the normal VGA modes too. Please tell me about any boards you know of like this or even close. The amount of color info is of most importance. Thanks. __________________________________________________________________________ Scott Settlemier Univ. of Oregon scott@cie.uoregon.edu (503)-686-0808 --------------------------------------------------------------------------
chasm@attctc.Dallas.TX.US (Charles Marslett) (11/29/89)
In article <8911250811.AA26716@cie.uoregon.edu>, scott@CIE.UOREGON.EDU writes: > I need to work with images with lots of color information and I'd like to have > as much resolution as possible and remain standard. I see lots of Super VGA > boards that handle 1024x768 with 16 colors and 800x600 with 256 colors. Are > there any boards out there that can handle something like 1024x768 or 800x600 > with 16.8 million colors? It would be great if such boards could also handle > the normal VGA modes too. Please tell me about any boards you know of like this > or even close. The amount of color info is of most importance. Thanks. The Tseng Labs ET4000 chip (going into full production early next year) will support 65536 colors and is a VGA chip, so it will handle all the standard VGA modes as well. The 16-bit/pixel modes do require some external support circuitry, however, so most boards designed with the ET4000 probably will not be able to do it. Some might -- check with the board makers that currently use Tseng chips -- STB (we will probably not support it, sorry), Tecmar, Orchid, Sigma Graphics, Genoa(?), and (I'm sure) several others. > Scott Settlemier Univ. of Oregon scott@cie.uoregon.edu (503)-686-0808 Charles Marslett BIOS guru -- STB Systems <-- apply all standard disclaimers chasm@attctc.dallas.tx.us
joel@peora.ccur.com (Joel Upchurch) (11/30/89)
In article <10401@attctc.Dallas.TX.US>, chasm@attctc.Dallas.TX.US (Charles Marslett) writes: > The Tseng Labs ET4000 chip (going into full production early next year) > will support 65536 colors and is a VGA chip, so it will handle all the > standard VGA modes as well. The 16-bit/pixel modes do require some .... It seems to me that if a board supports 16-bits/pixel that it would be better to have the colors map directly rather than going through a mapping table. With 5 bits each for red, green and blue that would give you 32k colors to work with one bit left over. This would eliminate the overhead of setting up the color mapping table as well the hardware to do the mapping. Does anyone know how many different colors a normal monitor can display that the human eye can actually tell apart? -- Joel Upchurch/Concurrent Computer Corp/2486 Sand Lake Rd/Orlando, FL 32809 joel@peora.ccur.com {uiucuxc,hoptoad,petsd,ucf-cs}!peora!joel Telephone: (407) 850-1040 Fax: (407) 857-0713
chasm@attctc.Dallas.TX.US (Charles Marslett) (11/30/89)
In article <4033@peora.ccur.com>, joel@peora.ccur.com (Joel Upchurch) writes: > In article <10401@attctc.Dallas.TX.US>, chasm@attctc.Dallas.TX.US (Charles Marslett) writes: > > > The Tseng Labs ET4000 chip (going into full production early next year) > > will support 65536 colors and is a VGA chip, so it will handle all the > > standard VGA modes as well. The 16-bit/pixel modes do require some .... > > It seems to me that if a board supports 16-bits/pixel that it would be > better to have the colors map directly rather than going through a > mapping table. With 5 bits each for red, green and blue that would > give you 32k colors to work with one bit left over. This would eliminate > the overhead of setting up the color mapping table as well the > hardware to do the mapping. The problem here is that the mapping I was talking about was going from 16-bit binary (digital) information in the video card's RAM to a 3-wire analog signal at the monitor. The DAC, that is. A problem with eliminating random mapping comes up when you want to do gray scaling (check recent messages in the comp.sys.atari.st group) -- with a fixed 5-bits/color map you only get 32 gray shades, even with 16 bits per pixel. > Does anyone know how many different colors a normal monitor can display > that the human eye can actually tell apart? It depends a whole lot on the patterns (a smooth gray ball requires perhaps 100 -- I see lines with 64), whether there are really boundaries in the image or not. The human eye is very good at extracting structure from a field of view, and sometimes we don't want it to (as in smooth shading). > -- > Joel Upchurch/Concurrent Computer Corp/2486 Sand Lake Rd/Orlando, FL 32809 > joel@peora.ccur.com {uiucuxc,hoptoad,petsd,ucf-cs}!peora!joel > Telephone: (407) 850-1040 Fax: (407) 857-0713 Charles Marslett chasm@attctc.dallas.tx.us [VGA BIOSes, DOS drivers, X servers, what comes next!]
ben@val.com (Ben Thornton) (12/01/89)
joel@peora.ccur.com (Joel Upchurch) writes: >In article <10401@attctc.Dallas.TX.US>, chasm@attctc.Dallas.TX.US (Charles Marslett) writes: >> The Tseng Labs ET4000 chip (going into full production early next year) >> will support 65536 colors and is a VGA chip, so it will handle all the >> standard VGA modes as well. The 16-bit/pixel modes do require some .... >It seems to me that if a board supports 16-bits/pixel that it would be >better to have the colors map directly rather than going through a >mapping table. With 5 bits each for red, green and blue that would >give you 32k colors to work with one bit left over. This would eliminate >the overhead of setting up the color mapping table as well the >hardware to do the mapping. >Does anyone know how many different colors a normal monitor can display >that the human eye can actually tell apart? Actually, a color mapping table is useful for a lot more than just making lots of colors. A real strong argument in favor of using them is their ability to shift color maps in real time. This makes it possible for multitasking OS's to assign different color maps to different areas of the screen to support different applications' requirements. There are few other way to accomplish this without the use of color mapping hardware. -- Ben Thornton packet: WD5HLS @ KB5PM Internet: ben@val.com Video Associates Labs uucp: ...!cs.utexas.edu!val!ben Austin, TX fidonet: 1:382/40 - The Antenna Farm BBS
bcw@rti.UUCP (Bruce Wright) (12/01/89)
In article <4033@peora.ccur.com>, joel@peora.ccur.com (Joel Upchurch) writes: > It seems to me that if a board supports 16-bits/pixel that it would be > better to have the colors map directly rather than going through a > mapping table. With 5 bits each for red, green and blue that would > give you 32k colors to work with one bit left over. This would eliminate > the overhead of setting up the color mapping table as well the > hardware to do the mapping. This is certainly true for some applications, but if you want to do image processing it can be *VERY* useful to be able to play around with a video lookup table. For example, you can quickly and easily highlight a portion of the image that has a particular range of values, change the brightness mapping scale to provide better definition, and so forth. It saves having to manipulate the image in your program and reload it onto the screen (saving both execution time and programming time, at least for large classes of display devices). Also, if the predefined colors aren't enough (for example, many images are processed with between 256 and 2048 shades of grey, which exceeds what you can get with 5 bits each for R,G,B = 32 shades of grey unless you get a monitor that can combine the signals from more than one of the color guns), you can always re-arrange the color map to get more of the types of colors you need and fewer of the ones you don't need. Again, however, you are right that for a good many PC applications (=text, charts, "business graphics", etc) 32k colors with 5 bits each for R,G, and B is more than enough. For that matter, for many PC applications 16 or 4 or even 2 is enough! Bruce C. Wright
zech@leadsv.UUCP (Bill Zech) (12/01/89)
In article <4033@peora.ccur.com>, joel@peora.ccur.com (Joel Upchurch) writes: > > It seems to me that if a board supports 16-bits/pixel that it would be > better to have the colors map directly rather than going through a > mapping table. With 5 bits each for red, green and blue that would > give you 32k colors to work with one bit left over. This would eliminate > the overhead of setting up the color mapping table as well the > hardware to do the mapping. Nope. Color lookup tables (aka color indirection, etc.) is much superior to direct mapping. All high performance systems I have ever used/designed employ them. Why? Suppose you want to change the colors slightly. Would you rather modify a small number of bytes in a table, or re-write your entire 1 million pixel display. There are many linear enhancement processes (contrast, brightness, pseudo color, etc.) which are very efficient using LUTs. > > Does anyone know how many different colors a normal monitor can display > that the human eye can actually tell apart? I don't know the exact number, but it's a lot. I have done some experiments with a good quality color system, and have observed the following: If two *slightly* different shades of the same color are adjacent to each other, the human eye can almost always pick them out. Take those same two colors and spread them apart an inch or so with some other intervening color, and you can't tell them apart. Because the human eye is so good at integrating, most pictures don't really need very many colors. Just look at some of the available 256 color VGA GIF files that float around. With a properly chosen color map, many images take on a near-photo quality. With some dithering, you can do even better sometimes. Generally, the lower the resolution, the more colors you need. With very fine pixels, fewer colors are necessary because at normal viewing distances, your eye blends and averages high frequency color transitions into a smooth appearing image. - Bill Zech Image Processing Consultant
joel@peora.ccur.com (Joel Upchurch) (12/01/89)
In article <3300@rti.UUCP>, bcw@rti.UUCP (Bruce Wright) writes: > This is certainly true for some applications, but if you want to do > image processing it can be *VERY* useful to be able to play around > with a video lookup table. For example, you can quickly and easily > highlight a portion of the image that has a particular range of values, > change the brightness mapping scale to provide better definition, > and so forth. It saves having to manipulate the image in your program > and reload it onto the screen (saving both execution time and programming > time, at least for large classes of display devices). I think you are are quite correct when we are talking about fairly small color maps. What I'm not so sure about is what is most efficent when the size of the color map is on the same order of magnitude as the video buffer, which it seems to me that it is when you start talking about 64k different colors on screen. It seems to me that at some point that overhead of maintaining the color lookup table tends to overwhelm the factors you mention. I could be wrong though, it is outside my area of expertise. > > Also, if the predefined colors aren't enough (for example, many images > are processed with between 256 and 2048 shades of grey, which exceeds > what you can get with 5 bits each for R,G,B = 32 shades of grey unless > you get a monitor that can combine the signals from more than one of > the color guns), you can always re-arrange the color map to get more > of the types of colors you need and fewer of the ones you don't need. You are quite right. 32 shades of gray isn't enough. Of course, if they are using some superset of normal VGA modes with 6 bit DACs, they only get 64, which isn't much of an improvement. Even if they use 8 bits a piece for RGB they only get 256 levels of gray, your lower limit. It seems to me that another mode is needed for working with gray-scale images, rather than mapping it on to color modes, so you can get more bit of resolution for the gray-scale modes. This raises another question with me. How is the cost of a DAC effected by the number of bits of input resolution? What is the cost differental of 6 bit versus 8 bit versus n bit DACs? If you had a high resolution gray scale mode, would it be cheaper to have a seperate DAC for it, that set the R, G and B signals to the same levels, or use 3 high resolution DACs all the time? Of course in real life, all these DACs probably wind up on one chip, but which chip is cheaper to make? -- Joel Upchurch/Concurrent Computer Corp/2486 Sand Lake Rd/Orlando, FL 32809 joel@peora.ccur.com {uiucuxc,hoptoad,petsd,ucf-cs}!peora!joel Telephone: (407) 850-1040 Fax: (407) 857-0713
bcw@rti.UUCP (Bruce Wright) (12/02/89)
In article <4037@peora.ccur.com>, joel@peora.ccur.com (Joel Upchurch) writes: > In article <3300@rti.UUCP>, bcw@rti.UUCP (Bruce Wright) writes: > > This is certainly true for some applications, but if you want to do > > image processing it can be *VERY* useful to be able to play around > > with a video lookup table. [...] > > I think you are are quite correct when we are talking about fairly small > color maps. What I'm not so sure about is what is most efficent when the > size of the color map is on the same order of magnitude as the video > buffer, which it seems to me that it is when you start talking about > 64k different colors on screen. You can certainly get enough bits to make a lookup table impractical, but that point is highter than 64k colors. That corresponds to 16 bits per pixel, and a LUT oF 65536 words (in whatever architecture the LUT uses - maybe 16, maybe 32 bit words). For a VGA-style display (640x480), which is hardly the limit, there are 307,200 pixels or about 600KB if you have 16 bits per pixel (I realize this isn't quite a standard VGA). So in this case the LUT is still less than half the size of the display memory (about 256KB if it's 32-bit words). One advantage that it would still retain even at an approximately equal size would be that you usually need not modify _all_ of it - there are usually commands to set up a "default" lookup table and to modify only parts of it. Most systems, however, have fewer bits per pixel than 16 - like maybe 8 or 12; this is quite sufficient for many (most?) purposes: for example, most medical imaging systems (the kind I'm most familiar with) only give you maybe 8 or 12 bits of accuracy at most, and then only give you a monochrome density image. Many image processing programs add color to highlight certain density ranges (a process which can be tricky, because the eye does not process color variation anywhere nearly as linearly as it does grey scales), but it's all added, not in the original. For most interactive use, you could do with a lot less - 8 or 16 may be a bit on the lean side, but 64 (=6 bits/pixel) or 256 (=8 bits/pixel) would probably be enough for all but the most demanding (and flush) user. You are usually better off spending the extra memory to buy more pixels rather than more bits/pixel unless you're doing imaging (analysis or creation) of some sort - having more pixels reduces the jaggies (aliasing in the technical jargon). One system I've heard of had 4096 x 4096 pixels, with 32 bits per pixel (10 bits each of R, G, B, and two overlay planes for annotations) which was used for satellite photographic data. Clearly _this_ system can't use a lookup table (which would require over 4,000,000,000 entries, presumably of at least 4 bytes each ... far larger than the size of the primary image storage). > This raises another question with me. How is the cost of a DAC effected > by the number of bits of input resolution? What is the cost differental > of 6 bit versus 8 bit versus n bit DACs? If you had a high resolution > gray scale mode, would it be cheaper to have a seperate DAC for it, > that set the R, G and B signals to the same levels, or use 3 high > resolution DACs all the time? Of course in real life, all these DACs > probably wind up on one chip, but which chip is cheaper to make? I'm not a video design engineer, but my impression from the way I usually see things done both for video generators and for A-D and D-A boards is that anything up to a 12 bit A-D or D-A device is not terribly expensive but that the cost goes up rapidly if you want more than 12 bits. At least until fairly recently, the dominent cost of going to more bits/pixel was not the higher resolution DAC you'd need to make the upgrade worthwhile, but the memory you'd need to store all that data. Since memory is finally dropping down into a more reasonable price range, this may no longer be true. Bruce C. Wright