Muxbleed Correction



Note: the following information is intended for the IRAC instrument team only. If you are not such a person, you should not be reading this. No guarantees are made as to the applicability of this information to the real IRAC.

Muxbleed is an effect observed in the IRAC InSb arrays (channels 1 & 2) wherein a bright star trails in the fast read direction (horizontal or x) for a large number of consecutive readouts. Since there are 4 readout channels, the trail appears every 4 pixels. The duration of this trailing is quite long, and as a result can wrap around to the next line. It is not known what causes the muxbleed. It has been seen in other arrays by SBRC. It is believed to be a result of operating the output driver FETs (there's one per readout channel) at such a low temperature. Large signals drive these FETs into full charge depeletion and as a result they are operating outside their normal tolerances. Due to the low temperatures the normal charge flow mechanisms are frozen out and the FETs wind up with a long recovery time. This seems reasonable in that the muxbleed is worse at lower temperatures and higher total fluxes. As can be seen on the SAO test page raising the temperature helped the muxbleed a lot but increased the number of hot pixels by an order of magnitude.



Please see the muxlbleed descriptions for Cold Cycle 5 and Cold Cycle 4 by Joe Hora at SAO. Mail me if you need the password. Tests were run at GSFC to characterize the muxbleed. Based on those tests we believe that the nature of the muxbleed appears to be the same everywhere on the array. While the shape of the curve is the same, it scales as a function of the intensity of the bleeding pixel and the scaling is different for the pixels closest to the bleeding pixel. Muxbleed only occurs in the fast read direction. It does not correlate from one pixel to the next, i.e. a pixel does not bleed it's value plus the bleed from another pixel. This is the key to how it is corrected.

To correct the muxbleed, one starts at the first pixel read out, call it i (which is the first pixel in the FITS file), which has an intensity a(i). One then advances to the next pixel in that readout channel, i+4k (where k is an index starting at 1), which has an intensity a(i+4k). One looks up the appropriate value in the look-up table, LUT(k), and scales it by a function of the intensity of the bleeding pixel, f(a(i)). The new value of intensity of pixel i+4k is then

a'(i+4k) = a(i+4k) - LUT(k)/f(a(i))

k is then incremented for as long as you want to correct the muxbleed from pixel i. In this case we will use a LUT with 128 positions, so k is incremented up to 128. That is enough to do 2 full lines in an IRAC image. The new value of a'(i+4k) is then put back in the image to replace a(i+4k). After the muxbleed from pixel i is corrected, you move to the next pixel by incrementing i.

The equation for scaling the lookup table is a polynomial:

f(x)= A(E/x) + B(E/x)^2 + C + D(E/x)^3

where the coefficients are:
CH. 1 k<5 k>5
A 1.987 4.802
B -0.331 -2.961
C -0.717 -2.055
D 0.101 1.232
E 36071 36071


Channel 2 will be supplied later. There should be 4 LUTs; 1 for each readout channel in an IRAC array. For now they will all be set to the same value, but the capability should be there for them to be different in the future. Here is the Channel 1 LUT. The above will crash if the intensity is negative. In the actual code below I don't correct any pixel whose value is below a given threshold (1 ADU in this case). The bleed from such a pixel is so small it could never be seen anyway. This should probably be a namelist parameter.

Fig. 2 - Example of the muxbleed correction algorithm on a very bright star.
The left hand images are before running the algorithm, and the right
hand images are after. The bottom images are full frame, the top images
are close-ups of the star.


Figure 2 shows the results of running the algorithm described above on a badly bleeding artificial "star". The image is cosmetically vastly improved. The intensity of the bleeding is now similar to that of the diffraction spikes. Since we are not correcting those, I believe this constitutes an "adequate" level of correction. Note that the output image is not perfect, however, particularly at the pixel closest to the star. For this reason when the muxlbleed corrector runs it should produce a mask file. This mask file will consist of a flag (i.e. one bit) which will be set when the muxbleed correction exceeds a pre-determined fraction (to be set in a namelist) of the local noise value. Thus the mask file will contain a map of pixels which have had a "noticeably large" muxbleed correction, and which therefore might be suspect.

This is the code that performed the above correction. It was written in the Igor data-handling language on the Mac. It's very similar to FORTRAN or C, and should be easy to understand in terms of algorithmic logic. One thing to note is that a "WAVE" is an array - in fact, pay no attention to variable declarations, they are hard to understand in this data language. Also, I probably did not handle the wrapping exactly right, and I didn't use the whole look-up table.

Images with muxbleed can be picked up from the SAO test pages for Cold Cycle 5 and Cold Cycle 4. In particular, p1_12_1d.fits was used for the test in Fig.2.

Jason Surace (7/21/00)