IRAC utilized beamsplitters to redirect the incoming light for a given FOV through each of the two filters. As a result, although for a given FOV two filters such as for channel 1 and 3 viewed the same piece of sky, the detectors saw (and hence read out) mirror images of each other. An image transposition was applied to ensure that the two filters for each FOV were in the same orientation (Figure 5.9). Note that the images were not de-rotated, that is, each is now correct relative to the other filter for a given FOV, but all of the images still have the effects of spacecraft rotation, and are not in a north up, east left orientation.
(5.20)
Figure 5.9: Transposition of an IRAC channel 1 dark image by the imfliprot module.
Channels 1 and 2 were flipped about their vertical axis, which is illustrated by equation (5.20). The image flip of these two channels provided an array orientation with the E axis located to the left of N for all the channels. Since this image transposition was applied after skydark subtraction and flat-fielding, those calibration files were in the original (pre-flip/pre-transpose) orientation.
5.1.18 detect-radhit (cosmic ray detection)
Within this module, individual frames were analyzed for probable radiation hits (cosmic rays), and the results appeared as a flag in the imask file (see Section 7.1.1 for a definition of imask or BCD-specific bad pixel files). The flagging was computed by a median filtering technique. Input images were read in, and a median filter was applied. The difference between the input image and the median-filtered image was then computed. Pixels above a specified threshold (i.e., with more compact spatial distributions than possible for a true point source) were then flagged in a mask image (bit 9 of imask was set when a pixel was suspected to have been hit by a cosmic ray). See Section 7.1.1 for more information about the imask bits.
5.1.19 dntoflux (flux calibration)
IRAC flux calibration is tied to a system of celestial standards measured at regular intervals during each campaign. The IRAC IST provided the calibration server with calibration files based upon these measurements. Because the flux calibration was determined with stellar point sources, the calibration for extended sources is somewhat different. For details of the photometric calibration and correction factors, see Chapter 4. The IRAC data were calibrated in units of MJy/sr in this module. This was accomplished by multiplying the data image by a conversion factor provided by the calibration server. This conversion factor was written to the data header as:
/ PHOTOMETRY
BUNIT = 'MJy/sr ' / Units of image data
FLUXCONV = 0.2008 / Flux Conv. factor (MJy/sr per DN/sec)
GAIN = 3.8 / e/DN conversion.
5.1.20 Pointing Transfer (calculation of pointing information)
The Pointing Transfer pipeline was a separate script from the actual data reduction pipeline script, designed to insert raw-pointing and distortion information into the FITS headers of BCDs. Like the reduction pipeline, it executed on a per-BCD basis. See Section 4.12 for more pointing related information. Pointing data was acquired by the spacecraft star tracker at a rate of 2 Hz, transferred to the boresight onboard, and down-linked every 12 hours as a Boresight Pointing History File (BPHF). The BPHF was received via a separate telemetry stream from the science data. The first step in pointing transfer was to acquire the portion of the BPHF which spanned the integration time of the BCD (getPH module). The 2 Hz sampled data were then transferred to the specific channel-dependent science FOV using a set of Euler transformations handled by the boresighttran module. The Euler angles relating the boresight and the FOV positions were determined in-flight and were stored in a configuration file.
The pointing samples were then averaged and combined by the ANGLEAVG module to compute the raw pointing for the BCD: CRVAL1 (RA), CRVAL2 (Dec), and PA (position angle). These, along with uncertainties and reference pixel coordinates (CRPIX1, CRPIX2), were inserted as keywords into the FITS header of the BCD. The module also computed a CD matrix and transferred distortion coefficients (represented in the pixel coordinate frame) from a calibration file to the FITS header. The default projection type for the celestial reference system (CTYPE keyword) was “TAN–SIP.” This was a tangent (TAN) projection modified to make use of the Spitzer Imaging (distortion) Polynomials (SIP) in coordinate mappings (see Section 2.2.4 for more information on Spitzer image distortion).
The Final Product Generator (FPG) was executed at the end of the BCD pipeline. This reformatted the FITS header and added additional keywords, which were most useful to the user, from the database. Examples of BCD headers (also containing pointing and distortion information) are given in Appendix E.
5.1.21 predictsat (HDR saturation processing)
predictsat was used to process data taken in the High Dynamic Range (HDR) mode by identifying saturated pixels using the information obtained from the shorter exposure time frames. Specifically, if the shorter frame was frame 1 and the longer frame was frame 2, and they have Fowler numbers F, wait periods W, pixel values DN, and saturation values of DNsat, then if
(5.21)
for any pixel, then that pixel was masked as saturated in the longer frame 2. Optionally, surrounding pixels might also be masked. This information was used in the post-BCD pipeline by the mosaicker when coadding frames to reject saturated pixels before applying any other outlier rejection. High dynamic range data were received as separate DCEs by IRAC. No co-addition was done of these frames at the BCD level, but they were received by the user as separate BCDs. See Section 7.2.1 for more information on saturation in IRAC data.
5.1.22 latimflag (residual image flagging)
The IRAC pipeline detected and flagged residual images left from imaging bright objects. A model of the charge decay was used to build a time history of the DCEs and set a mask bit (bit 10 in imask; see Section 7.1.1) to indicate that a given pixel in the DCE was contaminated by a residual. The algorithm worked in the following way: Starting with the first image in each observation or AOR, latimflag computed what is called a “latent-trap” image at the end of its exposure. This specified the amount of trapped charge in every pixel. The charge-trap decayed and appeared as a residual in subsequent images. The latent-trap image was effectively an image of the number of filled traps, which we label NF(t)i. The subscript i refers to the “trap-species” or type of latent trap distinguished by a characteristic decay time and trap filling efficiency. The latent-trap image was propagated forward in time, and updated with each consecutive image in the sequence. The images with pixels sustaining and exceeding a threshold above the background noise from image to image within the decay time were flagged in the imask (bit 10). Section 7.2.8 has more information on residual or persistent images.
