11.10: Defect Databases for DEIMOS CCDs

Part of the processing of CCD images is removal of image defects caused by regions of the CCD which are known to be bad. These typically manifest themselves as hot or dead columns or pixels. The number of separate amplifiers on DEIMOS provides strong motivation to ensure that this stage of the image processing is completely automated.

11.10.1: IRAF Mechanisms for handling bad pixels

Within IRAF the initial stages of automated reduction of CCD images are typically done by tasks in the noao.imred.ccdred package. As a part of ccdred the user can correct for bad pixels. IRAF bad pixel files are described in the help page on noao.imred.ccdred.instruments. The algorithm used is described in the help page on proto.fixpix.

The format of these bad pixel files dates from an era when images were created by single CCDs read through single amplifiers. As with other IRAF utilities, these bad pixel files presume that a detector which is read with different values of binning must be a different detector for each binning value. They do not begin to address the possibilities which arise when a CCD may be read through any one of several different amplifiers.

For the purposes of DEIMOS the best approach appears to be to define a generalized defect database which will be used on-the-fly to generate IRAF bad pixel files.

11.10.2: Generalized Defect Database

Different defects will show up depending on the CCDs, amplifiers, and readout modes. The keywords for DEIMOS images provide enough information to specify each of these variables. The defects for the CCDs used in DEIMOS will be entered into a generalized defect database (GDDB). The information in the GDDB will be used to generate the IRAF bad pixel files.

The following keys will be used to associate a particular observation with the defects which are expected to be found in the CCD data.

Chip and Amplifier ID
This information is found in the AMnDISm FITS keyword
binning
This information is found in the CCnSUMm FITS keyword
begin date
The first date when the CCD/amplifier was known to be acquiring scientific data with voltages/clock/temperatures/waveforms that would reveal this set of defects.
end date
The final date when the CCD/amplifier was known to be acquiring scientific data with voltages/clock/temperatures/waveforms that would reveal this set of defects.
The following additional commentary information should be included in the database for each combination of the above keys
voltages/clocks/temperatures/waveforms
any reproducible configurations of the CCD readout hardware which might affect the defects
map date
date when this defect map was generated
version number for the GDDB
Future developments in the technology of bad pixel correction may require the addition of other information to the GDDB files.
For each defect on the CCD the defect database should contain
coordinates of an affected rectangle of pixels
always measured in the sense that the current amplifier is at pixel (1,1).
type of defect
(e.g.; HOT, DEAD, BLOCKED)
severity of defect
some indication of how many electrons per second is generated by a hot pixel, how many electrons can fit in a trap, etc.
For the purposes of speed, the typical intent would be to read each CCD via multiple amplifiers. For various reasons, including hardware failure, it is possible that a particular CCD might be entirely read out through any one of its amplifiers. Thus, the defects database must contain information about the readout of the entire CCD via each amplifier.

It should be possible to develop an automated procedure which tests each amplifier of each CCD in all the modes which are likely to be used for science. Such a procedure could generate the defect databases.

11.10.3: Conversion of GDDB into IRAF bad pixel files

The coordinates in the DAmSECn card may be negative in either or both dimensions. If so it means that the FITS data along that axis were stored in the direction opposite that of the actual readout. In this case it is necessary to negate the coordinates found in the GDDB when producing the bad pixel file for IRAF.

The tool which generates the IRAF bad pixel files should be configurable. The user should be permitted to specify which types (and severity) of defects are selected from the GDDB.

A typical imaging frame from DEIMOS will consist of data read from 8 different CCDs and 16 different amplifiers. Removal of bad pixels will require 16 different applications of the existing IRAF utilities. This can be automated by creating IRAF cl scripts specifically tailored for DEIMOS data. These cl scripts can act as wrappers around the tasks in the noao.imred.ccdred package. There is a precedent for this with the CTIO ARCON detector.

Steve Allen <sla@ucolick.org>
$Date: 1996/03/19 00:16:31 $