Chapter 3
The Lucky Imaging Data Reduction Pipeline

3.1 The Lucky Imaging Process

The standard Lucky Imaging process, used to reduce almost all LuckyCam data, proceeds as follows:

1. Determine the quality for each frame on the basis of the guide star’s Strehl ratio.
2. Determine the shift for each frame that aligns the brightest speckles.
3. Sort the frames according to quality.
4. Align and co-add the best frames using the Drizzle algorithm (section 3.5.4).

The algorithm which determines the quality and alignment vector of each frame can be altered according to the science programme and the prevailing conditions.

3.1.1 Frame selection

The standard Lucky Imaging pipeline described in this chapter selects frames on the basis of the degree of correlation to a diffraction-limited PSF. This produces very similar results to selecting on the basis of Strehl ratio (the ratio of the peak flux to that expected in a diffraction-limited core), but blurs the input PSFs to match the telescope’s maximum resolution, increasing the SNR of the peak amplitude determination.

This procedure selects the frames with the best light concentration – that is, the frames with the largest fraction of the flux within the diffraction-limited core. It thus produces images with a maximised output on-axis Strehl ratio.

However, some science programmes benefit from different frame selection strategies. If there is a requirement for a wide field of view (i.e. a smaller drop-off in resolution with distance from the guide star), two or more guide stars can be used. Frames can then be selected on the basis of both the correlation between the two guide star PSFs and their light concentration, biasing the frame selection towards the periods with the largest isoplanatic patches.

As another example, if there is a faint close companion to a bright star, the PSFs which have less light from the bright star in the position of the companion can be selected (similar to the Dark Speckles method, Boccaletti et al. (1998)). These asymmetrical PSFs can be detected either by searching for a lack of light in the companion position or (to avoid biasing the selection towards periods where photon statistics reduce the light from the companion) an excess of light elsewhere. I performed some very preliminary experiments on this method, and found that the background within 1 arcsec from the guide star could be reduced by approximately a factor of two, although the Strehl ratio of the faint companion was also reduced because the poorer more asymmetric frames were preferentially selected.

The method of frame quality cutoff can also be varied. In the standard LuckyCam reductions only the frames which meet some quality criterion are included. This can be generalised to including all frames, but each weighted by some quality criterion. Tubbs (2004) investigated weighting frames on the basis of both Strehl ratio and the fraction of power in high frequencies, but found that the final output image was not improved in resolution from the simple cutoff method.

3.1.2 Image alignment

The standard data reduction system described below aligns frames on the basis of the peak position of the brightest speckle, ensuring that the maximum possible light is included in the center of the guide star image.

This approach can lead to problems with faint guide stars, where photon noise becomes important and the measured peak position is actually just the position of the brightest L3CCD photon event in the star PSF (see chapter 5). The Lucky Imaging reduction system described below has the capability to add frames together to increase the SNR sufficiently to obtain the true position of the brightest speckle, at the cost of time resolution.

An alternate approach is to align using the PSF centroid position, which can be measured with high SNR on PSFs containing far fewer photons than the brightest-speckle method (which relies only on the 10-20% of the PSF photons within the diffraction-limited core).

Christou (1991) gives a comparison of the centroid-centering vs. brightest speckle centering approaches using simulated near-infrared 8m telescope data, and finds that the brightest speckle method has significantly better performance.

On LuckyCam data, the centroiding approach does indeed recover resolution in cases where the guide star is too faint for Lucky Imaging; its use is demonstrated with one of the VLM binaries in chapter 7, where the I=~+12m target was observed though ~5 magnitudes of cloud cover. However, if the short exposure PSF is even slightly asymmetric (as most individual speckle patterns are; see the speckle patterns in chapter 1) the centroid position does not match that of the diffraction-limited core of the PSF (figure 3.1).

