Reference 7-1 -	E-mail, " Cassini ISS Calibration", Alfred McEwen, October 15, 1997
Reference 7-2 -	E-mail, "Review of Alfred's Calibration Outline", Charlie Avis, October 24, 1997
Reference 7-3 -	E-mail, "Modified Section 7.0 Radiometric Steps", Charlie Avis, May 14, 1998
Reference 7-4 -	IOM 388-PAG-CCA98-14, " NAC FM Calibration Results : Nonlinear Response Terms", Bob West and Charlie Avis, July 20, 1998 (see Section 5.1.11.3)
Reference 7-5 -	IOM 388-PAG-CCA98-15, " NAC FM Calibration Results : Nonlinear Response Terms", Bob West and Charlie Avis, July 20, 1998 (see Section 5.1.11.4)

If the data was sent through a 12-8 bit converter, convert it back to 12 bits (16 bits actually).

The conversion type used is stored in the VICAR label as an item called conversion_type.

conversion_type = VICAR_label.conversion_type;

• 12BIT :no conversion
  TABLE :12-8 look up table
  8LSB :8 least significant bits

  if conversion_type = TABLE then

  • DN_Step1(i,j) = 8-12_lut[ DN_raw(i,j) ]

  else if conversion_type = NONE or LSB then

  • DN_Step1(i,j) = (short)DN_raw(i.j)

  endif

Uneven_bit_weight_table stored in tables with names of format:
camera_gain_optics-temperature, specifically:
["wac"|"nac"]g[1|2|3][m10|p5|p25]

Note: There are some combinations of camera, gain state, summation mode and optics temperature for which UBW tables were not produced. The detected DN's for these cases should NOT be altered unless tables are created from in-flight data or model tables are produced.

This step can be skipped for DCT-compressed (Lossy) data.
 

• // Get appropriate UBW table

  if UBW table (based on camera, gain, and optics temperature ) exists

  • UBWtable = ["wac"|"nac"]g[1|2|3]["m10"|"p5"|"p25"]

  else

  • UBWtable = default_table // a simple 1-4096 table

  endif

  DN_Step2(i,j) = UBWtable[ DN_Step1(i,j) ]

DN = DN - frame_bias

The frame bias can be retrieved either from the OFFSET label (mean of all available offset values), or as the average of the overclocked pixels which are stored in the binary prefix of each line.
 

• if label "OFFSET" exists then
  • get the offset from OFFSET label

  else

  • total = 0
    for i = 1 to number_of_lines
    • total = total + DNbinary_prefix(i).overclocked_pixel

    endfor
    bias = total / number_of_lines;

  endif

  DN_Step3(i,j) = DN_Step2(i,j) - bias

Note : For prelaunch calibration frames, the VICAR label item OFFSET contained the mean value of all available Overclocked Pixels. This value was, however, truncated to an integer. For Flight data, this value will be floating point and the code will throw out the huge spurious values that appear from time to time before creating the mean.

DN_Step4(i,j) = DN_Step3(i,j) - Dark_cal(i,j)

Dark_cal frame accounts for dark current (DC) and Residual Bulk Image (RBI), and varies with camera, gain, exposure time, summation mode, compression mode, framing time, readout rate, T of CCD, T of sensor head if gain 3, etc., and may change over time.

Earch Dark_cal frame is typically produced for many (order 10) individual dark frames, to despike and average. Dark-current frames should have their offset subtracted before being included in any average. This not only makes the frames consistent, but removes the Gain 3 dependence upon temperature, because it is the offset which is being affected.

IT IS NOT FEASIBLE TO COLLECT UNSHUTTERED FRAMES THAT EXACTLY MATCH ALL PARAMETERS FOR EACH SHUTTERED FRAME, unless we dedicate half of our data return to dark frames.

Also, it is desirable to average many dark frames in order to remove radiation spikes and correct for the low-level graininesss. We especially cannot dedicate ~90% of our data rate to dark frames.

Options:

1. Collect standard dark frames for commonly used modes and typical temperatures (order 100 calibration files). Update in-flight at Jupiter and ~once/year at Saturn.

100 x 1024 x 1024 x 2 bytes = 210 MBytes to keep on-line.

Note : There was not a great amount of data , therefore not a great amount of analysis, comparing dark current data among the different gain states. Dark current calibration data (with integration times from 0 seconds to 20 minutes) was only taken in Gain State 3. The comparison made among the gain states was for the bias frames (integration time of 0 seconds). This evaluation noted different line profiles among the gain states with the only similarity being between gain state 3 and gain state 2 (both 1x1 summation mode). It has been noted that dark current line profiles are influenced by many factors : transfer rate from detector to memory (telemetry rate), size of image file, light flood (for exposures longer than 1 second), etc. Suffice it to say that more data and analysis is required in the future to determine how applicable and accurate it is to use the gain ratios for dark current calibrations among the different gain states. Although, comparison of bias frames for gain state 3 and 2, using the gain ratios, showed a difference of 1 DN.

2. Gary Yagi's camera model in the planning tools does a good job of predicting the dark-current (and its dependence upon line number), but not lightflood spatial variation.

3. When photometry is critical, plan in-flight dark frames as part of each observation sequence.

Calibration program must either look for appropriate standard dark correction frame or accept a user-input dark_cal frame.

(Algorithm to be constructed.)

DN_Step5(i,j) = f{DN_Step4(i,j)}

NOTE : The algorithm should recognize when each of the bright/dark pixel pairs becomes a problem. This depends on both the exposure time and the size of the trap which can be obtained from the calibration files provided for pixel pair identification. We would probably want to do nothing to a bright/dark pair if the exposure time is not long and/or if the size of the trap is small (~ a few percent for the longest exposures).

Linearity tests made during thermal vac calibration revealed nonlinear behavior. Departures from linearity (decreased sensitivity at high DN levels) were strongest for Gain State 0, 4x4 Summation. To correct for this nonlinear behavior, a correction factor (see Reference 7-4 and 7-5) must be applied. Note : Corrected DN values greater than 4095 will result in some cases even though the data were not actually saturated. This fact will have an effect on the radiometric correction software.
 

DN_Step6(i,j)= f {C * DN_Step5(i,j)}

where
C is the nonlinearity correction factor, and
f is an undefined algorithm to account for corrected DN values greater than 4095

(Algorithm to be constructed.)

Notes :
a) The calibration blemish files currently identify the bad pixel and which of its neighbors are good.
b) In order to track if a pixel has been interpolated, a suggestion was made to add a bad data binary header to each image (similar to what Galileo did).