.TL
The IIS Image Display
.AU
Richard Wolff
.br
Central Computer Services
National Optical Astronomy Observatories
Tucson, Arizona 
.DA
.PP
The International Imaging Systems (IIS) Model 70f is a reasonably
flexible image display with some more advanced capabilities than the IPPS,
(and, sad to say, some less advanced ones as well).  This note describes
the hardware so that the user can use the device to best advantage.
The Model 75, which is in use at CTIO, is more elaborate still, but its
fundamental properties are the same as the 70f boxes in use at NOAO.
.PP
The image display has four image planes (frames, memories), each of which
can hold a 512 x 512 8 bit image.  (The hardware can support 12 such planes,
but only four are installed in the NOAO units.)  These planes are loaded
directly from the host computer;  while there is hardware to support a
13-bit input/8-bit output mapping during load, this is not currently used
at NOAO.  The frames are numbered 1 through 4 and there is nothing to
distinguish one from another.  More than one image plane may be displayed
at one time; this may create a rather messy screen image, but, of course,
the hardware doesn't care.
.PP
The image is generated by hardware that
addresses each pixel in turn, and sends the data at that location to the
video display.  Panning (scrolling/roaming) is accomplished simply by
starting the address generation somewhere other than at the normal starting
place.
Each plane has its own starting address, which just means that each
plane can be panned independently.  In contrast, on the model 70,
all planes zoom together.  Zooming is done by pixel replication:
The master address generator
"stutters", duplicating an address 2, 4, or 8 times before moving on to
the next pixel (and duplicating each line 2, 4, or 8 times--an additional
complication, but a necessary one, which is of interest only to hardware types).
The master address is then added to the per-image start address
and the resulting address streams are used to generate
the per-image data streams, which are added together to form the final image.
The net result of this is an image on the screen, with user control of the
placement of each image plane, and with one overall "magnification" factor.
.PP
If more than one image is active, the pixel values for a given screen
position are \fBadded\fR together.  Thus, with four image planes, each of
which has pixels that can range in value from 0 through 255, the output
image can have pixel values that range from 0 through 3060.  Unfortunately,
the output hardware can handle only values from 0 through 1023.  But,
fortunately, hardware has been included to allow the use to offset and
scale the data back to the allowed output range.  We will look at that
in more detail later.
.PP
The hardware that determines which frames are to be displayed consists
of "gates" that enable or disable the frame output to the image screen.
These "gates" are controlled by various data bits in the hardware.
Conceptually, given the description in the previous paragraphs, one can
imagine one bit (on or off) for each image frame, and it is these
bits that the \fBdi\fR command turns on and off.  However, there are
complications, one of which is the split screen mode.  Split screen
hardware allows the user to specify a point, anywhere on the screen,
where the screen will be divided into (generally, unequally sized) quadrants.
The display control bits specify not only which images will be active,
but in which of the four quadrants they will be active.
There are four control bits per image plane, and so, any image can
be displayed in any number of quadrants (including none, which means the
image is "off").
.PP
If one imagines the split screen point in the middle of the screen, then
four quadrants are visible, number 1 being the upper right, number 4 the bottom
right, etc.  As the split screen point is moved to the upper left, quadrant
four increases in size and the other three decrease.  When the split point
reaches the top left corner (\fIIRAF\fR coordinate (1,512)), only quadrant
four is left.  Due to a hardware decision, this is the normal, non-split,
screen configuration, the one you get when you type the \fBs o\fR command.
It would make more sense to set the non-split position so the screen was
filled with quadrant one, but the hardware won't allow it.  So, be
warned, if you have a split screen display,
and then reset the split point to the "unsplit" point,
what you see will be only what you had displayed in quadrant 4.
.PP
The model 70f is a color display, not monochrome, and this adds more
complexity.  What happens is that the data from each enabled image plane
is replicated and sent to three \fIcolor pipelines\fR,
one for the \fIred\fR gun of the monitor, one for the \fIgreen\fR,
and one for the \fIblue\fR.  If the pipeline data streams are
the same, we get a black and white image.  If they differ, the
final screen image is colored.  Since there are really three data streams
leaving each image plane, it should not be surprising that there are
display control bits for each color, as well as each quadrant, of each
image.  Thus (and finally) there are 12 control bits, three colors in each
of four quadrants, for each image plane.  One can set up a display with
different images in different quadrants, and each colored differently!
Of course, the coloration is somewhat primative as the choices are limited
to red on or off, green on or off, both red and green on (yellow), blue on
or off, etc.  More control comes with look-up tables.
.PP
The data from the combined image planes is added together in the pipelines.
There are offset and range registers for each pipeline which allow you to
bias and scale the data.  Offset allows you to add or subtract a 13 bit
number (+-4095) and range scales the data by a factor of 1,2,4, or 8.
These are of interest mostly when more than one image is combined; in this
case, the resulting stream of data should be adjusted so that it
has its most interesting data in the range 0 through 1023.
.PP
Why 1023?  The reason is that after offset and range have taken their
toll, the data is "passed through" a 10 bit in/10 bit out look-up table.
Look-up tables are digital functions in which each input datum is used
as an index into a table and the resultant value that is thus "looked-up"
replaces the datum in the data stream.  The look-up tables here
are known as the \fIoutput\fR
tables (or, as IIS would have it, the "Output Function Memories").
There is one for
each of the three pipelines, and each accepts an input value of 10 bits,
which limits the data stream to 0 through 1023,
If the image data in the three pipelines are the same, and the output
tables are too, then a black and white image results.  If, however, the
pipelines are identical but the tables are different, a colored image
results.  Since this image is not a true color image,
but simply results from manipulating the three identical color
pipelines in differing ways, the result is called a pseudo-color image.
.PP
The simplest look-up table is a linear function, whose input values run
from 0 through 1023 and whose output values do the same.  The trouble
with such a linear output table is that the usual case is a single image
being displayed, in which case the pipeline data is never more than 255.
With the unit slope table, the maximum output would be 255, which is
one-quarter of full intensity.  A better table in this case would be one of
slope 4, so 255 would map to 1023 (maximum output).  This is what the
default is, and above 255 input, all values are mapped to 1023.  If,
however, two images are being displayed, then data values may be larger
than 255 (at overlap points), and as these all map to 1023, only full white
results.  The range/offset registers may be of use here, or a different
output table should be used.
.PP
The output of the "output" tables is combined with the graphics and cursor
data and sent to the display screen.  The graphics planes are one bit
deep; there are seven of them, and together with the cursor, they form
an "image" 8 bits deep.  In this sense, the graphics planes are just
like image data, and in particular, they pan and zoom just as the
image planes do.  Of course, the cursor is different.  The graphics
planes are sent through a look-up table of their own, which determines
what happens when one graphics plane crosses/overlaps others and/or the
cursor.  The resultant data replaces the pipeline data.  The graphics
data can be added to the pipeline data instead of replacing it, but this
feature is not available in \fIcv\fR at this time.  The cursor is really
a writable 46x64 bit array; thus, its shape can be changed, a feature
that may be made available to users.  Note that there is no quadrant/split
screen control for the graphics planes.
.PP
The final complication, at least as far as the current software is
concerned, is that each image plane has its own set of three look-up
tables, one for each color.  Thus, there are 4x3 frame look-up tables
and three output tables.  The image tables affect only the data from
the associated image plane.  It is the output of these tables that
forms the input to the three color pipelines.  Each table is an 8 bit in/9
bit out table, with the output being treated as a signed number (255 to
-256).  (Combining 12 9 bit numbers (a full model 70f) can produce a 13 bit
number, which is why the offset hardware accepts 13 bit numbers.)  In
the \fIcv\fR software, only positive numbers are used as output from
the tables.  Typically, the image tables are loaded with linear
functions of varying slope and intercept.
.PP
With the two sets of tables, image and output, it is possible to create
all sorts of interesting pseudo-color images.  One possibility is to
place the appropriate three mappings in the output tables so as to create
the color (for instance, red can be used only for pixels with large
values, blue for low values, green for middling ones).  Then the image
tables can be set to adjust the contrast/stretch of the each image
individually, producing, one assumes, useful and/or delightful
pseudo-color images.