Graphics on SUN's; SUN tape drive operations
John Lange
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
Robert Harker, All around good guy
>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
har...@well.UUCP (Robert Harker, All around good guy)
che...@tcgould.tn.cornell.edu.uucp
>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
web...@klinzhai.rutgers.edu.uucp
che...@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 (web...@aramis.rutgers.edu
web...@red.rutgers.edu
topaz!webber)
da...@onfcanim.uucp.uucp
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.