) are another bias-related artifact mainly affecting Cycle 7 and 7N data, which have now been mitigated by the BARSCORR step in calnica. Data from Cycle 11 and beyond are not likely to be affected. Bars appear as narrow stripes that cross the quadrants of an array, and occur identically in all 4 quadrants at the same rows/columns in each. They arise from electrical cross-talk in the detector lines when one camera reads out while the auto-flush pattern is executing in one or both parallel cameras. If an observation was made with all three cameras running in parallel using the same readout sequences, then there usually are no bars present in the data because there is no collision between camera readouts and parallel detector autoflush.
The bars run along the slow readout direction, i.e. along columns in
NIC1, and along rows in NIC2 and NIC3. Normally there is only one bar per quadrant, but occasionally there are more, always reflected in all 4 quadrants. Sometimes the bars will be in sync, appearing at the same place in successive readouts. Other times, they may appear in alternate readouts, or their positions may vary from readout to readout, sometimes appearing to march across the frame over the course of a MULTIACCUM sequence. They typically run the length of a quadrant (128 pixels), and are 3 pixels wide. The first pixel is lower than the mean, the second is at the mean level and the third is higher than the mean, giving the impression of an undersampled sinusoidal spike with an amplitude of up to ~10 DN peak-to-peak. The bars are almost always broken in at least one place, with a shift of 2-10 pixels in the narrow direction.
A flight software change was made prior to Cycle 11 to help mitigate
this problem by automatically turning off the autoflush sequence in unused parallel cameras. If no NICMOS parallel cameras were being used at the time of an observation, then there will be no bars in data taken after 1/1/2000 (Cycle 11 onwards). If a parallel camera is used with the same readout sequence, then as before, no bars will be present. However if a parallel camera is used with a different readout sequence then it still can induce bars in the other camera readouts, even in data taken after 1/1/2000. The software change has dramatically decreased the incidence of the bars in prime-only exposures and they are rarely seen now.
The bars are noiseless, localized changes in detector bias. The amplitude
is usually quite low, and for some observers they may have little impact on science data. However, it is possible to correct bars during post-processing of data obtained prior to Cycle 11, or newer data still affected by the electronic band problems. One approach is to flag pixels affected by bars in the data quality (DQ) array for each imset where the bars occur, e.g., by setting the DQ values to the bad data flag value 256. Subsequently, when calnica
carries out the CRIDCALC step, fitting the counts versus time to determine the count rates, it will ignore flagged pixels in a given imset, and the bars will therefore not perturb the fits. A memo describing this procedure is available as a link from the STScI NICMOS Data Anomalies Web page.
If a bar appears in the zeroth readout, it will be subtracted from all the
other readouts as part of the normal calibration process (ZOFFCORR), and appear as a negative bar pattern in all readouts of the processed *_ima.fits
file. This should have no significant effect on the calibrated final image (*_cal.fits
), however, since the bar just acts as an intercept offset to fit of counts versus time, which is irrelevant to CRIDCALC which only computes the slope (i.e. the count rate).