frame time ~ (waits + 2* fowler number)

and

exposure time ~ (waits + fowler number)

Due to the fowler sampling, the actual number of photons in the well is always larger than the apparent number returned by IRAC. Thus, a correction from too low on the linearity curve is used, and an erroeneous "linearized" result occurs.

To address this, an "IRAC Exposure Simulator" was written. It works by using a known incident flux (in DN/sec) and then going through the steps used by IRAC to do the fowler sampling. At each read the code computes the real number of "DN" in the well, and then applies the non-linearity curve to derive the "apparent" DN in the well. These apparent numbers are then added or subtracted as dictated by the fowler sampling scheme. A final, non-linear DN is then output. The non-linearity correction is then applied, based on the apparent DN, to produce a linearized DN. The linearity curve used was from the Rochester test data for a pixel near the center of an InSb array.

Since the "real" flux is known, it is possible to then compare the "real" expected number of DN returned by IRAC (using the exposure time) to the linearity-corrected DN. This gives a correction factor by which the linearized DN must be adjusted to get the true linear DN.

Figures 1 and 2 illustrate this problem for the shortest possible frame time (0.4 seconds) and the shortest non-HDR frame time (12 seconds). The 0.4 second frames are the most affected by this problem because here the difference between frametime and exposure time are maximized. For any given exposure, the linearity correction that is applied based on the observed DN is only halfway up the linearity curve from what should be applied. The error is thus roughly the difference in non-linearity between the frametime and the exposure time (times the incident flux). Since the arrays are increasingly non-linear at large DN, the error is largest when the arrays are near saturation. In the 0.4 second frame the maximum error is around 10%. The apparent full-well depth is only about 1/2 of that seen in the longer frames because the pixel is actually twice as full as the returned DN would indicate.

The 12 second frames are much less affected. Here the exposure time is 86% of the frame time. The difference in non-linearity over most of the curve is quite small.

Fig. 1 Percent difference between "real" DN in the well and perceived linearized DN based on the fowler-sampled, returned DN from IRAC vs. the full-well capacity. This is for the 0.4 sec frametime used by HDR.

Fig. 2 - Same figure, but for the 12-second full array frame time.

What to do about it:

Obviously, there is a considerable problem with the shortest IRAC frametimes. I propose a solution that works by applying a second correction to the post-LINEARIZE data. This new module would use a dataset calulculated via a simulator and the LINCAL solution.

Generating the error correction:

• A linearity dataset is processed by LINCAL to produce the linearity solution, as we currently have designed. In order to minimize problems with the disparity between frametime and exposure time, low fowler values should be used. Alternately, this may not be much of an issue with the input data because the flux rate from the transmission calibrators is so low that the correction will generally be quite low.
• The linearity model from LINCAL is used to generate a linearity correction lookup table. This can be done via an IRAC "exposure simulator" like the one described above. Since the corrections look like they are fairly linear, it may be enough to calculate just 10 points or so per pixel, and linearly interpolate for any other given DN. This will also generate a measure of the apparent saturation value for the pixel.
• There will be one such lookup table per array, per allowed combination of exposure time and fowler number.

To apply the correction:

• The input data is linearized by module LINEARIZE using the LINCAL solution.
• If the input data exceed the lower saturation value as determined by the new simulation module then the data gets flagged and processing stops.
• The linearized data is then corrected again by looking up, for each pixel, the appropriate correction curve in the LUT. The correction can be linearly interpolated where needed.
• The correction factor is then applied.