In that case, the final added image contains many separate diffraction-limited cores distributed over an area set by the differences between the centroid and peak positions. The distribution is often much larger than the diffraction-limited core size (figure 3.2). The (low-Strehl-ratio) diffraction limited core that would be recovered by the brightest-speckle method is therefore not present. For that reason, almost all LuckyCam reductions presented in this thesis are performed aligning on the brightest speckle.

3.2 Pipeline Implementation

The pipeline consists of a collection of C++ programs which are run sequentially on an observation run, and is implemented using the GCC V3.4 C++ compiler operating in Linux. I chose to implement the pipeline in C++ for two reasons:

Speed. Reduction of LuckyCam data requires high-speed data analysis. A typical observing run produces 1TB+ of data, which must be reduced in a timely fashion. In practise this involves processing the data at speeds comparable to its acquisition – i.e. megabytes per second. A relatively low-level language such as C++ gives the speed and flexibility required for this.

Flexibility and Code Reuse. C++ offers object-orientated features that significantly speed up the development process. For example, each program in the pipeline must load, save and manipulate images in a variety of formats. By implementing a C++ image class, I shared all the relevant code between the different pipeline programs. Although this could be performed in C (for example) by sharing source files, the encapsulation of all the relevant image data (memory storage, dimensions, etc.) and functions in a single object very significantly reduced the complexity of the final code.

As a second example of the use of objects, all stages of the processing within LUCKY, the final Lucky Imaging process portion of the pipeline, are implemented as classes and can thus be easily swapped for objects which offer the same interfaces. This allows very easy modification of the pipeline process, with the guarantee that (as long as the class interface specifications are followed) modifications to one part of the process will not affect the rest. In particular, the frame selection and alignment algorithms are implemented as a set of virtual classes, where only the interface is specified to other parts of the program. The initial processing and final image construction code can then remain completely agnostic as to the details of the frame selection processes, allowing very easy experimentation with different Lucky Imaging methods.

All the pipeline programs can be run manually, but are more usually scripted to run on a collection of observations by a pre-processing program, LSCRIPT. An overview of the pipeline reduction process is shown in figure 3.3. I discuss each component of the pipeline in detail below, in order of execution during processing.

3.3 LSCRIPT

LSCRIPT scripts the data processing sequence. In fully automatic mode it searches for LuckyCamruns on a data disk and picks suitable reference stars, background areas and bias generation areas automatically (figure 3.4). The program then creates a well-organised output directory structure including the relevant settings files for CLEANUP and LUCKY. Finally, a shell script is produced to schedule all the reductions, which the user can then run at their convenience.

3.4 CLEANUP & BIASGEN

Because the camera electronics must operate at very fast frame rates, some trade-offs between speed and image quality must made. The CLEANUP section of the pipeline is responsible for removing artifacts introduced to the raw data by the camera electronics. In general the 2002-2004 camera suffered from greater artifact problems than the 2005 camera; the artifact removal systems are, however, applicable to both cameras.

(a) Raw camera output   (b) Post-cleanup Figure 3.5: A single LuckyCam frame from June 2005, of a binary star before and after CLEANUP processing. The speckles in the background are individual photons from the sky (and some spurious events).

CLEANUP detects and removes the following artifacts, listed here in rough order of importance. An example before-and-after comparison is shown in figure 3.5.

• Row-to-row bias variations The bias level of individual rows is defined by the camera electronics on the basis of the average level in the dark pixels on the left side of the row. A spurious event within that area leads to the bias level of the entire row being set incorrectly. Low frequency noise also affects the bias levels of groups of rows. I remove these problems by resetting the bias level of each row such that the lowest 5th percentile of all data values within that row is set to zero. Using the 5 per cent level rather than a simple average ensures that only pixels which do not contain photon events are used.
• Horizontal Slope The images often have a slowly-varying horizontal slope in bias level. I model and then subtract this slope with a cubic fit to the 5th percentile levels in each column.
• Pattern noise The 2002-2004 camera experienced high levels of pattern noise with a wavelength of 2 pixels. The phase of the pattern was very consistent within each row, and so the pattern noise was removed by simply clipping out the pattern noise’s peak in the Fourier transform of the row. Bright objects within the row can lead to an overestimation of the noise because they contribution high-frequency signal. To avoid an incorrect noise subtraction, they are thus masked out during the pattern noise removal.

