Return to ING home page5.3 Image processing

This page is part of the ING document INS-DAS-31 Design notes for UltraDAS

Available processing

The processing of pixels is done by the Pile::process_pile method. This does up to four distinct processing steps.
  1. Assembly of Readouts within the Pile.
  2. Co-addition of Readouts.
  3. Averaging  (rescaling) of Readouts.
  4. Subtraction of two readouts.
These steps are done in the order listed above. A call to Pile::process_pile may disable some of the steps, but it cannot change the order.

The assembly step is needed for all cameras. The remaining steps support co-averaging of Readouts for IR cameras.
 

Details of assembly

A Mosaic looks to a client object like a simple collection of Regions, but is actually more complex. The Mosaic can contain both input Regions and output Regions, and understands mappings between them.

An input Region (or "tile") for a Mosaic is a region with a raster. An output Region is a rasterless Region into which the pixels of one or more input Regions will be copied. An input-output mapping is simply a note in the Mosaic as to which inputs and outputs are connected. Many inputs can be collected into one output; this is how multi-channel readouts are stitched together. The input and output Regions need not be defined in the same Space; the Mosaic, Region and Space classes collaborate to transform the rasters into the right geometry in the process of copying the pixels to the output.

If an output Region has no raster at the start of processing, it is given a raster in which all pixels are set to zero. This means that any pixels not filled in from the input Regions have the value zero after processing.

Before processing, the Mosaic will only allow access to the input Regions; the Mosaic's iterator skips over output regions. After processing, only the output Regions are available and the iterator skips over the input regions.
 

Details of co-averaging

The intention is to take the average value of corresponding pixels in Readouts obtained in a series of CDS observations. The normal procedure is as follows:
    Repeat for M CDS cycles:
       Repeat for N readouts:
          Acquire one Readout.
          Store the readout in the Pile.
       Integerate.
       Repeat for N readouts:
          Acquire one Readout.
          Store the Readout in the Pile.
       Co-add Readouts.
    Average remaining Readouts.
    Subtract remaining Readouts.
The idea is to reduce the Pile to a single Readout which is the difference between the co-averaged per-integration readouts and the co-averaged post-integration readouts. The calling object may well choose to omit the final subtraction step, in which case the co-averaged pre-integration Readout and the co-averaged post-integration Readout are kept.

The co-averaging is split into two stages: co-adding pixels and rescaling the co-added pixels by dividing by the number of Readouts in the co-addition. The co-addition is done once per CDS cycle to reduce the number of pixels that must be kept in memory. The Pile has to contain 2N + 2 Readouts at the point where each co-addition takes place, whereas the observation involves 2NM readouts in all. N might be in the range 2..10, whereas M can be very large. Clearly, it's infeasible to keep all Readouts separately up to the point of averaging.

For the co-averaging to work, the system has to know which Readouts to co-add and, at the averaging step, how many Readouts have been co-added. Both these numbers are attributes of the Readout class. A Readout is tagged with the number of a co-addition set at construction, and the Pile knows to co-add only those Readouts with a matching number. Readouts with a co-addition tag of zero are never co-added.

During co-addition, all 16-bit-integer pixels are converted to 32-bit floating point numbers. This avoids the risk of overflow that is present in integer arithmetic.