Table of contents:
Introduction and Overview
The raw WIRCam images have the odometer names ??????o.fits, are coded in
16-bit unsigned integers (0-65535 - make sure to use the BZERO and CHIPBIAS
keywords) and are stored as multi-extension FITS (MEF) images (1 primary header
+ 4 extensions). Additionnally, the MEF can be cubes or singles slices, i.e.
each extension can contain one or more images (look for NAXIS3=? in the
extension headers). The full mosaic and cube slices can be correctly viewed
with ds9 version 4 and higher with the commands:
ds9 -mosaicimage ??????o.fits, or
ds9 -mosaicimage wcs ??????o.fits (correctly displays the WCS)
The IDL Interpretor of WIRCam Images (`I`iwi - pronounced E-e-vee - a native
hawaiian bird) preprocesses all the o.fits images and produces two sets of
results: 1) the ??????p.fits images which are detrended (dark subtracted, flat
fielded, etc) and are sky subtracted; 2) the ??????s.fits images which are
detrended but NOT sky subtracted. This is intended so that PIs can use their
own sky subtraction strategy without having to start from scratch. There is a
subtle difference between PREprocessing and processing. CFHT preprocesses every
single image but does NOT coadd them into a deeper stack. The stacking,
so-called the processing, can be done on request by the TERAPIX team.
The image processing steps needed to remove the instrument imprints are
globally referred as the "detrending". In addition to the standard detrending
steps usually taken (dark subtraction, flat fielding, etc), the WIRCam
detectors (HAWAII-2RG) have specific imprints requiring special detrending
recipes (R stands for Reference pixels, G for on-chip Guider - not the same
beast as HAWAII-2 - a.k.a. WFCAM). For example, on some detectors, the guide
window produces a structured cross extending all the way to the edges of the
arrays. But the most important artifact plagging the WIRCam images is the
different types of electronic crosstalks which produce doughnut-shaped
artifacts which need to be accounted for. The next section will dwelve in all
the details of the detrending recipe.
To identify which version of `I`iwi was used for preprocessing, look for the
keyword IIWIVER in the "Processing Pipeline" section of each FITS
extension. That keyword was not put in for the beta version. Chances are the
beta version was used if preprocessing was done before September 2007.
It is probably wise to familiarize yourself with how WIRCam images are generated before
going any further.
Figure 1. Flow Chart of the Preprocessing of WIRCam images
Caption: The images are first detrended to remove all detector imprints
(except the crosstalks). Then the sky is constructed using adjacent adjacent
s.fits images and subtracted. Then, as a final step, the crosstalk is removed
from both the finally preprocessed images (p.fits) and the detrended-only
images (s.fits). Astrometry and photometry are then performed using SExtractor
and are updated in the image headers. The astrometry is a simple linear
solution while the photometry is based on standard stars observations (also
based on 2MASS for the J,H and Ks filters).
- Reading the images
- Flagging the saturated pixels
- Non-linearity correction
- Reference pixels subtraction
- Dark subtraction
- Flat fielding
- Bad pixels masking
- Guide window masking
Reading the images
The raw images are stored as multi-extension FITS files. Each extension can
be a single slice or a cube of up to 28 slices. If the keyword NAXIS3 exists,
it is set to the number of slices. We prefer to use the CMPLTEXP keyword
(non-standard, put by CFHT) which always exists and states the same
The raw images are stored in 16-bit unsigned integers. This is also the
output format of the processed images (p.fits and s.fits). The first step in
`I`iwi is to convert 16-bit to 32-bit floats because all image processing steps
are in floats. In converting to float, one must be carefull to use both the
BZERO and CHIPBIAS (CFHT non-standard) extension keywords. All raw and
processed WIRCam images have had an arbitrary constant value added to
prevent 16-bit wrapping of negative numbers into high positive numbers when
producing the CDS image (subtraction from two images). We call this constant
the CHIPBIAS and we have settled its value to 7000, but it used to be 3000
earlier in the life of WIRCam (at least the first year). In addition, the very
standard BZERO keyword is usually set at 32768.
In IDL, for example, reading an image is as follows:
raw = bzero + float(mrdfits(RAW_NAME, extension)) - chipbias
Important note. A constant CHIPBIAS of 7000 is arbitrarily added to
all processed WIRCam images. On sky subtracted images, this means the
background level is around 7000 adu.
Flagging the saturated pixels
A very first step is to identify which pixels are likely to be saturated and
keep a record of them so the finally preprocessed images can have them
correctly flagged to 65535. We adopt thresholds of 24000 adu (for semesters 05B
and 06A - which have a low electronic gain) and 36000 adu since semester 06B
(the gain was changed in August 2006). These thresholds are not as definitive
as those one would set for CCD images. This is simply because WIRCam images are
CDS subtraction and, depending on the sky brightness (actually the sky rate)
and detector readout time, the background in the first read may be at a higher
or lower level than expected.
Important note. An irreversible filter is applied to the data has it
is being taken at the telescope. The RAW and REF reads that go into producing a
CDS image are compared to a saturation map, in the acquisition system itself.
Pixels in either of the two reads having values above the map are immediately
flagged as saturated and assigned the value 65535 in the CDS image that is
saved. Care was taken in producing that saturation map so it represents the
values at approximately 95% full well. This has the advantage of limiting the
number of stars affected by black holes at the core of bright saturated
objects, easying the task of our automatic acquisition software that picks
Near IR detectors are notoriously non-linear in their flux response
(typically 5% non-linear before saturation compared to less than 1% at
saturation for CCDs). The non-linearity is intrinsic to the arrays (the charges
accumulate in a capacitor-like device for which the capacitance is affected by
the number of charges) as opposed to CCDs for which non-linearity comes from
the non-perfect behavior of amplifiers.
The problem of the non-linearity correction (NLC) is compounded by the fact
that only CDS images are saved for WIRCam, not the two single reads (learn more
about the image readout scheme). This
means that an iterative approach is required to apply the NLC.
We characterized the non-linearity of each of the four arrays by observing
the warm floor of the observatory when WIRCam is off the telescope and taking
images of different exposure times (typically from 5 seconds to 90 seconds) to
yield fluxes of 4000 ADU to 55000 ADU per pixel. We frequently (every 15
minutes for 7 minutes) took short exposures (5 to 7 seconds) to establish a
baseline and make sure there was no intrinsic flux variation. For this
calibration, we exceptionnally save both reads as well as the CDS image.
That characterization started in August 2006....
Impact on the zero points. Before/After August 2006....
For the moment, here is an example of the WIRCam Non Linearity Curves.
Reference pixels subtraction
HAWAII-2RG detectors have an effective surface of 2040x2040 sensitive
pixels. A 4-pixel wide border is used as reference to correct for relatively
slow bias drifts, first seen during WIRCam commissionning as column to column
DC offsets on a scale of several tens of columns.
Here, it is assumed that each column is approximately constant and that any
drift is seen as a level change between columns. In other words, we correct
only the presence of vertical bands. Only the rows of 4 reference pixels on top
and at the bottom of images are used, those on the left and on the right are
First, we correct the reference pixels themselves because a small DC level
slope is seen from line 0 to line 3 and from line 2047 to line 2044 (most
probably due to capacitive coupling
effects). So, each of those 8 lines has its median subtracted from it.
Then, we consider the 4 reference pixels on top and at the bottom of each
column. We consider they follow any DC change that affects the whole column.
The idea is to subtract the DC level seen on those 8 reference pixels from the
2040 data pixels of the corresponding column.
We construct a 2048x8 matrix of reference pixels that we median along the
vertical axis to obtain a 2048x1 reference line (that median of 8 reference
pixels is to reduce noise in the measurement). Then, to further reduce noise
and spurious effects, we smooth the 2048x1 line with a boxchar of 9. Then we
subtract the corresponding scalar value for each data column (e.g. column 5 =
column 5 minus 5th index of reference line).
Here is the IDL code. We pass imraw, the original image, to the function:
;Set the lines to be used as reference pixels, those at the top and bottom of
line = [0,1,2,3,2044,2045,2046,2047]
med = fltarr(n_elements(line))
im = imraw
;Try to correct the small slope seen in the reference pixels themselves, i.e.
;from line 0 to 3 and from 2047 to 2044 by subtracting the median horizontal
;value from itself.
reflines = fltarr(2048,n_elements(line))
for i=0, n_elements(line)-1 do begin
med[i] = median(im[*,line[i]])
;Apply offset so all columns have a median of zero
reflines[*,i] = float(im[*,line[i]]) - med[i]
;Now, for each column, use the median of the 8 reference pixels available.
;Crunch 8 lines into 1. This is a vector of 2048 reference columns.
averagecolumn = median(reflines,dimension=2)
;Smooth that column with box of 9. This is to prevent introducing noise but
;it also means that column to column variations on shorter timescales can not
;be corrected for.
box = 9
averagecolumn = smooth(averagecolumn,box)
;Subtract the average, smoothed column from each data column
for i=4,2043 do begin
im[*,i] = imraw[*,i] - averagecolumn
The dark current of the WIRCam detectors is generally low (less than 1
e-/sec). The cryostat is regulated to within one thousandth of a degree at
about 80 K. So the dark current is thought to be very stable and varies
linearly with integration time (figure ?).
Instead of using up one filter position to have an aluminum blank for dark
acquisition, we simply cross two science filters of different bandpasses (one
in each of the two filter wheels), for example LowOH1 and H2. This has proven
to yield exactly the same dark level as a pure blank.
Figure ?. Master darks of different exposure times
Caption: Each of these master darks is a median combination of a minimum
of 15 single raw darks. They were obtained in the hour following the end of a
Several structures are seen in darks:
- A background component slowly increasing with exposure time at rates of
less than 1 e-/sec.
- Hot pixels (10-1000 e-/sec), especially at corner boundaries and on the
right of the bottom right array. We have seen hot pixels changing position by a
few pixels between thermal cycles.
- Warm "blobs" (less than 100 e-/sec) of about 100-1000 pixels, for example
on the left of the lower-left array.
- Persistence effects due to stars or night sky emission observed during the
night. It is seen as fainter "blobs" or patchy background on long 630 sec darks
only for the lower-right and upper-left arrays.
In `I`iwi, dark subtraction is done for each slice by choosing the closest
(in time) processed dark cube of the same exposure time. All except the
persistence effects subtract well when a dark of the correct exposure time is
chosen. A processed dark cube consists in a median of generally 15 darks taken
sequentially (usually only 7 for 240sec or longer exposure times). Prior to
doing the median of 15 images, each raw image is corrected for the common noise
pattern (that's an electronic noise pattern common to all the 32 amplifiers --
because pixels are read in parallel -- and is constructed by the same method as
that to construct the median amplifier
for the crosstalk correction).
A note on master darks. In the future, we plan on constructing a master dark
valid for each run, one for each exposure time. Starting with semester 07B, we
are systematically taking darks every morning (darks were taken manually and
not as frequently before that).
We are using dome flats obtained at the beginning of each observing run on
the observatory dome illuminated with a tungsten lamp. We obtain a cube of 15
raw flats with the dome light turned on and subtract the 15 raw flats of the
same exposure time with the light turned off. This ensures any instrumental
thermal component is removed. We typically use 5-6 second exposure times for
wide band filters and up to 30 second exposure times for narrow band filters
and target fluxes of about 10000 adu on lamp-on flats.
Here is how dome flats are processed:
- Each detector is treated entirely independantly.
- All raw flats (lamp on and off) are multiplied by the bad pixel
mask, subtracted by their corresponding dark, and the background level is
measured using a simple median.
- Flat-off. Some flat-off images are rejected when their background
level is different by more than 1% compared to the others, or when more than 3
sigma off the others. Then the flat-off images are normalized to 1, a cube is
created and the median (through dimension 3) is obtained. Finally, the median
flat-off image is multiplied back by the median of all initial background
- Flat-on. Each flat-on has the final flat-off subtracted from it.
Then the same rejection criteria as for flat-off images are used. Then all
flat-on images are normalized to one before being put in a cube. Finally, the
median of the cube is obtained (through the third dimension). This produces the
final processed dome flat image.
Flat fields show mostly a radially increasing flux level and, fortunately,
no high spatial frequency fringes. The pixel to pixel quantum efficieciency
variations are of the order of a few percents.
A very important note on flats and photometry. The `I`iwi convention
is to treat each detector entirely separately. This means that the flat
fielding step does NOT remove detector to detector quantum efficiency
differences. The median background value of the processed dome flat is 1 for
each of it's four detectors. In other words, the same star observed with the
four detectors will yield different flux measurements. The relative quantum
efficiency differences are instead being absorbed in the quoted zero-point
found in each extension header of the processed images (s.fits and p.fits).
More details in the photometry
section. This convention has the advantages of 1) not changing the
electronic gain values and therefore the relative photon statistics, 2)
***there were more fundamental reasons I forget.
An other important note on illumination correction. No illumination
correction is made in 'I`iwi. The change of pixel scale is small (less than 1%
in the corners) and the photometry error that it introduces is much smaller
than the current absolute photometry uncertainty (of 4-5%).
Preliminary photometric measurements using twilight instead of dome flat
fields indicate that dome and twilight flat fields are consistent to within
0.5-1.0%. Nevertheless, twilight flat fields are obtained on a regular basis
and will probably be used in the next version of `I`iwi.
Bad pixels masking
`I`iwi uses the bad pixel mask constructed by Chi-Hung Yan (Academia Sinica
- Institute of Astronomy and Astrophysics - ASIAA). He developped a method to
construct bad pixel masks from darks and dome flats aided with a ds9
interface to do a second pass manual inspection - see Chi-Hung's
The bad pixel mask has 1 for good pixels and the float Not-a-Number (NaN)
value for bad pixels.
Guide window masking
On-chip guiding unfortunately has side effects on the science images. These
artifacts depend on the DSP code used in clocking the science and guide pixels
and a lot of effort was spent to optimize the code and minimize the unwanted
artifacts. This means the side effects description and the detectors afflicted
have changed between observing runs, even within a run. That complicates their
removal during post processing.
Figure ? shows an example of the cross centered on the guide window that
extends across the whole detector. Since semester 06B, the bottom two arrays
are free of guide window artifacts, only the upper two arrays are afflicted.
Figure ?. Example of the guide window artifact on a fully preprocessed image
||Zoom centered on the guide window
The guide window size has changed over the life of the instrument and,
unfortunately, the corresponding header keywords have not always been correctly
populated. The headers have been correct
Note. A guide window is always read out but put in a predefined bad
pixel region for unguided science exposures. Science calibration images like
darks and flats are always obtained with the guide window clocked in order to
always be in the same hardware setup.
Figure ?. The two different types of guide window artifact suppression
Sky subtraction steps:
- Identifying adjacent images
- Background level measurement
- Source masking
- Sky construction - standard
- Sky construction - for nodding
- Sky subtraction
- Constraints and pifalls
Intro to show sky movies etc...
Identifying adjacent images
Sky construction requires the use of at least 3 (ideally 5) adjacent
observations taken through the same filter at different dither positions. The
detrended images are usually normalized to 1, sources are masked and a median
is taken for each pixel. Best sky subtraction results are obtained when using
images obtained close in time and space. So, for each image, a different set of
neighboring images needs to be selected.
Background level measurement
The sky background level is estimated on detrended images by using a simple
median on each detector. To normalize the mosaic to a flux of 1, the relative
quantum efficiency of each detector is taken into account.
EXPTIME (sec) SKY LEVEL (adu/sec) CORRECTED FOR QE MEDIAN NORMALIZED
All 1 2 3 4 1 2 3 4 All All
30.000 70.77 62.18 67.34 67.55 66.91 66.94 67.00 66.99 66.96 1.00874
30.000 71.69 63.08 68.17 68.34 67.78 67.90 67.83 67.77 67.81 1.02142
30.000 70.72 61.69 66.89 67.41 66.87 66.40 66.55 66.85 66.70 1.00479
30.000 69.78 61.26 66.44 66.71 65.98 65.94 66.11 66.15 66.04 0.99488
30.000 69.85 61.50 66.59 66.69 66.05 66.20 66.25 66.14 66.17 0.99679
30.000 70.09 61.46 66.30 66.64 66.27 66.16 65.96 66.08 66.12 0.99606
30.000 69.90 61.28 66.43 66.77 66.09 65.96 66.10 66.21 66.09 0.99566
30.000 68.94 60.52 65.47 66.14 65.19 65.14 65.14 65.59 65.17 0.98166
For sky construction purposes, a copy of each detrended image is made. On
that copy, all positive sources are masked (i.e. put to Not-A-Number - NaNs).
To identify which pixels have to be masked, the pixels with a value of zero in the
"checkimage" are used. Here is the parameters used when calling SExtractor:
The wings of stellar sources (under the 1.5 sigma threshold) can bias the
sky construction and produce dark rings after sky subtraction. To prevent this,
the idea is to enlarge each masked star to make sure no wing signal creeps in.
The fastest way to do this is to apply smoothing using a box of 5x5 (the smooth
command in IDL).
Sky construction - standard
To be written
Sky construction - for nodding
To be written
To be written
Constraints and pifalls
To be written
- Positive Cross-talk
- Negative Cross-talk
- Edge Cross-talk
Until March 2008, WIRCam was affected by three types of cross-talks. We
liberally named them, the "Negative", "Positive" and "Edge" cross-talks. Here
are detailed information and examples on the
Nothing is done to remove this cross-talk. It is confined to the 8
amplifiers of an affected viedo board.
This is the most important source of cross-talk. We basically subtract a
median amp from each of the amplifiers. The median amp is constructed by
slicing all 32 amps from a detector to create a cube of 2048x64x32 pixels (from
an image where sources are masked) then simply taking the median.
The edge cross-talk is suppressed during the medamp subtraction that removes
the negative cross-talk. No need for further subtraction.
- Full Mosaic Linear Solution
- Detector by Detector Refinement Using IMWCS
The goal of the astrometry solution at CFHT is to be within an error of
about 1 arc second and this goal is almost always achieved. For the sake of
simplicity, of robustness and because there was no FITS standard to express
non-linear terms, the `I`iwi WCS solution is purely linear (assumes a constant
scale). The following figure shows that WIRCam has a field distortion of about
1% in the corner of the mosaic.
Figure x. WIRCam Field Distortion as Determined by Scamp
Knowing the geometry of the detectors, a first fit using all 2MASS stars
found on the whole mosaic is performed. Then, provided enough stars are found,
the WCS of each detector is refined individually. The RMS scatter of the
resulting WCS solution is generally about 0.3-0.8 arc second.
Full Mosaic Linear Solution
The full mosaic approach makes use of the known geometry as determined by
the Terapix team who produced a wircam.ahead file. `I`iwi uses this geometry to
project into sky coordinates (expressed in degrees with the field center being
at 0,0) the sources found by Sextractor. It fits a rotation as well as d_alpha,
d_delta offsets. It then matches stars to the 2MASS catalogue. This method is
robust (even for sparse fields) because it uses all sources found on the
mosaic. But the detector geometry is not exact and it is not rare to see larger
than 2-3 arc second discrepancies for stars in the corners of arrays.
Detector by Detector Refinement Using IMWCS
Starting with the list of matched stars obtained in the full mosaic
solution, this method operates on individual detectors to refine the WCS
solution. `I`iwi calls the IMWCS software in the WCSTools package (D. Mink,
Harvard). This generally yields a better than 0.5 arc second rms solution.
In rare cases, only the full mosaic solution converges and is kept. To know
which method was used for each extension of the FITS file, look at the
WCS_ORIG keyword in the "Processing Pipeline" section. IMWCS-linear
means that the detector by detector refinement method using IMWCS worked and
was kept. The quality of the fit is given in MATCHRMS, the number of
stars used to initiate the fit is WCSNREF and the number of stars kept
in the fit is WCSMATCH. If WCS_ORIG='MOSAIC-linear' then only the
full mosaic solution could converge in which case MATCHRMS,
WCSMATCH, WCSNREF and more keywords are missing.
- Difference in Sensitivity Between Detectors - No Correction Done
The star flux is obtained using SExtractor and the FLUX_BEST is used.
Arguably, this is NOT the best output photometry to use but for other reasons
(an unidentified bug in SExtractor when using weight maps and thresholds
different than 0) it was used rather than FLUX_AUTO (which IS probably
better). No aperture correction is done on the pipeline side. We use the
Sextractor values directly.
Determining the zero point depends on the filter used. For narrow-band
filters (basically all filters except J, H and Ks), we adopt the zero points as
determined from standard star observations. The problem is there are no
published standard star photomeries in the narrow bands so we use three of the
four CALSPEC spectrophotometric standards (GD71, GD153 and G191B2B) which have
well modeled near IR fluxes. The modeled magnitude is obtained by convoluting
the filter response curves with the model spectra using a sotware developped
and tested by S. Arnouts. Then:
ZP_measured = mag_modeled +2.5*alog10(stars.flux) -2.5*alog10(stars.exptime)
and the zero point thus measured is stored as PHOT_C0 in each FITS
extension header of the s.fits and p.fits files. This WIRCam Zero Points
page details the values used in the pipeline with curves for each filter
and the adopted zero point offsets between detectors.
For J, H and Ks, we also use the 2MASS measured values for all 2MASS stars
found on each detector. These measurements are done on each actual slice of a
cube, on a detector by detector basis. We apply:
ZP_measured = mag2mass +2.5*alog10(stars.flux) -2.5*alog10(stars.exptime)
and simply take the median of all stars (bright and faint - a weighted
average would be more appropriate indeed for `I`iwi version 2). The zero point
thus measured is stored as FOTC_?? in each FITS extension header
of the s.fits and p.fits files (?? represents the slice number in the cube).
No color term is yet included in the pipeline.
Difference in Sensitivity Between Detectors - No Correction Done
A very important note about how the different detector sensitivities is
handled in `I`iwi. There are two possible conventions: 1) Normalize the flux of
each individual detector to a common-to-all-detectors zero point, generally
done after flat fielding ; 2) Make no normalization and simply have different
zero points for each detector but write the zero point in the FITS extension
header. The second convention is adopted for `I`iwi. This means that on the
finally preprocessed images, stars of the same magnitude placed on the four
arrays will have different flux counts. The zero point is found in each FITS
extension under keyword PHOT_C0 (as determined from standard stars) or
keyword FOTC_?? (as determined from 2MASS stars in the field, ??
represents the slice in the cube starting with 01).
The main reason for doing so with WIRCam is to preserve key hardware constants
like electronic gain and saturation values which would be changed if we were to
normalize all detectors to a common zero point.
Note for Megacam users, the other convention is use for Megacam. Elixir
normalizes all the detectors to a common zero point.
For stacking purposes, one therefore needs to scale the flux of each
detector appropriately. With Scamp (from E. Bertin) one needs to have the
argument MAGZERO_KEY set to PHOT_C0 or FOTC_?? and use a
post May 2007 version of scamp (a bug - that argument was not handled properly
Important Header Keywords
FITS header keywords:
- The important keywords
The WIRCam FITS files are multi extension files (MEF) with a primary header and
4 extension headers. `I`iwi updates and edits the extension headers but not
much is done with the primary header as processing is mostly on a per detector
The important keywords
There are several sections in the extension headers:
- Mandatory keywords
There is one very important keyword here: BZERO. Having BZERO defined at
32768 enables the images to be encoded in 16-bit unsigned integers (0-65535).
When using mrdfits in IDL, this means the BZERO must be added off to the values
read (which mrdfits assumes by default to be signed integers). The behavior of
other FITS reading tools may be different. Notice that an arbitrary constant
value is also added to the adu values and this is given as CHIPBIAS in the
'Detector' section. The CHIPBIAS must be subtracted off. So:
raw = BZERO + float(mrdfits(RAW_NAME, extension)) - CHIPBIAS
- Observation Summary
SLDATE?? is the exact date when each of the image slices was
obtained. It corresponds to the start of the reset. These keywords were added
on October 26 2007.
Since October 2 2007, DATE represents the moment at the start of the
reset of a CDS image. Before that date, it corresponded to the time at the end
of the exposure.
EXTNAME is the extension name and actually represents the part number
for each of the four HAWAII-2RG detectors.
QEPOINTS is the only information provided by the detector
manufacturer. It gives the quantum efficiency in two broadband filters: J and
K. These values should not be taken at face values, they are probably affected
by 10-15% errors (the maps showed a wing of pixels with QE higher than 100%!).
See the WIRCam Throughput web page for more
LIN1PCT, LIN3PCT and LIN5PCT were meant to represent
the adu level at which the detectors are non linear by 1, 3 and 5 %. One should
rather see the WIRCam Non Linearity web
page to obtain more relevant information.
MDCOORDS is 1 or 4 and represents the number of images that are part
of a micro dithering pattern. MDCOORDSis 1 when no micro dithering is
used and MDCOORDS is 4 when it is, in which case MDCOORD? take
the x,y offsets applied to the tip-tilt plate to effectively dither by half
pixels. MDREPEAT represents the number of loops of micro dithering done
for this cube.
CMPLTEXP is a usefull keyword that states how many slices were
successfully acquired for this cube. It exists in case of problems in the image
creation and because NAXIS3 (if it exists) does not otherwise
discrimintae against bad slices. It should generally match the number of
expected slices, NEXP, unless a problem happened during observation or
CHIPBIAS is an arbitrary constant value added to the adu values in
order to be able to save in 16-bit integer format without having the negative
values wrapping during the CDS construction.
EXPTIME is the accurate exposure time as determined by the DSP code
that controls the readout scheme. It is precise to at least the millisecond.
There is no shutter in this instrument and the exposure time is determined by
the time period between the first and second reads of the CDS.
OPENTIME is the period of time during which photons could accumulate
on the arrays, i.e. the time elpased between reset and the last read.
WCBLANK describes whether any form of on-chip guiding reset was done
during the full science image reset or readout. This keyword was added somewhat
late in the life of the instrument when it was realized that on-chip guiding
during science reset/read introduces artifacts in the science images.
SCFOWLER describes whether any Fowler sampling is done in
constructing the image. By default, most filters use SCFOWLER=1. For the
LowOH filters, SCFOWLER=4.
TRGTYPE can be "TARGET" or "SKY". It is meant as a keyword to know
whether an image can be used to build a sky frame in the nodding observing
mode. In the case of normal Dithering Pattern (DP) or Wide Dithering Pattern
(WDP) mode, this keyword should always be "TARGET".
All the guider keywords in this section are legacy keywords from other
instruments and should be ignored entirely. There is no separate guider for
WIRCam, only on-chip guiding, and it is the subject of the WIRCam Guider
INSTZRA and INSTZDEC are the instrument off-axis offsets
applied to the target when sending coordinates to the telescope so that the
presumed target be positionned off the mosaic center (out of the gaps) and in
the corners of the North-East detector.
- WIRCam Guider
Most of the keywords in this section are self explanatory. Note however that
before September 2006, they were prone to errors and will often be misleading.
WCCLOCK1,2,3,4 are meant to tell whether on-chip guiding pixels were
being clocked or not. When clocked, guide pixels introduce artifacts on the
science images which requires a different set of calibration than when no
clocking occurs. Since late 2006, pixels are always clocked but placed in
predetermined positions in the case where guiding is not requested.
WCONOFF1,2,3,4 are meant to tell whether on-chip guding is enabled or
not. If guiding is not requested then these keywords are set to 0 even if
(since 2006) pixels are being clocked anyway. WCONOFF1,2,3,4 is
basically a way to kwow if meaningfull values are to be expected in all other
WCNULL?? are the target centroid position for each guide star. They
take values between -0.5 and +0.5 pixels and exist to compensate for the
inability of positionning a guide window to a sub integer pixel value.
- WIRCam Acquisition
This section is populated by the acquisition software which takes a snapshot
image after telescope slewing to control the exact positionning of the field
center and to choose guide stars automatically.
Note that the value of WCGDDEC1,2,3,4 was incorrect before February
29 2008. The values were incorrecly divided by 15 before being converted to
WCAQPTST states whether exact field centering was requested and
applied or not. If so, the centering is then precise to within an arc second.
- WIRCam Environment
Most are self explanatory keywords of various measurements of environment,
telescope and instrument temperatures.
WCFOCTMP is the closest measurement to the detector temperature.
- Processing Pipeline
CRUNID describes the instrument installation ID. It usually follows
the QRUNID keyword except if, for example, unmounting and remounting the
instrument during an observing run was performed. As of March 25 2008, it never
happened for WIRCam. This is to let the pipeline know that it should be using
different sets of calibrations (presumably because illumination and rotation
may have changed in the process).
More to be added later...