Linearity

program names, file names
variable names
prompts, commands, program code

Contents:

Overview

"Doing linearity" is one of the first things that needs to happen after an observing run. This process creates some data which allows us (via linez) to correct the data images for nonlinear response in the detector. Nonlinear response refers to the detector's tendency to saturate. Ideally, for a constant illumination, the detector response would be such that the reported signal would be directly proportional to integration time. This is not the case, because eventually the detector's dynamic range is exhausted, and further illumination of the detector does not result in higher signal levels.

When we are taking linearity data on an observing run, we generally arrange for constant illumination of the detector (this is often done during bad weather or during the daytime, with the dome closed and some of the interior lights turned on), set the filter wheel to the K broadband filter (linearity correction is independent of wavelength, and K is a convenient filter to use), and then we take a bunch of images at increasing integration times (itimes). A plot of signal v. itime might look like the following:

[A plot of signal level as a function of integration time]

In a perfect world, the plot would look like the solid line: perfectly linear response until a well-defined saturation level. Unfortunately, actual data looks like the diamond-shaped points, with the data deviating from linear behavior well before saturation. Most of the dynamic range is fairly linear, but there is a healthy range of signal levels that display nonlinear behavoir. Rather than discard these points (which would greatly diminish the detector's dynamic range), we attempt to correct for this nonlinear response by "linearizing" the data. We also try to determine the saturation level, so that we can exclude any pixels which have values too close to that saturation level.

A final note to make is that there may be more than one set of linearity data for each observing run. This will likely be the case if there were two or more observing modes during an observing run. For example, at times we have had a "slow mode" and a "fast mode", where those two modes are distinguished by operating the camera with different values for CTSTIME (clamp-to-sample time) and Vbias. So you will need to "do linearity" for each observing mode for which linearity data were taken.

"Doing linearity"

The first order of business is to prepare a list of the FITS files of the linearity data. The images in this list MUST be ordered by increasing itime. Fortunately, this is how the data are typically taken (ie., in order of increasing itime), so you can probably just use fnamegen.

Next you need to edit the ~/idlpro/lin/newlindatrc configuration file. It should look something like this: 

center of box 1 (ie., 124 110)
80 175
center of box 2 (ie., 24 210)
205 173
center of box 3 (ie., 20 24)
201 83
center of box 4 (ie., 208 214)
46 86
center of box 5 (ie., 182 16)
162 230
half-width (in standard deviations) of display range (ie., `sig' in view.pro)
5
FULL pathname of output file (0 for random name generation)
lindat.txt
FULL pathname of linearity file (0 if not linearizing images)
0
FULL pathname of saturation file (0 if omitting)
0
saturation fraction (ie., .95)
1.0
value to which saturated pixels should be set ('ignore' value from lindata.pro)
-30000.
FULL pathname of cds file (0 if omitting)
0

The first five pairs of entries are the coordinates for the centers of five 21x21 stats boxes. You should endeavor to pick these coordinates such that the boxes do not contain any hot pixels. Next is a value of sig for viewing the images. The next entry is the disired name for the output file.
Carl Welch