- PIO
- Safety
- Sciops
- Gemini Home
- Telescopes and Sites
- Instruments
- Observing with Gemini
- Schedules
- Data and Results
- Helpdesk
- Future Instrumentation
- Statistics
- Publications
Change page style:
NIRI Data Primer
This page describes some features of NIRI data and its reduction. Go directly to:
- Raw data and nprepare
- Array characteristics
- Vignetting by the wavefront sensors
- Recognizing saturation
- Dealing with detector problems
Raw data and nprepare
Raw NIRI images are written as multi-extension FITS (MEF) files with a single unnamed extension [1] containing the image data. Most of the information is contained in the primary header unit (PHU, extension [0]). Additional important information is added to the PHU by the IRAF task NPREPARE, which is part of the current release of the Gemini IRAF package.
Raw files stored by the Data Handling System (DHS) are written with file names of the form N20051010S0001.fits. The date is the UT date at the beginning of the night. Because the DHS is writing data from multiple instruments, including the wavefront sensors, the NIRI file number sequence is frequently interrupted. Missing file numbers do not necessarily indicate missing NIRI data.
NIRI writes images taken as coadds as a summed, not averaged, image. This means that if one takes 10 coadds of 1 sec each, the final image will have a flux level in ADU equivalent to 10 sec. The task NPREPARE leaves the pixel values as written by NIRI but modifies the header keyword EXPTIME to be the total exposure (the original exposure time x number of coadds). NPREPARE adds a keyword COADDEXP that contains the original exposure time for each individual frame. While this behavior may be confusing to some, it is consistent with one ADU in the output image representing a fixed number of detected electrons.
The NIRI array controller averages the data based on the number of digital averages or multiple non-destructive read pairs, so no modification is necessary for different LNRS or NDAVGS values. The flux value will correspond to the exposure time, and the noise will vary as a function of the number of reads.
NPREPARE can help you better understand the raw data by adding a few header keywords. These include GAIN, RDNOISE, SATURATI, NONLINEA, and BIAS which give estimates of the gain (e-/ADU), read noise (e-), saturation level (ADU), the level at which the data start to be non-linear (ADU), and the array bias voltage. These important header keywords are used by other scripts in the NIRI package. NPREPARE refers to a data file named nprepare.dat that contains vital information for adding these header keywords. The user must make sure that the version of NPREPARE and nprepare.dat is appropriate for the data being reduced. nprepare.dat is included with the current release of the NIRI package. nprepare.dat will be modified from time to time to reflect updates in the array parameters or instrument configuration.
Note that the slit centerings are slightly different than before, and we have distributed a modified version of nsappwave.dat to account for a small central wavelength shift.
NPREPARE can also add variance and data quality planes, as described in the help pages for NPREPARE.
Array characteristics
Raw NIRI images are dominated by the landscape of the pixel sensitivity variations. You will notice a number of common features:
- small-scale curved "stripes" running vertically. These result from the manufacture of the array and flatten very nicely.
- a circular pattern of ripples resembling a thumbprint in the upper left quadrant. This will also flatten out.
- three small regions of bad pixels, about 10 pixels across, two of which have a partially bad column below them. These are left over from the procedure that excised "photon-emitting defects" from the array, and are totally dead. Dither patterns should be large enough to guarantee that these pixels can be corrected.
- a few hundred hot pixels, mostly in the upper left corner and in a clump near the bottom center
- a prominent crack in the array substrate, seen as a line of bad pixels in the lower right-hand corner
- an overall large-scale bright region in the center of the array with darker regions top and bottom
- offsets in overall sensitivity at the quadrant boundaries
- correlated noise in groups of 8 pixels is sometimes seen when digital averaging and multiple reads are not used. This is due to the fact that the array is read out in four quadrants with eight output amplifiers per quadrant.
In addition, the array has a frame that can be seen along the top and right edges of the frame, with rounded corners.
Vignetting by the peripheral wavefront sensors
The peripheral wavefront sensors are used for tip-tilt correction and guiding with NIRI. The peripheral wavefront sensor probe arms will vignette the f/6 field of view when the separation from the science target is less than approximately 5.5 arcmin. Sometimes, however, the only or best available guide stars are near this limit and some positions in the dither pattern may be affected. Care must be taken to exclude vignetted images when constructing the sky image if the other unvignetted images are not to be corrupted during sky subtraction.
Recognizing saturation
See Detector properties for a discussion of saturation. Note that no linearity corrections are made to any of the released data. Badly nonlinear pixels are flagged by NPREPARE in the data quality plane.
Dealing with detector problems
As discussed elsewhere, the NIRI detector has several problems/feature and all frames need to be examined and rejected as necessary. Some of these problems can only been seen when successive frames are subtracted. Note, however, that the frames where the four NIRI quadrants have mismatched bias levels and/or vertical striping with a periodicity of 8 pixels (the number of amplifiers reading out each quadrant) are generally reduceable. There is an IRAF task in the Gemini GNIRS package called 'nvnoise' which subtracts a constant from each of the 32 amplifier channels, and seems to work fairly well in removing this noise from imaging data. A more effective python script is also available although not yet incorporated into the official Gemini data reduction packages.
For quality assessment, Gemini astronomers usually exclude the first image of each data set. The first image of each set of flat field images is also excluded. The first image in each set of standard star measurements is NOT typically excluded (although it is not used to generate the sky image) because the short exposures are not badly affected by this problem. There is no measurable change in the photometry in a standard star when the first frame is excluded. The problem is cosmetic and affects the background, not the detected flux
from the star.
Last update 29 October 2007; Andy Stephens & Tom Geballe