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 magnifier. 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 this regard.

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.)

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.

8.6.4.1: 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 lickserv 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; figdisp is simply informed about the locations of the new sections of an incoming image.

8.6.4.2: 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 FITS file.

8.6.4.3: 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 that of lickserv and 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 <sla@ucolick.org>
$Date: 1996/03/19 06:36:36 $