For each run, CLEANUP loops though the input frames written during data acquisition and stores cleaned frames onto a fast RAID-0 array in the data reduction computer. This second storage step allows subsequent reprocessing of the data without re-cleaning of the input frames and re-loading from the relatively slow USB external hard disk used for initial data storage. Since several later data reduction stages (determination of the run gain, for example) require reprocessing of the cleaned data this intermediate storage gives a very significant time saving over the course of the reduction process. CLEANUP by default writes compressed files, in the same format used by PixCel LC, saving significant storage space and increasing the (often hard-disk-limited) speed of the pipeline processing.

The 2005 camera introduced an extra effect, a different bias level for each column. The effect, at the 2-5DN/pixel/frame level, is too faint to be visible on individual images, but appears as strong vertical lines on summed images. Because the column bias levels can only be measured accurately on summed post-CLEANUP images, I introduced an additional step into the pipeline to measure and subtract them.

BIASGEN generates a bias image that contains the values of the vertical lines introduced by the camera hardware into the images. The user (or LSCRIPT) selects a set of rows which are relatively clear of stars. The average value in each column is then determined from a large (>1000) number of frames. The average is constructed from twice-iterated 1σ clipped values to remove any faint stars within the given areas. Because the lines have no vertical structure, the measured values can then be applied to the entire image.

The column bias estimates are subtracted from each frame in subsequent processing by LUCKY and other programs. Because the vertical line structure changes slowly, the bias estimates are regenerated every run or 10,000 frames, whichever is the shortest.

3.5 LUCKY

The LUCKY section of the pipeline performs the actual Lucky Imaging processing. Briefly, input files are calibrated, the quality of each frame is determined and the highest-quality frames are then aligned and added together into a set of high-resolution output images. The full processing performed by LUCKY is detailed in figure 3.6 and the major components described in detail below.

3.5.1 Setup

Reduction settings and the parameters of the input run are read in from a text file (for an example, see figure 3.7) written by the user or generated by LSCRIPT. The file gives details of the data (location and camera/telescope properties during acquisition), the regions to be used for the guide star and background and a large number of processing options.

3.5.2 Initial processing

Reduced images are prepared in two steps, first the determination of the quality of the frames and then the construction of the high-resolution images. The two step process is required to derive the relative quality statistics for different sections of the individual runs, before the final image reconstruction. A realtime lucky Imaging system does not have this luxury, and must decide on the quality of a frame solely on the basis of past frames. For an example of this style of processing, see chapter 2.

To save memory for the first reduction stage only the PSF of the guide star is extracted from each frame, after the frames have have been debiased and flat-fielded. Each PSF is checked for saturation and calibrated to a zero background level by subtracting the average flux in the selected background regions, before the set of PSFs is passed to the next stage:

3.5.3 Frame quality and shift-lock determination

There are two standard versions of Lucky Imaging currently implemented within the LUCKY framework. The standard Lucky Imaging system (labelled “Strehls” in LUCKY), in its simplest form, selects frames on the basis of the amount of light within the brightest pixel of its input image (equivalent to selecting on the brightest speckle), and aligns the image shift onto that pixel. Frames with the greatest concentration of light have the highest quality; this selection corresponds to selecting the frames with the best Strehl ratio.

Two main options are available to increase the quality of the processing, both of which are enabled in almost all circumstances (except when accurate photometry of the guide star is required; see chapter 5).

