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? Russet. APO APO APO APO APO Apache Point Observatory 3.5m APO APO APO APO APO This is message 372 in the apo35-general archive. You can find APO the archive on http://www.astro.princeton.edu/APO/apo35-general/INDEX.html APO To join/leave the list, send mail to apo35-request@astro.princeton.edu APO To post a message, mail it to apo35-general@astro.princeton.edu APO APO APO APO APO APO APO APO APO APO APO APO APO APO APO APO APO