next up previous contents index
Next: 7.3 High-Level Scientific Data Up: 7. ISOCAM Auto-Analysis Previous: 7.1 AAC's General Approach

Subsections



7.2 Instrumental Procedures and Data Products $\Longrightarrow$CCIM

Once the SCD data structures have been established a series of instrumental procedures is applied to ensure the reliability and integrity of the imaging data. Each step is discussed below. Many of them have the effect of causing a bit to set in the SCD pixel mask that ensures exclusion of the datum from photometric calculations of any type of which the CMAP is the most important. More generally within SCDs, data are also excluded while the instrument is under adjustment as shown by non-zero values of the CISP[1].CISPDISC flags that show a configuration other than that commanded. Occasional SCDs have all their data excluded as reported in the CUFF:


     No useful data in CSCD3610030101AX
     No useful data in CSCD3610030101AY

Inspection of the raw images reported in the CCIM file gives some idea of the importance of these steps. There are 3-row RATE, RATE_ERR and EXPOSURE images in CCIM.TABLE[1] for every SCD of whatever type, accompanied by a full set of auxiliary data describing the circumstances in which the data were taken. The CCIM images are raw in the sense that they include all the SCD's data irrespective of imperfections of any type, like glitches, dead pixels, badly illumination or defects of any other type. For each CCIM 3-row image, the CUFF reports a short summary such as:


     LW(OBS)  1996-11-11(14:20:43) to 1996-11-11(14:21:40) CSCD361003010107
     RA(J2000)=20 21 48.007 : DEC(J2000)=+39 57 00.67 : ROLL(J2000)=249.20
     14.0-15.8 micron @ 6" per pixel
     CCIM(22:24) 27 planes
     <RATE>=9.6ADU/s  <RATE_ERR>=0.1ADU/s  <EXPOSURE>=56.7s
     CGLL 192 glitches
     CJAM maximum jitter [-21.5:+0.1,-8.2:+0.2] pixels
including details of entries made in some of the products discussed below.


7.2.1 Deglitching $\Longrightarrow$CGLL

