5. Guider System and Object Acquisition Software
5.A The Guider System
The guider system, or simply "guider", consists of the guide camera(s)
and related electronics, optics and software.
For purposes of discussion here, we will refer
to the optical system bringing light onto the detector as the
the detector and related controlling electronics as the
and the software and electronics for maintaining a position on the sky as the
The guide camera, autoguider and the image display and analysis tools will be
referred to collectively as the "TV image subsystem".
The TV optics include elements such as filters,
diaphragms, reticles and focusing mechanisms, and is considered
part of an individual science instrument such as DEIMOS.
The guider has two major and alternating functions:
In addition, the guider may be used for some other valuable (but sometimes
non-traditional) functions, including:
- target acquisition; and
- holding a fixed position on the sky ("guiding").
The guider software consists of these elements:
- evaluating and monitoring observing conditions (eg, seeing, transparency);
- approximate aperture photometry;
- calibrating the telescope pointing and focus; and
- at Keck, checking alignment of optics (eg, stacking of segments).
Control of the TV optics, as part of a science instrument, falls under
"instrument control," although the status of such elements must be
available to the guider.
- Control of the guide camera(s);
- Image display for the guide camera images;
- Analysis of the guide camera images for acquisition (image display);
- Command of offsets to the Drive & Control System (DCS) for acquisition;
- Analysis of subimages for guiding (autoguider);
- Command of corrective offsets to the DCS (autoguider);
- Monitoring of sky and telescope conditions (eg, seeing; focus); and
- Miscellaneous analysis functions (eg stellar photometry) available via
the image display.
5.1 The DEIMOS Guider Requirements
Guider requirements for slit-mask guiding are more stringent than for
normal direct-imaging or long-slit observing, as both the x-y coordinates
and the PA need to be held to a high precision. Furthermore, the mask
alignment process requires more small-scale offsets (in three axes) than
is typically required for single-slit spectroscopic observations.
For these reasons, it is important that the observer have access to an
easy-to-use control of the guider. As part of that access, we recommend
a guider console that should be located between the Observing Assistant and
the DEIMOS observer(s). More on the rational for a separate console can be
found in Section 5.10.
For the remainder of this section, we will assume a single guide camera,
of size 1K x 1K (or 1K x 0.5K) pixels and field-of-view about 3 arcmin across.
(Note that a second DEIMOS guide camera may be constructed in the future;
such a camera would enable tracking of image rotation.)
The camera will look at either an offset field
or at the slitmask (semi-polished) or polished long-slit jaws,
as chosen by the observer. We assume a reticle (parfocal with the slitmask)
in the offset position, and reference marks on the slitmask itself; these
enable us to focus the camera independently of telescope focus, and to
track guide-camera flexure. We will not discuss the design or requirements
of the CCD control (guide camera), nor the TV optics.
We have the capability of using this guider as a science instrument,
and we choose to use it to provide supplemental information
for the actual science observations. Such functions include monitoring
In addition, we propose the option of coadding guider images during each science
integration - this summed image would be attached to the science
image file, and would provide a record of the average conditions during
the exposure. In a slit-viewing mode, this would also provide an
unambiguous location of the slit across targets of interest. Depending on
the ability to calibrate the guider throughput (particularly off the slitmask),
it may be possible to derive photometric calibrations from these images as well.
- FWHM (that is, seeing and focus changes);
- counts (that is, transparency);
- sky background (very useful for beginning and end of nights);
- autoguider offsets (history of motions as diagnostic).
Finally, since the DEIMOS TV optics will have some sort of reference objects
at the telescope focal surface (ie a reticle in offset mode; the slitmask
itself in slit-viewing mode), we will be able to focus the guide
camera on the telescope focal plane. Once the camera is focused,
we have a means of focusing the telescope. The guider should take
advantage of this opportunity for real-time focus of the telescope -
perhaps even during a pause in a long science integration.
Fig. 5.1 - Possible Guider Image Display
Fig. 5.2 - Possible Guider GUI
Fig. 5.3 - Proposed Control Room Layout
See terms for the guider components in Overview above.
in image display (Chapter 8).
With regards to the guider image display,
transfer function refers to the mapping of intensity data into
the [effective] video memory of the display, while look-up table (LUT)
refers to how the video memory gets mapped into colors and intensities on the
More details may be found in image display
Acronyms used in the chapter: DCS is the Drive and Control System;
LRIS is the Low Resolution Imaging Spectrograph;
OA is Observing Assistant.
5.4 Software Functional Requirements
5.4.1 Guide Camera Control
The user needs control of the following from the guider control interface:
- read-out modes (eg subrasters)
- integration time / frame rates
5.4.2 Guider Image Display
The image display is used for several purposes, including target identification
and positioning, selecting a guide star and analyzing conditions.
While it may or may not
be the same image display tool that is used
for display of full DEIMOS images, it is essential that
of simple display functions (zoom, pan, LUT control) and analysis functions
(eg distance measurement, coordinate system overlay, stellar image analysis)
appear identical between the two. The necessary features for the guider
image display are:
It is necessary to have a default mode in which the transfer function limits
(ie min, max) should be automatically selected to
provide useful threshold and contrast for most applications.
However, the user should also have the ability
to adjust these limits (or reset them to default values).
- Full image display;
- Zoom and pan capability;
- Lookup table (LUT) and colormap control;
- A "ruler" to measure distances (in various coordinate systems)
on the display;
- Compass rose to indicate orientation of N and E;
- Optional coordinate grid overlay on image;
- Optional overlay of catalog object positions on image;
- Stellar image statistics, including FWHM and approximate magnitudes;
We also propose that the most recent guide camera images (say up to 8) can
be stored in memory so that they may be optionally averaged as a "leaky" memory.
The images automatically displayed would then be either the most recent
(ie "real-time") image or an average of the last two (or four or eight).
5.4.3 Object Acquisition (Offset Control)
- Graphic "handpaddle" control (buttons for left, right, up, down, CW, CCW;
- Offsets by numerical value (eg, 8 arcsec N, 2.3 arcsec E). If the
autoguider is on, the target position will be graphically indicated
by a circle or box so that it is trivial to visually confirm that the expected
offset was achieved;
- Point-and-drag offsets: by this, we mean that a reference object is
selected by mouse click, then the position where the observer
wants it is selected, with the offset vector "dragged" out by the mouse.
The target position is marked as above;
- Identification of target object, for which the needed offsets to a nominal
position - eg, the center of the longslit - are automatically derived
(target position marked as above);
- Optional centroiding during selection of reference object (target ID,
- "Memory" of selected locations (eg, for alternating between two
positions on the sky);
- Graphical position marker(s) - eg circles or crosses to mark
positions of interest to the user.
- Simple Autoguider ON/OFF switch;
- All offsets for which the autoguider must be interrupted will
perform the interruption/resume automatically. This primarily concerns
rotations, in which case the autoguider should stop guiding, then calculate
the offset introduced by the rotation about the instrument center, reposition,
and then resume autoguiding.
In order to keep offset methods consistent and to have a reasonable degree
of user verification, we propose the following rules for offsets:
- Clicking on (and/or holding) the "handpaddle" buttons will
instantly apply offsets;
- Offsets entered by numerical value (or point-and-drag - see below)
will require an "apply" button to be pushed;
- For this latter kind of offset, there will be three associated switches:
"clear," "apply," and "reverse" (undo);
- Offsets by numerical value will be specified by the three fields
delta-Dec, delta-RA and delta-PA. However, a blank field implies an offset of
0. Thus, clicking on "clear" will clear all fields and values may be entered
into one, two or three fields as desired.
- The mask alignment program and the "point-and-drag" option will both
talk to the "Numerical Offset" fields. Completion of the mask alignment
analysis will place the calculated offsets into the numerical offset window,
and the "apply" command must be sent to actually perform the offset.
5.4.4 Software for Autoguiding
Note 1: The reference marks at the focal plane serve as fiducial
points, so that flexure in the guide camera system can be automatically
- Center on reference marks and update the guider coordinate system
(see note 1);
- Center on object image(s) (see notes 2,3), calculate and send correct
incremental offsets to the DCS.
- Keep a running record of applied offsets, and take corrective action
if needed -
eg, adjust the "track rates" for repeated similar offsets, or slightly adjust
integration times or offset rates if position is oscillating;
- Perform stellar image analysis and keep a running record of
count rates, FWHM and sky level; sound warning alarm (voice message) if count
rates drop too low (ie, clouds; guide star lost).
Note 2: There are several possible algorithms for centering, and at
least two should be available to the user. One is the "balanced quadrants"
method, where the object is divided into four and the amount of light
in each quadrant is equalized. This method is particularly useful
if autoguiding on spilled light from an object in a slit. A cross-correlation
algorithm would also be quite useful if the guide object is extended
rather than stellar.
Note 3: Ideally, we should be able to autoguide on several objects
simultaneously, by either coadding the images or averaging the offsets.
This would enable the use of several fainter stars if a suitably bright
guide star is not available. Also, it provides a "pass-off" mechanism
for guide stars which move outside the camera field-of-view during offsets.
5.4.5 Miscellaneous Software
We will need software (as yet unspecified) to support image analysis for
focusing of both the TV camera and the telescope.
We will need software to coadd the guider images during science
integrations, and to communicate with the DEIMOS exposure control and
5.5 Possible designs
Two sketches of a possible image display and
guider GUI are shown in the figures.
5.6 Existing Software and Tools
The ESORTD image display tool may be adaptable for this component.
5.7 Other Resources Required
The hardware for the guide camera is yet TBD.
5.8 Dependencies on Other Components
The guider images and related information about seeing, transparency and
sky background will be logged. Object catalogues for positional overlays
will require access to the database.
(See Database/logging, Chapter 9).
5.9 Outstanding Issues
There is some concern that the read-out and display rates can be made
sufficiently fast. We expect camera read-outs at a frequency of about 1 second;
for each readout, we will need to coadd the data (for the integrated
science images), possibly coadd the data in memory for a "leaky-memory"
scheme, and display the image.
5.10 Control Room Layout for DEIMOS Observers
DEIMOS is a large and sophisticated instrument. It is likely that its
efficient use will require at least two observers, particularly if two
barrels are in place. However, the instrument should be operable
with only a slight loss in efficiency by a single observer.
In addition, effective interaction with the Observing Assistant is essential.
As part of the DEIMOS design, we wish to consider a physical layout that
promotes efficient observing, for the cases of one or two observers plus an
Observing Assistant. We adopt the standpoint that:
Part of this consideration requires that certain ``territorial rights'' be
defined. We propose the following:
- The physical environment for control of the telescope
and instrument must facilitate ease-of-use. The physical layout of
computer keyboards, monitors and image displays, and access to telescope
information or control via the Observing Assistant, should be
carefully considered. A well-planned layout can considerably aid
efficiency of operations such as target acquistion, mask alignment and
guiding; whereas a poorly-planned layout can contribute significantly
to mistakes in communication and lost observing time.
(In the above, we have selected 2 arcmin for the critical size as
it is roughly the radius of the guider field. The actual critical size is TDB.)
With these divisions of ``territory'' we propose the following
physical layout, in sequential order:
- The observer(s) will nominally have exclusive control of the following:
- Spectrograph internal stages, including the mask changer and hatch;
- Detector (shutter, CCD controller, and all downstream data flow).
- The Observing Assistant (OA) will have exclusive control of:
- large telescope motions (ie motions larger than about 2 arcmin);
- Dome (including general dome lighting);
- LN2 operations.
- The observer(s) and OA will share control of:
- small telescope offsets (ie motions smaller than about 2 arcmin);
- Instrument rotator;
- Dome calibration lamps.
Please note that shared functions may be monitored from any console,
but control should be from Console 2 (primarily or exclusively,
depending on the function - TBD).
- Console 1 - the OA's console, for performing OA exclusive functions;
- Console 2 - the guider console. Either the observer or the
OA could sit down and control the guider, the responsibility to be
negotiated by the observer and OA. This console is also used for other
- Console 3 - the instrument control console, for performing
- Console 4 - the observer's data-analysis console, for performing
quick-look and automated spectral reductions.
- DEIMOS image-display monitors (two) will be located above or beside the
instrument console (Console 3). Another two image-display monitors
will be located beside the data-analysis console (Console 4).
5.B Object Acquisition: Slitmask Alignment
Slitmask alignment is an extension of object acquisition, at a much higher
level of precision. For direct imaging, positioning of the telescope to
within a few arcseconds is usually sufficient. For single-slit
observations, positioning must be precise to within a fraction of
an arcsecond perpendicular to the slit width; usually the position angle
is unimportant or perhaps accurate to, say, 1 degree. On the other hand,
multislit observations require positional accuracy of order 0.1 arcsec
in both axes over the entire length of the slitmask. Our problem
is to position the telescope and instrument rotator to within the tolerances
in a simple and efficient manner, with minimal operator involvement.
Slitmask alignment requires the use of both the guider
and the DEIMOS CCD array.
The guider is used for approximate positioning during the initial stages
and for autoguiding during the final adjustments.
The following goals are included in mask alignment design:
The procedure described here is based on that developed for LRIS slitmasks
by the DEEP group at UCSC.
It uses alignment boxes and alignment objects (stars)
to position the mask against the sky, by centering the stars within the boxes.
This approach has the following advantages:
- The alignment process must be fast. Ideally, we
would like an acquisition and alignment overhead of only a small fraction
of a typical science integration.
We set a target of 8 minutes for the process.
- The process must be simple. All user inputs should be
kept to a minimum and, as much as possible, should be limited to
oversight of automated routines.
- The process must be accurate. Tolerances should be a fraction
of the slit width - of order 0.1 arcsec rms.
- Alignment stars are chosen to be fairly bright, so that relatively
short exposure times (of order 30s) are sufficient to obtain accurate
- The mask remains installed throughout the procedure - no overhead in
moving the slitmask and no repeatibility worries;
- Only a small area of the detector is involved, so we may employ subraster
read-out of the CCDs to speed the process.
5.11.2 Steps in the Alignment Procedure
Suitable alignment objects are selected during mask design and
corresponding alignment boxes (typically 3 arcsec square) are cut during mask
fabrication. To set up on a mask at the telescope:
With LRIS, CCD positions for the boxes are obtained
from direct images through the masks
taken with calibration lamps during the daytime, but in principle we should
be able to adequately predict the CCD positions of alignment boxes.
- The field is acquired and PA is set; the spectrograph is placed
in direct imaging mode and the mask inserted.
The guide star is placed in its expected position on the guide camera, and
guiding is started.
(This should be sufficiently close to correct alignment that the alignment star
images will fall in the boxes on the mask.)
- The observer takes a direct image through the mask. For DEIMOS,
we will need to read out and analyse only those small regions near the
- The location of each star relative to its alignment box is measured
via a semi-automated routine,
and a solution to delta-RA, delta-Dec and delta-PA is determined.
These offsets are sent automatically to the guider/offset control
and the offsets are applied.
- Repeat the last 2 steps as needed until the alignment stars are centered
in their boxes.
- The grating is moved into place and the science integration begins.
The centering algorithm used by the DEEP group for LRIS is based on
edge detections for both the stellar image and the alignment boxes. The only
required inputs are star FWHM and box size in pixels (see Fig. 5.15-1).
For each star/box
pair, a plot shows both x- and y-profiles through the box; the user sets
a single sky level and the algorithm finds both the box and star centers.
Generally only two keystrokes are needed for each alignment star/box.
After all the alignment stars are examined, the solution is shown graphically
and the user must simply use a single keystroke to exit. The entire
alignment solution takes well under 1 minute to execute once the image is
available for analysis.
Using this general procedure, we have performed successful alignments of
LRIS in under 20 minutes,
from the end of one science integration to the start of the next. LRIS
requires close to 10 minutes for two grating-mirror changes and a mask-to-mask
change. DEIMOS overhead for the equivalent operations will be about 4 minutes
both because of simpler grating motions and because stages will run in parallel.
Furthermore, it is likely that specialized read-out for DEIMOS alignment will
be shorter (15 sec or less) than the entire LRIS read-out (40 sec).
Based on our experience, it seems likely that we may acquire and align on a
field within our target of 8 minutes (not including telescope slews).
Note that the mask in the second barrel (when constructed) must be
aligned relative to the first mask, ie., by internal motions,
rather than by repositioning the telescope and instrument rotator.
The procedure above is therefore slightly modified, with offsets being
calculated for the internal-stage motors rather than for the telescope
and instrument rotator.
Fig. 5.4 -
Alignment Box/Star Centering Algorithm.
5.14 Specific Functional Software Requirements
The needed functionality already exists for LRIS, with the exception of
communicating the offsets directly to the telescope and instrument rotator.
All of the steps will be executed by a single command.
The mask alignment for the second barrel differs only in that commands must
be sent to motors in the spectrograph which reposition the mask.
- Find precise box location (must be robust, but box size and approximate
location are known a priori).
- Find precise star location within box (must be robust; star FWHM is
roughly known a priori).
- Derive offsets and rotation from the values above. This function
must be interactive in an easily visualized fashion, so that spurious points
can be detected and removed easily.
- Communicate offsets and rotation directly to telescope and instrument
(We envision that the Observing Assistant or observer will be required to
give a confirming "go ahead" command from the guider.)
5.15 Design Notes
With a priori knowledge of the size of the alignment boxes and
approximate FWHM of the alignment stars,
a very robust centering algorithm is available
(similar to that used in the IRAF "identify" task). The profile is convolved
with the profiles shown in Figure 5.15.1, and
the zero-crossing indicates the center. This method weights toward the
edges of the features (stars or box) provided the FHWM is appropriate. It is
insensitive to errors in background level and the presence
of most cosmic rays.
5.16 Existing Software
As noted above, comparable software for LRIS has already been developed at UCSC.
Except for communication with the DCS/instrument rotator, no significant
modifications would be required.
5.17 Additional Resources Required
5.18 Interfaces with Other Modules
The software must access the mask design and the current distortion maps in
the database (Chapter 9) to get the approximate
locations of the alignment boxes on the CCD array.
It must also communicate with
the "offsets" section of the guider control (5.5 above) or the DCS.
The software will be interfaced with the
image display (Chapter 8) in
order to display residual vectors on top of the alignment object images.
5.19 Outstanding Issues and Concerns
Chapter 5 was assembled by Drew Phillips.
Last modified: 19 mar 96