Mosaicking

This is fully automated. No longer do you have to measure painstakingly centroids and manually tile to form mosaics from the jittered frames. The jitter offsets are sufficiently small to permit shift of Cartesian co-ordinates to register. The offsets are derived from the automatic registration. No correction for the detector orientation is applied, since it degrades the quality of the data, despite the small rotation ($\sim$1 degree) normally involved. Allowance for this misalignment with the cardinal directions will be through the FITS world co-ordinate system. In the meantime should you need the rotation angle, pipe the output of KAPPA's fitslist function into grep.

      % fitslist <your_frame> | grep CROTA2

The flat-fielded frame can either be resampled to give sub-pixel registration, or to the nearest pixel. The latter is much faster and is adequate for most uses of UFTI, UIST, thermal IRCAM, and Michelle. It also has the advantage of not smoothing the data and introducing covariance into the data errors. For older undersampled IRCAM3 data (0.286 arcseconds per pixel) and for INGRID (0.235 arcseconds resampling has some merit.

The mosaicking uses the CCDPACK algorithm of its makemos command. Only zero-point shifts of intensity are applied to the resampled frames to create the mosaic. For most cases the comparison is of the sky levels as sky pixels dominate. This comparison is repeated for all pairs. makemos then finds the most mutually consistent set of additive corrections, weighting appropriately, to make the smoothest mosaic given the data. The first frame, which for the UFTI execs is the central (offset 0,0) frame, has no additive correction applied. The mosaic generation adjusts the zero-point of the jittered frames. Another way of looking at it is that mosaicking attempts to remove the sky variations. The additive corrections are normally quite small, like a few tenths of a count to a few counts. However, over longer integrations or in the thermal regime they can amount to a few score. A mosaic pixel value is the mean of all the adjusted contributing pixel values at that location. It is possible to select other statistics for the contributing pixels, such as the median, through the METHOD argument of the _MAKE_MOSAIC_ family of primitives.

There is no normalisation to counts per second in the mosaic. The mosaic's signal corresponds to that of the first frame, thus the exposure time of the mosaic is that of one individual frame. The recipes assume that you have used their corresponding `execs' or`sequences', and hence have not changed the exposure time during a jitter. The exposure time (header EXP_TIME [UFTI/UIST/Michelle], EXPOSED [IRIS2], EXPTIME [Classic Cam/INGRID/ISAAC/NACO/-NIRI] or DEXPTIME [IRCAM]) is propagated from the first frame to the mosaic. Where multiple frames combined to create a mosaic pixel the signal-to-noise ratio corresponds to the combined integration time. The integration time (keyword INT_TIME [UFTI], TOTALEXP [IRIS2], or EXPOSED [IRCAM]) is the number of coadds times the exposure time per coadd.

Depending on the recipe, the mosaic may be trimmed to the dimensions of a raw frame. Mosaicking removes virtually all the bad pixels for standard stars where the jitter offsets are small.

A mosaic forms for each cycle of the recipe, e.g. all four frames in a QUADRANT_JITTER. For multiple cycles, an integrated `grand' mosaic forms of improving signal-to-noise. To avoid the build up of bad pixels from cosmic rays, bad pixels are interpolated before the addition. This may result in some strange stripes in the top-left corner of UFTI frames where no interpolation can occur. Those pixels are bad in all frames and should be ignored. The exposure-time header for the integrating mosaic is the sum of the exposure times of the contributing mosaics. Again the signal is not divided by the exposure time.
[_MAKE_MOSAIC_ and invoked within several wrappers (all with the _MAKE_MOSAIC_ prefix) tied to various families of recipes]