1. Resampling. The PSF images are bicubically interpolated to 4× the original size, allowing sub-pixel determination of the best shift position from the brightest pixel in the resultant resampled image. This sub-pixel value is then used by the image reconstruction system.
2. Convolution / Correlation. After resampling, the PSFs are convolved with a diffraction-limited PSF, matched to the observation’s telescope size, pixel scale and effective wavelength. The brightest pixel in the image then corresponds to the position that best matches a diffraction-limited PSF, and its value gives the degree of correlation. This procedure effectively blurs the images down to the maximum resolution of the telescope, increasing the signal-to-noise in each pixel without losing real spatial information, and thus improves the quality of image reconstruction for fainter guide stars.

The second Lucky Imaging technique implemented in LUCKY is Signal-to-Noise Tracking Lucky (SNT Lucky). This proceeds in exactly the same way as the standard method described above, except that the signal-to-noise of the frame quality and shift position determination is tracked. If the guide star flux is too low for an accurate determination of those quantities, adjacent frames are added together until the signal-to-noise becomes sufficient; effectively, the frame rate is adjusted according to the prevailing seeing conditions.

This is particularly important for the faintest guide stars. There is a very sharp drop-off in the accuracy of frame shift-position determination when the number of photons in the PSF core drops to less than 1 photon per pixel. In that regime, the frame selection system is likely to lock onto the more numerous random photons in the star halo rather than those in the core. Although the SNT Lucky reduction of the effective frame rate does reduce the quality of the Lucky Imaging, very faint guide stars benefit greatly from increasing the amount of light within the core of the star to several photons per pixel. For this reason, SNT Lucky is the default approach for the reduction of images with faint guide stars.

Variable cloud cover can also cause the light in the brightest pixel to change, possibly corrupting the frame selection process. I describe methods to minimise this problem in section 3.5.5.

3.5.4 Final high-resolution image reconstruction

The above processing produces a list of frame qualities and shift positions. As a final step, the frames are sorted according to quality, then shifted and co-added using the Drizzle algorithm (figure 3.8), starting with the best quality frame. The addition continues until a user-specified selection level (such as the best 5% of frames) is reached, upon which an output image is written (unless there remain more inclusive selection levels to be made).

If the images were simply interpolated by the non-integer pixel shifts and added, each input pixel would be reduced in resolution. To see this, consider a frame to be shifted by 1/2 of a pixel horizontally and vertically. Each pixel of the image is then spread equally over 4 pixels of the output image – thus reducing the output resolution (top panels of figure 3.9). However, more complicated algorithms can avoid much of this resolution loss, essentially by reducing the size of the input pixel relative to those of the output image.

Earlier Lucky Imaging software Tubbs et al. (2002, 2003) used filtered sinc-resampling to increase the image resolution before image shifting. This worked well for the technical trials in which it was used, but introduces ringing in the output data and an unphysical “texture” in the background. I compare the output of this algorithm to several others in figure 3.9.

For all images presented in this thesis I elected to co-add the images using a custom implementation of the DRIZZLE algorithm (Fruchter & Hook, 2002), which offers the resolution achieved by the sinc-resampling methods without any associated ringing.

Drizzle proceeds by “drizzling” the input pixels onto a larger grid, generally 2× the size of the input pixel grid (figure 3.8). This process can also be represented by making each input pixel decrease in size (but not separation) by a factor of two before addition. At each stage of the addition both the output image and a weight map for each pixel is updated.

Each input pixel is dropped onto an area of the output grid that usually overlaps several pixels. If the fractional area of overlap with a single output pixel is represented by F the signal S(x,y) and weights W(x, y) of that pixel are updated to be:

(3.1)

(3.2)

where S′ and W′ denote the current signals and weights, S_input is the signal from the input pixel, and W_P (x, y) are individual pixel weights for the current frame that can be used to remove (for example) cosmic ray affected areas.

This operation corresponds to making a weighted average of the input pixel values in each output pixel. After each frame addition S(x,y) contains an estimate of the final high-resolution image, which is used directly as the LUCKY output image.

