In order to test the functionality of the thread, I have compared it to the results of doing the same reduction by hand using IRAF. This is centered in the belief that the functionality of the thread should conform at the very least to what could be acheived by a careful hand reduction.

A suite of test data was selected from CTA testing at Ball and pre-screened to eliminate frames with significant ground-contamination by RFI. This same data is the pipeline-priming data that will be used for the pre-flight data calibration. These were:

Channel 1:

20001217_zero_pt_11.0.fits
20001217_zero_pt_11.12.fits
20001217_zero_pt_11.16.fits
20001217_zero_pt_11.20.fits
20001217_zero_pt_11.24.fits
20001217_zero_pt_11.28.fits
20001217_zero_pt_11.32.fits
20001217_zero_pt_11.36.fits
20001217_zero_pt_11.4.fits
20001217_zero_pt_11.40.fits
20001217_zero_pt_11.44.fits
20001217_zero_pt_11.48.fits
20001217_zero_pt_11.52.fits
20001217_zero_pt_11.56.fits
20001217_zero_pt_11.60.fits
20001217_zero_pt_11.64.fits
20001217_zero_pt_11.68.fits
20001217_zero_pt_11.72.fits
20001217_zero_pt_11.76.fits
20001217_zero_pt_11.8.fits
20001217_zero_pt_4.48.fits

Channel 4:

A.2000.354.21.05.41.04.20.0000.fits
A.2000.354.21.55.59.04.6E.0000.fits
A.2000.354.21.56.30.04.6F.0000.fits
A.2000.354.21.57.02.04.70.0000.fits
A.2000.354.21.57.33.04.71.0000.fits
A.2000.354.21.58.04.04.72.0000.fits
A.2000.354.21.58.35.04.73.0000.fits
A.2000.354.21.59.06.04.74.0000.fits
A.2000.354.21.59.37.04.75.0000.fits
A.2000.354.22.00.08.04.76.0000.fits
A.2000.354.22.00.39.04.77.0000.fits
A.2000.354.22.01.10.04.78.0000.fits
A.2000.354.22.01.41.04.79.0000.fits
A.2000.354.22.03.14.04.7C.0000.fits
A.2000.354.22.03.45.04.7D.0000.fits
A.2000.354.22.04.42.04.7F.0000.fits

Hand Reduction:

The data was reduced by hand using IRAF. The raw FITS images were converted to floating point format, The InSb data was flipped to the positive domain by multiplying by -1. The input data was then combined using IMCOMBINE, using both median combining and averaging using 3-sigma clipping. I have written my own destriper that works by assuming that for any given pixel the background in that pixel should be a linear interpolation of those in the pixels to the left and right (i.e. the adjacent readout channels). It then computes the needed offsets, assuming a constant offset for each readout channel. The destriper is iterated around 20 times until the offsets converge.

Pipeline:

Russ Laher processed the same data using the pipeline DARKCAL thread.

There are two primary differences. The first is is that DARKCAL produces results in e/sec. Thus, everything must be converted by the exptime/gain (which in this case is 26.8/13 = 2.062). Second, the darkcal module contains it's own destriper since the jailbar effect is removed separately in the science thread by the darkdrift module. I have used a separate destriper which appears to do about the same job as the one in DARKCAL. Barring these differences, the frames are the same. The table below gives statistics for the reduced dark frames, converted to the same data scale used by DARKCAL. The statistics are taken in small boxes to ensure that the large scale variations in the frames do not dominate the statistics. In particular, they have the same means and standard deviations. This indicates that the darks are being properly constructed.

Also in the above figure is the difference between the two frames. There is some structure visible. This is probably because the frames were destriped using two different algorithms. The small offsets between the frames are a result in the algorithmic differences in the destripers. In particular, my destriper holds the offset in readout channel 1 fixed and adjusts the other three to match. I believe DARKCAL does the more correct thing and adjusts all 4 channels to their common mean.