It is clear from the most cursory glance at CCIM images that glitches are an unwelcome but common feature of many image readouts as discussed above in Section 4.3. The `Multi-resolution Median Transform' method (see Appendix E) is applied to detect and flag these events on the entire observation's history of each pixel. A few thousand glitches are regularly detected in observations and reported in the CGLL, whose main purpose is to provide a cross-check against any unusual features that might be discovered in the data. Besides the time, detector coordinates and strength of the glitches, CGLL[1].INDEX(*) refers to the CCIM images in which they were detected. For those glitches detected during regular observations of the sky, the corresponding pixel celestial coordinates are reported in CGLL[1].(RA(*),DEC(*)). Zero rather than proper NULL values fill these columns for glitches detected in operational modes other than OBS. The CGLL was also originally designed to accommodate glitch model parameters but no such modelling was ever performed and the COUNTG(*), YG(*), ZG(*) and UTKG(*) columns contain only nominal or null values.


7.2.2 Use of pointing data $\Longrightarrow$CJAM

Detailed use is made of the IRPH and IIPH pointing files for prime data or the CRPH and CIPH for parallel data. First, the CUFF reports any pointing condition that applies to the observation as a whole, such as:


     No up-to-date QSS/STR misalignment measurement: IRPH12900907
after which the RPH file is used to provide the reference celestial coordinates for each SCD using a combination of RPID and time-key. These data are later used to define the reference coordinates attached to the images and thus determine ISOCAM's astrometry.

It is obviously important to take account of data taken only when the instrument was looking in the right direction. A crude assessment is provided by the OTF which shows that the pointing was within a threshold distance, usually 10 $^{\prime \prime }$, of the target position and data are indeed excluded if the OTF is low. However, the OTF threshold is usually equivalent to several pixels and more detailed information is available in the Pointing History files which are in any case, the ultimate source of the SPD OTF. The instantaneous pointing data reported in the IIPH or CIPH, including the RPID and OTF, have a time resolution of 0.5 s that is finer than SPD and thus enable more complete checks. Experience has shown that during a raster the OTF sometimes briefly remains high immediately after a change in the RPID has signalled a move to a new position. If AAC detects a condition of this type in an SCD the high OTF is overruled as reported in the CUFF:


     Overruling the first high QLA(OTF) at RPID=[2,1]
Similarly, if a move has apparently started during a single ISOCAM integration but the CAM OTF is still high, it is also overruled with the report:

     Overruling OTF when final RPID <> [3,1]
The mean instantaneous direction during each integration is used to calculate the offset from the current reference direction otherwise known as the pointing jitter. The jitter could have been used to realign the individual exposures contributing to an image but because of some confusion early in the mission about the reliability of the pointing data the corrections were disabled and never reinstated. The jitter components in pixel units parallel to the detector axes are reported in CJAM[1].DY and CJAM[1].DZ for each integration. Inspection shows that the satellite's pointing system was evidently very stable with the jitter amplitude usually only a fraction of a pixel. These are the most useful CJAM data. The CJAM[1] MEMORY, UNSTABLE and GLITCHED columns are obsolete.


7.2.3 Illumination masking $\Longrightarrow$CUFF

For some optical configurations, the field mirror did not entirely cover the detector causing the appearance of prominent linear features roughly parallel to the edges of the detector, whose positions can vary. Badly illuminated rows and columns of this type are masked out and reported in the CUFF with messages such as:


     780902864<UTK<781068887 Badly illuminated columns [1] [2]


7.2.4 Saturation masking $\Longrightarrow$CUFF

Observers should also be aware that very bright sources can saturate the detector, rendering the photometry dangerously unreliable. In this unfortunate event, prominent messages in the CUFF should draw the observer's attention as in these disjointed fragments which both show the extra CCIM information and anticipate the CMAP and CPSL discussion below:


     +--------+---------+---------+--------+--------+---------+---------+--------+
     CWRN                Saturation problems detected
      ******** ********* ********* ******** ******** ********* ********* ********
      Of the data collected during this observation 193 pixel readout values
      were marked as saturated, so that flux measurements should be treated
       with caution. Shown below are
         - the saturated pixel count for those CCIM images affected;
         - the label `saturated [LW] image' for those CMAP images affected;
         - the label `saturated' for those CPSL point sources affected.
      ******** ********* ********* ******** ******** ********* ********* ********
     +--------+---------+---------+--------+--------+---------+---------+--------+
 
     LW(OBS)  1997-06-14(11:12:16) to 1997-06-14(11:14:14) CSCD576007010150
     RA(J2000)=17 53 36.572 : DEC(J2000)=+56 51 56.89 : ROLL(J2000)=5.18
     11.6-17.0 micron @ 6" per pixel
     CCIM(154:156) 105 planes
     <RATE>=-2.2ADU/s  <RATE_ERR>=0.1ADU/s  <EXPOSURE>=117.6s
     CGLL 532 glitches
     88 saturated pixels
     CJAM maximum jitter [-0.1:+3.5,-0.1:+0.1] pixels
 
     CMAP(142:144) 1997-06-14(11:12:16) to 1997-06-14(11:14:14)
     RA(J2000)=17 53 36.572 : DEC(J2000)=+56 51 56.89 : ROLL(J2000)=5.18
     11.6-17.0 micron saturated LW RPID=[7,6] image of [32*32] [6"] pixels
     <FLUX>=0.53mJy/arcsec^2  <FLUX_ERR>=0.12mJy/arcsec^2  <EXPOSURE>=113.7s
     CCIM(OBS:DRK:FLT)=(154:0:0)
 
     CPSL(58) 1997-06-14(11:12:16) to 1997-06-14(11:14:14)
     11.6-17.0 micron
     ISOC175332.0+565219 17 53 32.043 +56 52 19.3   8413.2 +/- 42.1  mJy saturated


7.2.5 Transient modelling

One of the significant improvements introduced towards the end of OLP software development was the ability to account for the transient behaviour of the LW detector following a change in the illumination as discussed in Section 4.4. It takes a long time for the detector to settle down after a large change in incident flux. In earlier versions a very rough check on the stabilisation was provided by the QLA flag which was raised after a pre-programmed fixed number of exposures had elapsed. Now, by application of the Fouks-Schubert model, individual pixel data are calculated according to the model and stored in SCDs, providing estimates of what those pixel data would have measured in the absence of such non-linearities. The CUFF reports a few details of the calculations.


     FS:Using transient corrector Fouks-Shubert v2.0
     FS:++ Depth data cube :      3310 planes
     FS:++ Pixels corrected:   3389440
     FS:-- Using Taylor    :   3170187
     FS:-- Using Mueller   :    218229
     FS:$$ Mueller failed  :         0
These models provide, therefore, a much better stabilised alternative to the raw pixel values and the pipeline makes use of them in calculating all of its highest-level scientific data products.


next up previous contents index
Next: 7.3 High-Level Scientific Data Up: 7. ISOCAM Auto-Analysis Previous: 7.1 AAC's General Approach
ISO Handbook Volume II (CAM), Version 2.0, SAI/1999-057/Dc