3.5.5 Further processing

Full data reduction of a run with LUCKY often involves several further processing steps to improve and/or calibrate the quality of the final output. The most important options are detailed in the following sections.

Autoguider simulation

In parallel with the Lucky Imaging reconstruction, the user can also elect to simulate a standard telescope autoguider system. Telescope autoguiders are designed to remove the telescope motion produced by incorrect tracking and other long-timescale (longer than 1 sec) effects. LuckyCam samples images at a high enough rate to allow full simulations of the commands an image motions that would be produced by an autoguider guiding on a bright star within the LuckyCam FOV.

(a) No autoguider   (b) Simulated autoguider Figure 3.10: The effect of the simulated autoguider. The seeing here is ~1.0 arcsec FWHM, and the images have a vertical dimension of 9 arcsec. The left panel shows a simple sum of the recorded frames (targeted on a section of the core of the globular cluster M3), with the NOT autoguider turned off. The right panel shows the same data with much reduced image elongation after processing with a simulated NOT autoguider.

During LuckyCam observations at the NOT the autoguider system is disabled (to avoid introducing extra image motion) so a simple addition of frames in a run usually produces very elongated images that do not give a true estimate of the natural seeing. A direct simulation of a standard autoguided telescope imaging system from the LuckyCam data allows a simultaneous comparison of LuckyCam performance with that of the standard imaging system. The often very rapidly changing seeing conditions necessitate a simultaneous comparison of LuckyCam with other imaging systems, to ensure the same level of turbulence is being measured for each system (see chapter 4).

LUCKY simulates the Nordic Optical Telescope autoguider system. The system samples at 12.5 frames per second, and can thus be adequately simulated by LuckyCam at all frame rates (in all observing runs, LuckyCam has run at a minimum of 12 frames per second). The autoguider tracks the centroid motion of a bright star, starts to send correction commands when the star’s offset from the current position is > 0.1 arcsec, and corrects at a maximum rate of 0.2 arcsec per sec. The commands from the autoguider system are smoothed by a low-pass filter with a 1-sec time constant (Graham Cox, private communication).

For simulation of the autoguider system in LUCKY, the PSF centroids are tracked during initial processing, and the simulation of the autoguider is performed as the final part of the initial processing. An additional output image is then constructed by Drizzle, using the simulated autoguider image shift commands instead of the Lucky-derived shift positions.

The seeing values derived from FWHM measurements of the simulated image match those derived simultaneously from on-site RoboDIMM (O’Mahony, 2003) measurements. However, a real telescope does not respond instantly to the autoguider commands, and may not be capable of tracking at 100 milli-arcsec resolution. The simulated system thus corresponds to an idealised autoguider.

Cosmic ray removal

Cosmic rays appear on LuckyCam images as isolated “splashes” of saturated pixels 3-5 pixels high and 4-7 pixels long. These are important to remove from (or at least detect in) LuckyCam images, because if a cosmic ray falls inside a guide star box it could be mistaken for a very high quality frame. The frame would then be shifted in the output image such that the cosmic ray appears at the nominal guide star position while the guide star itself appears somewhere nearby – where it could, for example, be mistaken for a faint companion star.

LUCKY detects cosmic rays by searching for very high-valued pixels in each frame. If a cosmic ray falls within a guide star box, the frame is not used for imaging. Otherwise, the drizzle weights of the cosmic ray pixels are set to zero, along with the surrounding eight pixels to eliminate the effects of charge leakage from the saturated pixel. Cosmic-ray removal can be very vigorous with LuckyCam data, because each output pixel is the weighted sum of at least tens of input frames, and cosmic rays are only likely to affect one to two of those frames.

Cloud protection

