8.6: Inheritance from existing image display tools
The interfaces provided in Figdisp, SAOtng, and ESORTD all appear
to provide a good core of
what will be needed for the real time mosaic display.
None of them is currently capable of handling mosaicked images
for actions such as WCS readback from mouse tracking.
SAOtng and ESORTD provide the ability to overlay arbitrary complex
graphics in the manner of the DEIMOS requirements
8.6.1: The image display widget
SAOtng uses the NOAO ximtool widget which forces the panner and
magnifier to occupy a location within the body of the ximtool widget.
ESORTD is written in Tk, which means that it is quite simple to
rearrange the elements of the display.
For an 8k x 8k image it
will be very desirable to be able to split the main image, panner, and
In order to make optimum use of whatever screen real
estate is available it would be preferable that these be able to be
sent to different X DISPLAYs, not just different X windows.
With images of size 8k x 8k, when there's no hope of getting the entire
image onto the screen unbinned, the roles of main/panner/magnifier
may change. We think that such a GUI needs to be built and tested
to see how best to arrange for user interaction under a variety of
display/window manager scenarios. The Tk wrappers around the ximtool
widgets of SAOtng and ESORTD should allow for easy experimentation in
8.6.2: A more sophisticated FITS-in-memory scheme
The current shared memory schemes for interprocess communication of
FITS images require that there be a fully-conformant FITS bitstream in
memory. No matter how we end up storing the pieces this will not
always be true when the image comes from a mosaic.
The other DEIMOS documents
describe a scenario where the output of all of the amplifiers
is mosaicked in memory. It is intended that there should be a legitimate FITS
header preceding this, and that it will correctly describe the
mosaicked image. In large part this would work with the existing
SAOtng, ESORTD, and with most other existing image display tools. Indeed,
this is the motivation for storing the mosaic in memory in this fashion.
However it should also be possible to
construct FITS headers which apply to sub-rasters of the mosaic
(e.g., the section from a single CCD or sections which contain
logically contiguous pieces of scientific data). This would mean that
a description of a FITS object in memory would need to contain
(This kind of array access has a bit of Fortran 90 flavor in it.)
pointer to the header
pointer to the beginning of the image section
information about the strides required to access the section
8.6.3: A more sophisticated WCS handling scheme
A mosaicked image containing pieces from n CCDs will usually
have n different WCSs. The display should be able to
determine where the boundaries between the CCDs are, and switch WCSs
accordingly. The WCS text readout that changes as the mouse tracks
will probably want some enhancing. In the case of the NOAO ximtool
widget it would be desirable to move the coordinate tracking display
outside the image window.
When the mouse is over one of the prescan/overscan pixel sections
it should identify the pixel coordinates and the CCD/amplifier.
When moving over a direct image it should give sky coordinates.
When moving over a spectral frame it should be able to use the
FITS table that describes the slitlets and identify
the slitlet, object, and rest wavelength.
In the general case this basically amounts to making a very easily
extendible interface through which the text that is being displayed
can be specified. It should be easy for any instrument-specific
text display routines to be inserted.
8.6.4: Real Time Display issues
Even if DEIMOS CCD readout reaches its most optimistic goal it will still
take a notable amount of time for the image to arrive.
During and after the readout the observer will want to be able to see
and perform quick look interactions with the image.
220.127.116.11: Existing Keck scheme
In the existing Keck schemes it is the responsibility of a process
lickserv) of the data acquisition system (DAS) to do the
allocation and writing of the section of memory where the image is
stored. When readout of a new image begins
informs the display client
figdisp of its size and shared
memory location via properties on an X11 server. As
lickserv places new chunks of the image into shared
memory it continues to communicate with
figdisp through X
properties. With each new message
figdisp updates the
real-time display. The number of amplifiers simultaneously feeding
the image into shared memory is not a limitation;
is simply informed about the locations of the new sections of an incoming
18.104.22.168: Changes needed for DEIMOS
When a DEIMOS image has been transferred completely from CCD
controllers into memory the DAS may slice it up as it writes it into
one or more FITS files on disk. Thus in most cases the DAS will want
to create more than one FITS header to accompany the mosaicked
observation. The manner of slicing will have been dictated by the
observer and the type of observation. The FITS Grouping Convention
will be used to associate the various pieces of the mosaic image.
This will require a unique ID to be assigned and written into each
22.214.171.124: Changes for a generic scheme
For a generic display the most prudent course of action seems to be to
permit the image to be acquired by some instrument- or site-specific
process and placed into a shared memory segment. The ability to
have shared memory FITS headers separate from data units will be very
useful in such a real-time environment. Standardization of a set of
FITS keywords that describe the nature of the mosaic is important.
SAOtng already uses XPA to manipulate X11 properties in a fashion much like
figdisp. The XPA protocol
would need to be extended in the fashion of Keck to permit communication
of the availability of subsections of the incoming image as they arrive.
ESORTD uses the Tcl/Tk ``send'' mechanism for interprocess communication;
this also makes use of the X11 server as an intermediary.
Different CCD amplifiers on the mosaic may have differences in their
bias and gain. With the current Keck DAS this can often produce
step-function artifacts between the sections of the CCD. For maximum
utility it may be necessary for the display client to use the overscan
to perform some crude color map adjustments.
Steve Allen <firstname.lastname@example.org>
$Date: 1996/03/19 06:36:36 $