In this section we discuss the software and observing procedures needed for the following:

1. How to evaluate the observations as they are obtained at the telescope, including how to display Mosaic images, how to evaluate the telescope focus, and edit and examine the image headers. We also discuss how to log the observations.
2. How to read and write the data from/to tape.
3. Calibration observations that should be obtained at the telescope
4. How to reduce the images.

Observers familiar with CCD cameras and the IRAF reduction and analysis software for the most part will find the processing of Mosaic images to be similar to cameras of more modest size. At the same time, there are a number of important differences that we touch upon briefly here. To start with, Mosaic images are recorded in a special multi-extension FITS format (MEF). In brief, the Mosaic CCDs are saved as individual images grouped together as separate entities in a larger FITS file; only at the end of the reduction are the CCDs assembled as a single large astronomical image. Because of this special format, most IRAF routines will not work directly on the full Mosaic files. To provide for processing of the special Mosaic format, as well as reduction and analysis tasks specific to Mosaic, we have developed a set of IRAF routines available under the MSCRED package. Almost all of the software tasks that we discuss below presume that you will be working within this environment.

A key factor that drives both the data taking and reduction of Mosaic images is the presumption that the final astronomical exposure will be built from a number of Mosaic images obtained by dithering the telescope. This places strong demands on the quality of the data reduction to ensure the uniformity of the photometric response of the reduced image.

