Subject: time savings on DIS slit viewer

From: Russet McMillan

Submitted: Mon, 30 Aug 1999 18:31:52 -0600 (MDT)

Message number: 372 (previous: 371, next: 373 up: Index)

During the first week of the shutdown, I spent some time looking into
ways to speed up the operation of the DIS slit viewer.  Because of the
slow readout of our ST-6 SBIG camera and the need for a dark image to
subtract from each frame, waiting for the slit viewer typically costs
us around 5 to 10 minutes for each hour of DIS observations.  Reading
out a single full-frame image (with dark frame) requires more than 80
seconds of readout and download time, in addition to two exposures.
For a 17th magnitude object requiring a 30-second exposure on the
slitviewer, it would typically take 145 seconds to obtain the first
slit image (which is then saved to disk and an offset calculated), then
an additional 105 seconds for an image to confirm that the object is
on the slit, and only then are we ready to expose the instrument and
change to sub-frames on the slit viewer.  This is the minimum time
required in the case of a smooth and trouble-free acquisition.

Among the solutions I considered were new software, a new camera, or a
change in procedures.  After looking into these, I believe we can make
a significant savings in time by making a small change in procedures.
This change should not impact the science at all, but it will be
visible in some ways to the observers.  So, for the benefit of those
interested, I'll recap the possibilities.

New software is a strong contender.  A third party group called
Software Bisque has been making SBIG-compatible operating programs for
some years.  A new revision which will save multiple dark images is
supposed to be launched soon, and they have offered us the opportunity
to try the beta version.  This would give us the opportunity to take a
few darks with different exposure times in full and sub-frame mode at
the beginning of a night, and save us the necessity of taking darks
when we could be observing.  It would require some careful forethought
(and advance information from observers) to take advantage of this
feature, however.  The time savings would be most significant for
programs which include many objects of similar magnitude (same
exposure times), which can be set up on the same part of the slit for
each exposure (same sub-frame).  For programs involving many objects
of different magnitude or objects widely spaced on the slit, this
might not be so useful.  Trying to use the same subframe each time
would also make it harder to include, for example, potential
focus-check stars in the slitviewer frame.

I also looked into the possibility of a new camera.  The more recent
SBIG models (ST-7 or ST-8) should plug neatly into our hardware and
software.  But they cost a few thousand dollars, they include various
features that we don't need, and perhaps most importantly, they have a
slightly smaller area.  The current slitviewer already fails to cover
the entire slit, and any further loss in field of view would be
undesirable.  A change in optics for the camera is always possible, of
course, but would not include the appeal of an easy and modular
transition.  If we are to go that far, we might as well consider a
completely new camera (the Apogee, for example, has an appealingly
fast readout).

Then I considered a change in procedure: namely, binning.  As
currently used, the slit viewer has rectangular pixels that are 0.28
by 0.34 arcseconds each.  This is sufficient resolution that 2 X 2
binning should not cost us much accuracy in centering.  Unfortunately,
the ST-6 does not offer 2 X 2 binning.  Our choices are 1.5 X 1 and
1.5 X 2.  Low resolution (1.5 X 2) requires about 25 seconds for
readout of a full-frame image with dark, as compared to >80 seconds
for 1 X 1 binning.  This is a significant savings in time.  For the
example above showing setup on a 17th magnitude object, the time costs
would now be 85 seconds for the initial image (pause for object
identification and offset), and an additional 50 seconds for
confirmation.  Clearly, the savings would be greatest for brighter
objects where the readout dominates over the exposure time.

The obvious disadvantage to binning this way is that the aspect ratio
of the images, already slightly skewed by the rectangular pixels, will
be less representative of the real sky.  Fortunately, there is an
option in our control software to resample the pixels after an image
is taken and before saving to disk.  Thus, although the observing
specialists would still have to contend with a slightly squashed
image, the observers trying to identify their field could actually get
a *more* accurate portrayal of the sky than in the old 1 X 1 binning
scheme, although there is still some smearing due to the resampling
process.  (1 X 1 binning before resampling: 375 X 241 pixels; 1 X 1
after resampling 319 X 241 pixels; 1.5 X 2 before resampling: 250 X
120 pixels; 1.5 X 2 after resampling: 160 X 120 pixels)

Another option allows us to switch automatically to 1 X 1 binning when
we enter subframe mode, thus guaranteeing no loss of resolution when
we are actually guiding on the object -- the only loss would be in the
original centering of the object.  For a low-resolution image after
resampling, the image scale is 0.68 arcsec/pixel.  I believe this
should still allow sufficient sampling for a decent centroid.  

After reviewing the options, I feel that we can get the greatest
savings in time (without waiting months for new software or hardware
to be installed) by simply making a change in procedure so that
full-frame images are routinely taken in low resolution mode and
re-sampled if they need to be saved to disk.  This will cut down
drastically on our time costs due to readout.  Later, we can try
incorporating the Software Bisque control program to save time
actually exposing dark images.  The new procedures will require a
little extra care on the part of the observing specialists (especially
at first, when we have to make sure we're using the right pixel scale
to calculate offsets), but I believe they can be codified enough to
become routine and easy.

Do any of the observers have comments on this new procedure?  Is 0.68
arcseconds per pixel acceptable for centroiding?  Should we
incorporate this into the routine?


APO APO APO APO APO  Apache Point Observatory 3.5m  APO APO APO
APO  This is message 372 in the apo35-general archive. You can find
APO  the archive on
APO  To join/leave the list, send mail to
APO  To post a message, mail it to