johnl@auscso.UUCP (John Lange) (03/16/87)
I have recently begun to play with the graphics capabilities of our SUN3/160. It has a color display that is capable of displaying a total of 256 colors on the screen at one time. This is done by choosing from a pallette of 2^24 colors. To set the colormap of 256 colors, it is necessary to specify red, green, and blue indeces of [0] to [255]. In my endeavors, I have discovered that approx. the first 100 levels of indeces in the red, green, and blue come out looking virtually identical - they are all VERY dark. This may be a hardware problem with our particular SUN. It seems a bit wasteful to have 256 indeces when only the last 150 or so look different. It would be MUCH more practical and useful to make the 256 indeces about equal perceptually. Most high quality pictures are digitized in this manner. Thus, to display a picture using as many perceptually different colors as possible requires the use of logarithmic scaling of the indeces. THERE'S GOT TO BE A BETTER WAY!! My next question is also SUN specific. Does anyone know why the tape drives only work at 1600 bpi??? Even the lowly IBM RT can save at 6250 bpi. I can't think of a good reason why the SUN workstations couldn't save at 6250. The speed increase would be about a factor of 4 with very little additional hardware or software. While I'm on the subject, why is the default blocking factor so low?? All SUN's that I have used work with at least 126, and again, it's a lot faster. One other bug on the SUN's: I have a problem with our machines getting hung when the tape is not rewound before usage (with the 'mt rewind' command). It only shows up once in a while - not every time. When it happens, it looks like it's hung in the tape driver. I have read of other people's similar problems, and am wondering if anyone has found the cause or a solution. Reply to: John Lange Radian Corporation voice: 512-454-4797 x. 5747 net: altair!johnl or whatever it says at the top of this
harker@well.UUCP (Robert Harker, All around good guy) (03/18/87)
In article <14@auscso.UUCP> johnl@auscso.UUCP (John Lange) writes: >My next question is also SUN specific. Does anyone know why the tape >drives only work at 1600 bpi??? Even the lowly IBM RT can save at >6250 bpi. I can't think of a good reason why the SUN workstations >couldn't save at 6250. The speed increase would be about a factor >of 4 with very little additional hardware or software. Two things could be wrong here: The first is that your hardware may only support 1600 BPI reads and writes. If it is a CDC tape drive purchased form Sun, this is the case. If your tape drive is a Fujitsu (with a Xylogics tape controller board) or some other tape drive that supports 6250 BPI, then you may be using the wrong device number when you write your tape. If you tape supports software tape density select then use the following table to select your drive: /dev/rmt0 1600 BPI, rewinding device /dev/rmt4 1600 BPI, non-rewinding device /dev/rmt8 6250 BPI, rewinding device /dev/rmt12 6250 BPI, non-rewinding device I hope this helps RLH harker@well.UUCP (Robert Harker, All around good guy)
cheryl@TCGOULD.TN.CORNELL.EDU.UUCP (03/26/87)
In article <14@auscso.UUCP> johnl@auscso.UUCP (John Lange) writes: >I have recently begun to play with the graphics capabilities of our >SUN3/160. It has a color display that is capable of displaying a >total of 256 colors on the screen at one time. This is done by >choosing from a pallette of 2^24 colors. To set the colormap of 256 >colors, it is necessary to specify red, green, and blue indeces of >[0] to [255]. In my endeavors, I have discovered that approx. the >first 100 levels of indeces in the red, green, and blue come out >looking virtually identical - they are all VERY dark. This may be a >hardware problem with our particular SUN. It seems a bit wasteful >to have 256 indeces when only the last 150 or so look different. It The 255 different levels are 255 settings on the VOLTAGES of each of the 3 color guns. It is a well-known principle of computer graphics that there is a nonlinear relationship between these these voltage settings and the actual intensities that are displayed on the screen. In fact, it is an exponential relationship. Standard nomenclature refers to the factor in this exponential relationship as GAMMA, hence the phrase "GAMMA correction." Since the gamma correction necessary varies from monitor to monitor, most manufacturers of graphics hardware leave it up to the on-site computer graphics wiz to do the gamma correction herself -- or himself as the case may be. Cheryl Stewart MSI Computer Support
webber@KLINZHAI.RUTGERS.EDU.UUCP (03/26/87)
In article <8703252224.AA09472@tcgould.TN.CORNELL.EDU>, cheryl@TCGOULD.TN.CORNELL.EDU (cheryl) writes: > The 255 different levels are 255 settings on the VOLTAGES of each > of the 3 color guns. It is a well-known principle of computer > graphics that there is a nonlinear relationship between these these > voltage settings and the actual intensities that are displayed on > the screen. In fact, it is an exponential relationship. Standard > nomenclature refers to the factor in this exponential relationship > as GAMMA, hence the phrase "GAMMA correction." Since the gamma > correction necessary varies from monitor to monitor, most > manufacturers of graphics hardware leave it up to the on-site > computer graphics wiz to do the gamma correction herself -- or > himself as the case may be. The nonlinear relationship between the voltage and light energy emitted by the phosphors is indeed GAMMA, but this is not an exponential relation. It is a low order polynomial, roughly x to the 2.2 (on average maxing around x to the 2.8 for some monitors). There is an exponential relationship between light energy and the neuropsychological perception of brightness, but that is another matter (i.e., you would percieve x, 1.02 * x, 1.02 * 1.02 * x, 1.02 * 1.02 * 1.02 * x, etc. as a linear progression in brightness although x is light energy). Thus GAMMA correction is a monitor hardware internal problem whereas the exponential intensity perception is a psychoneurological phenomenon. Although there are doubtless many technical references on this material, a good introduction to this sort of thing is: Raster Graphics Handbook (Second Edition), by Conrac Division, Conrac Corporation, published by Van Nostrand Reinhold Company, in 1985. - ------------------------------------ BOB (webber@aramis.rutgers.edu webber@red.rutgers.edu topaz!webber)
dave@onfcanim.UUCP.UUCP (03/30/87)
In article <132@brandx.klinzhai.RUTGERS.EDU>, webber@KLINZHAI.RUTGERS.EDU (Webber) writes: > In article <8703252224.AA09472@tcgould.TN.CORNELL.EDU>, > cheryl@TCGOULD.TN.CORNELL.EDU (cheryl) writes: >> The 255 different levels are 255 settings on the VOLTAGES of each >> of the 3 color guns. It is a well-known principle of computer >> graphics that there is a nonlinear relationship between these >> these voltage settings and the actual intensities that are >> displayed on the screen. In fact, it is an exponential >> relationship. Standard nomenclature refers to the factor in this >> exponential relationship as GAMMA, hence the phrase "GAMMA >> correction." Since the gamma correction necessary varies from >> monitor to monitor, most manufacturers of graphics hardware leave >> it up to the on-site computer graphics wiz to do the gamma >> correction herself -- or himself as the case may be. > > The nonlinear relationship between the voltage and light energy > emitted by the phosphors is indeed GAMMA, but this is not an > exponential relation. It is a low order polynomial, roughly x to > the 2.2 (on average maxing around x to the 2.8 for some monitors). > > There is an exponential relationship between light energy and the > neuropsychological perception of brightness, but that is another > matter (i.e., you would percieve x, 1.02 * x, 1.02 * 1.02 * x, 1.02 > * 1.02 * 1.02 * x, etc. as a linear progression in brightness > although x is light energy). > > Thus GAMMA correction is a monitor hardware internal problem > whereas the exponential intensity perception is a > psychoneurological phenomenon. > > Although there are doubtless many technical references on this > material, a good introduction to this sort of thing is: Bob Webber points out that the relationship between screen intensity and video signal voltage for a CRT is really a polynomial, not exponential as Cheryl said. He's technically correct, but Cheryl's description is basically right. Writing it down as a formula, gamma screen_luminance = (signal_voltage) where '=' really means "is proportional to". Perhaps this should be called a "power law" relationship, since "exponential" isn't correct. The value of "gamma" varies with the monitor. Also, note that this is only an approximation - the response of a real monitor is more complex. This non-linearity of the monitor is usually corrected for by loading the frame buffer's colour lookup table with a table that generates the correct signal voltage for each possible pixel value. Making use of the approximation above, for a pixel intensity I in the range [0..1], and a video DAC whose inputs are in the range [0..DACMAX], the DAC input (and thus lookup table entry) should be table_entry = round_to_int(DACMAX * I ** (1/gamma)) This is referred to as "gamma correction". This ensures that the intensity of light coming off the phosphor is proportional to the intensity that you calculated for that pixel (except for errors in the "gamma" model of CRT behaviour). However, none of this really addresses the original question, which was (paraphrasing) "how do you select a representative set of intensities for each colour?". The most common method of having pixel values represent intensities in a frame buffer with 8 bits per pixel per colour is to have a pixel value of P represent an intensity of P/255. This produces the cheapest pixel encoding to calculate, but it is not the best use of the bits. The visual system responds to the ratios of brightnesses between areas, not the absolute difference - it is effectively a logarithmic measuring device. If you display a set of equal-sized objects with luminances of 1, 2, 4, 8, 16, 32, and 64 foot-Lamberts, you eye will perceive equal brightness changes between each patch. Thus, to make the best use of a small number of bits per pixel, the available pixel values should be spaced evenly in perceptual brightness, which means that the pixel codes should be the logarithm of intensity, scaled appropriately and rounded to an integer. For example, if you have 8 bits per pixel (per colour), and want to encode an intensity range of [0.01, 1], the pixel value is given by P = round_to_int(255 * (1.0 - log(I) / log(0.01))) It doesn't matter whether "log" is base-10 or base-e. Note that you have to decide in advance how much intensity range you want to encode, and that intensities below this range produce negative pixel values that you have to clamp to 0. As long as the number of DAC bits is about 2 or more greater than the number of pixel bits, log encoding is the "optimum" method of encoding intensity in pixel values. When you only have 8 bits per pixel for all colours, you have to divide them carefully. The simplest method is to use 3 bits for each of red and green, and 2 bits for blue (since blue does not appear as bright to the eye as red or green, it contributes less to overall perceived brightness). Thus you get 8 distinct values of red and green, and 4 of blue. Intensities are converted to pixel bits using the formula above (with 255 replaced by 7 or 3) and then shifted and ORed together. An alternative that provides more equal resolution in all colours is to encode red and blue as integers in the range [0-5] and green in the range [0-6]. Since 6*7*6 < 255, this will work. The pixel value is encoded by multiplying: P = (R*7 + G)*6 + B Using 7,7,5 instead of 6,7,6 will also work. Whatever way the pixels are encoded, the decoding is done by the colour lookup table. For each entry in the table, calculate the red, green, and blue intensities represented by that particular pixel code taking into account the way they were encoded (linear or logarithmic) and packed (shifts or multiplies). Then calculate the DAC input needed for each of the RGB intensities using the gamma correction formula above, and you have your colour table entry.