An excellent summary of the Mosaic reduction routines is provided in the two guides written by Frank Valdes: Mosaic Data Reduction System (http://iraf.noao.edu/projects/ccdmosaic/Reductions) and. Guide to the NOAO Mosaic Data Handling System (http://iraf.noao.edu/scripts/irafhelp?mscguide). This last is available in the mscred by the command "help mscguide". We encourage Mosaic users to read through these documents before attempting to reduce their data. The guides also provide a thorough description of all MSCRED tasks that may be valuable during the night's observing.

The NOAO Mosaic data format produced by the Data Capture Agent (DCA) is a multi-extension FITS (MEF) file. The file contains nine FITS header and data units (HDU). The first HDU, called the primary or global header unit, contains only header information which is common to all the CCD images. The remaining eight HDUs, called extensions, contain the images from the eight CCDs.

The fact that the image data is stored as FITS format images is not particularly significant. A single FITS format image file may be treated in the same way as any other IRAF image format. The significant feature is the multi-image nature of the data format. This means that commands that operate on images need to have the image or images within the file specified. Only commands specifically intended to operate on MEF files, such as those in the MSCRED package, can be used by simply specifying the file name. Commands that operate on files rather than images, such as copying a file, may be used on MEF files. In general, it is safest to use only MSCRED commands on MEF files. IRAF V2.11 is required to run MSCRED.

The basic syntax for specifying an image in a MEF file to an IRAF task is:

filename[extension]

where "filename" is the name of the file. The ".fits" extension does not need to be used. The "extension" is the name of the image. For the NOAO Mosaic data the eight CCD images have the names "im1" through "im8" (but the simple "1" through "8" works,too). The extension position in the file (where the first extension is 1) may also be used. To access the global header (for listing or editing) the extension number is 0; i.e. filename[0].

There is currently no wildcard notation for specifying a set of extensions. So to apply an arbitrary IRAF command that takes a list of images you must either prepare an @list (or type the list explicitly) or use the special MSCCMD command. The task MSCCMD takes an IRAF command with the image list parameter replaced by the special string "$input". The input list of Mosaic files will then be expanded to a list of image extensions. Section 4.3 illustrates the use of MSCCMD with the HSELECT task.

During observing, a small set of IRAF commands are commonly used to examine the data. This section describes these common commands. While this section is oriented to examining the data at the telescope during the course of observing, the tools described here would also be used when reducing data at a later time.

The two commands DISPLAY and MSCDISPLAY are used to display the images in XIMTOOL. The DISPLAY task is used to display individual images - in this context, the individual CCDs in a Mosaic exposure. There are many display options which are discussed in the help page. The only special factor in using this task with the Mosaic data is that you must specify which image to display using the image extension syntax discussed previously. As an example, to display the central portion of extension im3 (i.e., CCD#3) in the first frame and the whole image in the second frame:

• cl> display obj123[3] 1 fill-
• cl> display obj123[3] 2 fill+

The MSCDISPLAY task is based on DISPLAY with a number of specialized enhancements for displaying Mosaic data. It displays the entire Mosaic observation in a single frame by "filling" each image in a tiled region of the frame buffer. The default filling (defined by the order parameter) subsamples the image by uniform integer steps to fit the tile and then replicates pixels to scale to the full tile size. The resolution is set by the frame buffer size defined by the "stdimage" variable. An example command is

1. mscdisplay obj123 1

Many of the parameters in MSCDISPLAY are the same as DISPLAY and there are also a few that are specific to the task of displaying a mosaic of CCD images. The mapping of the pixel values to gray levels includes the same automatic or range scaling algorithms as in DISPLAY. This is done for each image in the mosaic separately. The new parameter "zcombine" then selects whether to display each image with it's own display range ("none") or to combine the display ranges into a single display range based on the minimum and maximum values ("minmax"), the average of the minimum and maximum values ("average"), or the median of the minimum and maximum values. The independent scaling may be most appropriate for raw data while the "minmax" scaling is recommend for processed data. Another new optional answer here is "auto", which is the default, will try to use the best option, given the status of the data.

There is a new parameter set, too, called "mimpars", which controls the on-the-fly processing. You can select overscan correction, flat-field correction, both, or none.

MSCDISPLAY offers a special mode of display not previously available. If invoked before the readout of the Mosaic array is complete, MSCDISPLAY will begin painting the XIMTOOL screen with as much data as are available at that moment. When automatic gray level scaling is used it will compute the scaling based on the amount of data present when it starts. It will then keep the same scaling for the number of display and sleep cycles given by the "niterate" parameter after which it will compute a new display scaling and reload all the currently recorded data. Thus a small value for the niterate parameter will update the scaling frequently and a large value will update more infrequently. The trade-off is that calculating the scaling takes a significant amount of time and causes the whole display to be reloaded, while using only the first scaling based on just a little bit of data may result in poor scaling values. Generally, we recommend infrequent updates because of the very lengthy time required to display an entire image. [This use of MSCDISPLAY is only sensible if automatic displaying is disabled from the DCA GUI.]

The MSCDISPLAY task is automatically started when a new image is reading out. This default behavior is controlled by the IRAF Data Capture Agent (DCA). Whether to display or not is controlled by the DCA user interface, the DCA GUI (see Sec 4.9).

Once you have displayed the Mosaic exposure, you will need a few more commands specific to Mosaic to interact with the display to do such things as looking at exposure levels, checking the focus, and so on. Just as we have written MSCDISPLAY as a special version of DISPLAY, we provide the MSCEXAMINE routine as an analog of the standard IMEXAMINE to allow for interactive examination of Mosaic images. MSCEXAMINE is essentially the same as the standard IMEXAMINE task except that it translates the cursor position in a tiled mosaic display into the image coordinates of the appropriate extension image. Line and column plots also piece together the extensions at the particular line or column of the mosaic display. To enter the task after displaying an image the command is:

cl> mscexam

As with IMEXAMINE, one may specify the Mosaic MEF filename to be examined and if it is not currently display it will be displayed using the current parameters of MSCDISPLAY.

For evaluating focus sequence exposures you may use MSCEXAMINE or MSCFOCUS. With the former you measure individual widths and keep track of the focus values yourself. With MSCFOCUS, which is a Mosaic version of KPNOFOCUS, you mark the top exposure (on any CCD) for each star and the task measures all the exposures in the sequence and estimates the best focus value using information recorded in the data file. To run MSCFOCUS on a displayed exposure just give the command (with a file name it will display the exposure if needed):

1. mscfocus

To measure pixel statistics you may use MSCEXAMINE or MSCSTAT, a Mosaic version of IMSTAT. MSCSTAT runs IMSTAT or each of the selected extensions in a list of Mosaic files. To restrict the measurement to a region you use image sections which apply to all of the selected extensions. For example, to measure statistics at the center of a set of observations the command would be something like:

cl> mscstat *.fits[900:1200,2000:2300]

There was some discussion earlier concerning use of generic image tasks with the NOAO Mosaic data. The tasks IMHEADER and HSELECT fall into this category. The two important points to keep in mind are that you must specify either an extension name or the extension position and that the headers of an extension are the combination of the global header and the extension headers.

Often one does not need to list all the headers for all the extensions. The image title and many keywords of interest are common to all the extensions. Thus one of the following commands will be sufficient to get header information about an exposure or set of exposures:

cl> imhead obj*[1] l- # Title listing

cl> imhead obj123[1] l+ |page # Paged long listing

cl> hselect obj*[1] $I,filter,exptime,obstime yes

If you need to list header information from all the extensions then you need to take the additional step of creating an @file. For example to get the default read noise and gain values for each CCD:

1. imextensions obj123 > list123

cl> hselect @list123 $I,rdnoise,gain yes

Rather than create an @list you can use MSCCMD:

cl> msccmd "hselect $input $I,rdnoise,gain yes"

The CCDLIST task in the MSCRED package is specialized for the Mosaic data. It provides a compact description of the name, title, pixel type, filter, amplifier, and processing flags. By default, it lists all the extensions, but the "extname" parameter may be used to select a particular extension. Because all extensions should generally be at the same state of reduction it may be desirable to list only the first extension. Like most of the CCD reduction tasks you can also select only a certain type of exposure for listing. Examples of the two modes are:

• # Summary for all exposures
• cl> ccdlist *.fits extname=im1
• # Summary for all object exposures
• cl> ccdlist *.fits extname=im1 ccdtype=object
• # List of all extensions.
• cl> ccdlist obj123

Recording your data to tape consists of allocating the tape drive and using MSCWFITS to write the Mosaic format files to a FITS format tape. With the CCD Mosaic, every exposure produces 135 Mbytes of raw data. After a good night, an observer may have 100 images, or 13.5 Gbytes of data. Writing this volume of bits consumes a great deal of time and tape, comparable to more than 5 hours and 3 Exabyte 8505 tapes (possibly only 2 tapes if compression is used). We have considered the market for a new direction in tape drives and have decided to use the digital linear tape technology. A DLT-7000 tape drive is the preferred tape system, and a drive is available downtown for those needing to transfer tapes to other technologies. The DLT-7000 can write tapes about 3 times faster than the Exabyte 8505 and the tape cartridge holds 7 times the data volume. While tape cartridges cost about $100, they can hold roughly 3 nights of data. As an alternative, we also offer a Exabyte 8505-compatible (actually, Eliant 820) drive and a DDS3 (DAT) drive. The DDS3 format holds 12 Gbytes in compact format.MSCWFITS takes about 50seconds to write a raw image to the DLT and about 90seconds to a DDS3 tape.

Please note that we are experiencing compatability problems with DLT7000 and DLT4000 drives. Tape writing
on our DLT7000 in a low density mode is slow, and may NOT be readable on DLT4000 drives. Please bring DLT type IV tapes, that are labeled 35 Gby capacity.

The reduction of Mosaic camera images at first glance is just like that of any other CCD camera, ignoring the immense amount of data contained in a single Mosaic image. As is standard for other cameras, reduction requires overscan correction, followed by zero, dark, and flat field corrections. In detail, however, full reduction of Mosaic data requires a number of steps not normally encountered in the routine reduction of other CCD camera images. The driving factor in Mosaic reduction is the expectation that the observer will not simply obtain a single Mosaic exposure of an astronomical field, but may want to construct a deep integration from several Mosaic images spatially offset or "dithered" from each other to cover both the gaps between the individual CCDs and any defects. Stacking dithered Mosaic images places high demands on the uniformity of the initial data reduction as well as requiring several additional steps once the basic reduction of the individual exposures is complete.

The Mosaic camera also has a spatially variable pixel scale that has important implications for ensuring a uniform photometric zeropoint in the reduced images.

At this writing we are still refining the reduction software and learning about the camera, especially with regard to the new SITe CCDs. We share what we found here with the caveat that this is still a work in progress.

Good data reduction begins with obtaining good calibration data at the telescope. Dark frames may be required, in addition to the usual zero frames. It is safe practice to obtain darks with exposures similar to your science images. Dome flats provide a fair basic flattening of the frames to 1% or so, but night sky flats or illumination corrections likely are required to produce images that can be stacked without introducing obvious artifacts. Using night sky flats, we expect to flatten the images to 0.1%; twilight flats do not appear do work quite so well as dark sky flats due to regions of variable thinning that cause slightly wavelength-dependent features.

The default Mosaic dither pattern is a sequence of 5 exposures designed to insure at least 80% coverage for all portions of an astronomical image, given the gaps between the CCDS

Lastly, good astrometry is required to register and stack the Mosaic images. We have derived solution for most filters, but the scale varies slightly with color, so you may want to image an astrometric field if you are using weird filters. Our experience indicates that the array is geometrically very stable.

Almost all of the basic image reduction is done under the IRAF MSCRED package. Before you get started, you should be aware that the Mosaic multi-extension FITS data format means that you will have to be careful to stick to the routines in MSCRED that can handle this format. In many cases, useful routines from CCDRED have been rewritten with the same name to be available in the MSCRED package. IRAF routines in other packages can be used on one CCD at a time either in scripts or the command line, but will not work directly on an entire mosaic image at once. At present we are still working on this issue, but there is an MSCCMD routine that acts as an interpreter, allowing you to use traditional IRAF routines on the Mosaic files.

One of the first things that you're likely to do is to stack sequences of zero, dark, and flat exposures to produce "superimages" to feed into CCDPROC. On the assumption that the darks and zeros are all the same, using ZEROCOMBINE and DARKCOMBINE presents no complications. On the other hand, you are likely to want to scale the flats by their modes, and this at present can be tricky. Because of the importance of image defects, modes and other statistics can be biased by bad values. To estimate modes in our reductions to date, for example, we wrote a script that estimated the mode in two passes. The first pass restricted the range of allowable pixel intensities to "plausible" values to exclude "wild" numbers; the second pass used the mode from the first pass to limit the range of allowable values to between zero and twice the initial mode.

With the first version of the software, we had to write a stand-alone FORTRAN program that averaged the modes from the 8 CCDs with sigma rejection (and that ignored CCD4, as well) and then feed the scale factors to the combining task. These improved algorithms for mode estimations and combining to a single scaling value for each exposure eventually will be part of the standard MSCRED version. [The need for these routines is much reduced with the science-grade CCDs.]

With good zero, dark, and flat field images in hand, the basic image reduction is done with the MSCRED version of CCDPROC. If your data consists of a dither-sequence that you intend to stack later, we recommend that you do not interpolate over bad pixels; this is more logically done downstream, as we discuss later. One of the last basic steps that you may attempt is to build a sky flat or illumination correction from a portion of your reduced data. You could try going directly to a sky flat without any prior reduction with a dome flat (or any other serviceable flat), but working with roughly-flattened data first allows for more accurate estimation of the mode in the presence of faint astronomical sources, and further allows for better detection and rejection of biased regions of the images. At the same time, flat field reductions will produce wild values in the few defect regions, so extra care is required when estimating modes or other statistics from flattened data.

A key assumption in traditional reduction of CCD images is that the pixel scale is uniform and that a properly reduced blank sky image will have a uniform and flat appearance. Unfortunately, this is not correct when the pixel scale varies over the field. In the case of Mosaic, the pixel scale decreases approximately quadratically from the field center, with the pixels in the field corners being 6% smaller in the radial direction, and 8% smaller in area, given the complete astrometric description of the field. Pixels in field corners thus would properly report only 92% of the sky level seen in the field center, even with uniform sensitivity. At the same time the same number of total photons would be detected from a star regardless of how many pixels the PSF would be distributed over. Forcing the sky to be uniform over the image would have the deleterious effect of causing the photometric zeropoint to vary from center to field corners by 8%. Note that this effect is different from vignetting, where the flux actually delivered to the image margins is less than that at the center, an effect that is corrected by the flat field.

In practice, the photometric effect of the variable pixel scale can be ignored provided that the reduced images will be part of a dither-sequence to be stacked later on. As discussed below, prior to stacking the images, they first must be re-gridded to a tangent-plane projection, which has pixels of essentially constant angular scale. This is done with the MSCIMAGE task, which re-grids the pixels and has a "flux conservation" option that can scale the pixels photometrically by the associated area change. If this function is disabled, then "improperly" flattened images will have a uniform zero point restored with this option turned off. In short, the flat field already adjusted (if inappropriately) for the different pixel sizes, so MSCIMAGE would then do no further adjustment. Stars would be too bright in the corners of the flattened images, but after re-gridding, their total fluxes would be seen to be scaled down to the appropriate values.

If the Mosaic images are to be analyzed individually, however, as might be done for standard star fields, then after the flat field reductions are complete, the differential scale effects must be restored. This can be done with the MSCRED task PIXAREA without actually re-gridding the image with MSCIMAGE (which can also be done with images not part of a dither-set). The correction process is simple; the scale at any point in the Mosaic field is already known from the astrometry, so one could just calculate and multiply by a correction surface. The final image would appear to have a variable sky level, but would be photometrically uniform. NOTE PIXAREA allows you to multiply or divide by the correction, just be sure that in your final frames pixels at the corners of the Mosaic have less sky than those in the center! We are contemplating allowing an option to subtract a sky level prior to the correction and perhaps adding it back afterwards. In the later case, the sky would be cosmetically but not photometrically uniform, and could cause confusion if the frame is ultimately re-gridded to a constant scale. We also note that performing surface photometry on Mosaic images with their native sampling can cause biased results unless care is taken to track the changes in the pixel scale.

In many ways the real work of reducing Mosaic data comes when preparing to stack the images to make a final deep image free from gaps and artifacts. Not only is there a premium on having well-flattened data to begin with, but one must also understand the relative photometric and sky level variations among the images in a dither-set. At any point in the final stacked image, different frames will be making differing contributions. Any differences in scaling will produce noticeable artifacts in the final sky background or zeropoint. In practice we have found that the stacking works beautifully with data obtained under clear conditions and with no bright stars near the fields; on the other hand we have found that simple reduction strategies produce very poorly stacked images if the shape of the sky over the field or scattered light contributions varied over the course of a dither-sequence (or over the course of the night used to define the sky flat).

The first step in stacking the reduced Mosaic images is to register them to a common coordinate system. This is done with the MSCZERO and MSCREGISTER programs. The MSCZERO routine can be used to set the coordinate system origin for any given image, given a known position or even ad hoc position for any star. There are three important uses of MSCZERO. The first is to set the coordinate zero point fairly accurately and then read back coordinates. With a reference star one can obtain useful "real-time" coordinates at the telescope. We did this to check asteroid detections against known asteroid positions. The second use of MSCZERO is to identify a list of stars in one "fiducial" image that will be located in the other images in the dither-set. A third use is to reset the origins of the other images in the dither-set to match the fiducial image in the event that the coordinate origin is lost or corrupted (as happened a few times in our reductions). The MSCZERO routine uses the known astrometric description of the Mosaic field so that the location of any star identified can be used to set a global origin. In passing, we note that the quality of the astrometric solution is excellent; stars can be located to a fraction of a pixel (0.26"at the 4-m) in all portions of the field.

Registering the images in a dither-set to the fiducial image can in principle be done entirely with a single star using MSCZERO, but MSCREGISTER offers more options and has the ability to use a number of stars to find the best registration. At this time we are still experimenting with MSCREGISTER, but have had the best luck with identifying about 10 stars or so in the fiducial image and asking MSCREGISTER to locate them in the other dither-set images.

MSCREGISTER uses the astrometric solution and recorded relative telescope offsets to locate the registration stars in a given image (it can also be assisted by running the images through MSCZERO if this assumption fails for some reason). Once a given star is located, it is cross-correlated with the same star in the fiducial image to calculate a positional offset. You have the option to review the quality of the match to decide if it is acceptable. The final offset is the average of the individual offsets, with a check for outliers. At this time, we think this interactive approach gives the best confidence that the correct offsets are being used. In the future, we hope to automate rejection of poor cross-correlation matches. MSCREGISTER presently has the option to find an offset by cross-correlating random regions of the images, but at present this often leads to computing offsets from regions with no bright objects or containing defects.

The penultimate step in stacking Mosaic images is to re-grid them into common tangent-plane projections using MSCIMAGE. The use of a common projection aligned to the centers of the pixels is done so that the shift and stack step does not require any further re-sampling. Up to this point the individual CCD images are each stored in their own partition in the multi-extensions FITS files. MSCIMAGE "pastes" the individual CCDs into a large single FITS image, accounting for their accurate relative positions and rotations, given the astrometric description of the field. MSCIMAGE further re-grids the pixels into a tangent-plane projection, which yields pixels of essentially constant angular size over the extent of the Mosaic field. This is also the best point to fold in knowledge of the bad pixel map. The bad pixel map itself can be re-gridded by MSCIMAGE, giving the final routine, MSCSTACK, complete knowledge of where the bad pixels are. If the bad pixels had been replaced prior to this point, and had not been flagged in the Mosaic images themselves, their locations would have been unavailable in the final stacking.

Re-gridding the Mosaic images requires a method to calculate new pixels interpolated from the original ones. One can select from any number of the standard IRAF interpolation routines; however, given the immense quantity of the data involved, we have always selected bilinear interpolation for speed considerations. Unfortunately, bilinear interpolation smooths the noise slightly, and as the new pixel grid beats against the original grid, the noise in the tangent-plane image shows bands of coherent noise structure. This will be reduced somewhat in the final stacked image, given the spatial de-coherence of the images in the dither-set. At this time we are experimenting with improving the speed-performance of higher-order interpolation methods to avoid smoothing of the data. Lastly, as noted above, MSCIMAGE has the option to correct the flux in the re-gridded pixels for the variable pixel scale. Use of this option should only be invoked when this information is preserved in the flattened images to begin with.

The final step is to combine the re-projected dither-set images using MSCSTACK. This is the stage where careful attention must be paid to variations in zero point and sky level among the images. Even on photometric nights, the sky level is likely to change over the course of the dither-sequence. We have used the image modes to track the sky level, but again, one must be careful that the mode is not biased by bad pixels and defects. In detail, for our reductions to date, we calculated the average sky level for a dither-sequence and then gave MSCSTACK a file specifying additive offsets for each image about this average. At this stage you should also account for any photometric variations among the images. MSCSTACK can also accept a file of multiplicative offsets. These might be based on an atmospheric extinction curve on photometric nights, or determined by comparing stars among the dither-set; we are exploring the use of MSCREGISTER to measure photometric as well as spatial offsets among stars. At this writing, we are also upgrading MSCSTACK to include options for calculating both forms of scaling, so specifying the scale factors in an external file may be no longer required.

The final stacking of the image by MSCSTACK can be done with any of the standard combining algorithms within the IRAF combine tasks. We have preferred to use an average value with sigma rejection; we also make complete use of the bad pixel map at this stage to eliminate known defects. One might be tempted to use a simple median, but in the limiting case of a large number of images this will still only yield ~80% of the signal-to-noise available from an average. On the presumption that most vectors of pixels to be stacked will be valid, an average (with occasional rejection) will give the best answer.

Going all the way through to this stage has produced final stacked images of variable quality, depending on the conditions of the observation. In non-photometric conditions the sky may not be flat; further, scattered light from nearby objects may affect the sky over large areas - unfortunately, the pattern of scattered light varies as the telescope is dithered. A further complication is that computation of an average mode for an image may be affected by scattered light that affects only a small portion of the Mosaic field. At this time we are still working on a solution for stacking images of this type; the solution is likely to require fitting and subtracting a sky surface to the individual Mosaic images prior to feeding them to MSCSTACK. When conditions are favorable, however, we have produced beautifully flat stacked images free from defects, showing the full scientific potential of Mosaic camera, and providing a suitable reward for our hard work.