The standard Lucky Imaging methods described above assume no clouds are present. Clouds cause the total flux from the guide star to vary rapidly and unpredictably (figure 3.11). The naïve quality-from-brightest-pixel approach is then vulnerable to selecting frames with the highest transmission rather than the highest quality. I implemented two sequential cloud detection and protection measures, to be enabled when reducing suspected cloud-affected data.

1. Each PSF is divided by its total flux, for a normalised estimate of the frame quality. This works well for thin clouds, but thicker clouds can occasionally reduce the flux from the star sufficiently to leave only a few single photon events. Under this scheme they appear to have superb light concentration, with most of the flux from the star concentrated into a single pixel, which can lead to preferential selection of the worst frames.
2. If the cloud transmission is very variable and drops to very low values, for the above reason the frames with the thickest clouds must be dropped. The total flux in each PSF is tracked, and if frame dropping is enabled those frames with less than half the maximum total flux are removed from the selection process. The remaining frame qualities are then normalised as point 1 above.

Although some frames may have to be dropped, these methods allowed full performance Lucky Imaging even under the very cloudy conditions of the November 2005 LuckyCam run, where most observations were performed though at least three magnitudes of (rapidly varying) cloud cover.

Binary de-tripling

In standard LUCKY processing guide stars are selected in boxes based on the initial seeing-limited summed data. These boxes must be sufficiently large to include all apparent image motion of the guide star. For this reason, close companions to the guide star (unresolved by seeing-limited instruments) may also fall within the guide star region. If the close companion is of roughly equal brightness to the guide star, photon statistics will cause the “brightest speckle” to randomly shift between the two stars. In some frames that are added to the high-resolution output image, the companion will thus appear in the position of the actual guide star, and the guide star will appear as a second companion displaced in the opposite direction to the true companion (figure 3.12, left panel).

The binary system will thus appear to be a very improbable-looking triple star system arranged into an exact line. This case is easy to detect by eye, and resolved photometry for the guide star and companion can be calculated from the resolved flux from the three apparent stars (see chapter 5). However, this effect must be removed to produce convincing images of these binary systems.

The LUCKY de-triple option adds an extra stage to the guide star selection for use on guide stars with close companions. After an initial coarse (standard) guide star box has been drawn, a new intermediate-resolution image is made by aligning the brightest pixel of the guide star PSF in each frame. This produces an image that allows separation of the binary system’s components, which is presented to the user. The guide star box is then drawn around one of the components, and all frame selection and alignment proceeds in that box, which is moved relative to each frame’s initial shift position. Image motion is thus removed during the frame selection process, and only light from the selected component is used for the guide star.

Example results of this procedure are shown in figure 3.12. The algorithm works well for binary separations down to 0.2 arcsecs. Below this value, the diffraction-limited cores of the binary components merge, and further processing is required to confirm the binary system (see the speckle imaging sections of chapter 5).

(a) Standard Lucky Imaging   (b) De-tripling enabled Figure 3.12: Detripling the 0.33 arcsec binary LSPM J0503+2122. The left image shows the result of standard Lucky Imaging with a guide star box including both stars (the binary is unresolved in a seeing limited image). The right side shows the result of guiding on the upper component, with a small guide star box that moves with the brightest pixel in the PSF.

3.6 Summary

• The standard Lucky Imaging process is: 1/ Determine the quality of frames on the basis of Strehl Ratio; 2/ Align frames on the position which best correlates with a diffraction-limited PSF; 3/ Select the best frames, then align and sum them using the Drizzle algorithm.
• Other Lucky Imaging algorithms are possible; the above algorithm gives very good performance in most situations but some more specialised methods are of use in particular cases.
• I have implemented a Lucky Imaging data reduction pipeline, to automatically reduce entire nights of frame data to sets of high-resolution Lucky images.
• The pipeline automatically picks guide stars, cleans the input frames of camera artifacts, and processes them for Lucky Imaging.
• The Lucky Imaging section of the pipeline, as well as implementing the above methods, has many options to improve the quality of the output image under a variety of conditions.