Why: When an observer specifies the use of HDR mode in the IRAC AOT for a full-frame observation, he or she will receive extra exposures taken with shorter exposure times than the specified full-frame exposure time. The specific reason is to increase the dynamic range of the resulting data. Objects (e.g. bright stars), which would saturate in the specified exposure time can have their data later filled in using the shorter exposures.

However, rejection of the saturated data in the long frames is more complex than it sounds. Because the IRAC arrays use Fowler sampling, once a given pixel is saturated the DN in that pixel actually {\it decrease} as the exposure time is increased. This is because the signal reads are saturated, yet the pedestal reads are not. Continued exposure will eventually drive the DN all the way back to zero. Because of this multi-valuedness, a simple threshold scheme for testing for saturation is not always reliable. Since the saturated values would appear good, when the data is coadded, the result will be wrong. Even worse, in cases where HDR mode creates three frames and two are saturated, outlier rejection will actually guarantee the wrong result because the shortest frame time is in the minority.

However, an ensemble of HDR data is taken without slewing - that is, all the pixels correspond to the same place on the sky and hence each other. By looking at the shorter frames, it is possible to tell which pixels in the longer frames must be saturated.

How: For a simple example: imagine an HDR data set consisting of two frames, one short (1) and another long (2). One would read in these two frames, including the Fowler number (AFOWLNUM) and waitperiod (AWAITPER) header keywords. Call these F(1),W(1) and F(2),W(2). A given pixel has counts DN(1) in the short frame and DN(2) in the long frame, and it is known that the pixel saturates at DN(sat). The latter could either be a global value given by a namelist parameter, or could be specific to that pixel and could be acquired from the LINCAL solution.

The exposure time is proportional to (F+W). This relates time to the measured DN.

The frame time is proportional to (2*F+W). This relates time to the number of "real" DN in the well. The "DN rate" is then DN/(F+W). Thus, if

DN(1) (2*F(2)+W(2))
-------------------- > DN(sat)
     F(1)+W(1)

Some additional tweaks that would be nice:

• It would be useful if there were an ability to adjust DN(sat). For example, one could test to see if we are within some settable percentage of DN(sat), rather than using the actual value. This will allow one to be a little more conservative in terms of saturation rejection.
• In some cases there may be more than two frames. One would time order them and start with the shortest frame.
• DN(sat) should be be able to be read in from a LINCAL solution to set it pixel-by-pixel, or we should able to override this via a namelist value so that the whole array has a fixed saturation value. This may prove more reliable (or at least well-behaved) than using the LINCAL solution.
• A "growth" parameter could be specified, so that in addition to masking the offending pixel it also masks a box around it. For example, if "growth=1" it could mask the 3x3 box centered on the offending pixel. This would be useful is turns out that there is any additional contamination of surrounding pixels (perhaps by scattering) due to the saturated pixel. It might also help suppress "seams" where a coadded result jumps from one solution to the next.