User's Guide to the DEBRIS Package

1. Introduction

This guide provides a description of the procedures involved in detecting geostationary/geosynchronous orbital debris using an untracked observation method. It is a general outline of how data is acquired and how it is subsequently analyzed using the tasks of the DEBRIS package. A detailed description of the individual tasks can be found in the help documentation of the package.

2. The Method

In order to observe geostationary objects there are two obvious methods:
Tracking
If the telescope drives are on during the observations then of course all geostationary objects will appear as straight lines in the east-west direction. This means that the already faint objects get blurred out over many pixels, making them even harder to detect.

Untracked
However, if the telescope drives are switched off during the observations then all truly geostationary objects would appear as point sources. Unfortunately, orbital debris cannot be assumed to be truly geostationary due to changes in the orbit's inclination and ellipticity. Therefore it must be assumed to change both its HA and DEC. Although this motion is comparatively small it is obvious that this poses a limit on the exposure time if one keeps in mind that the whole purpose of this observing method is to keep the object if possible in one pixel.

The DEBRIS package was designed as a facility to analyze data acquired using the untracked method. The idea is to compensate for the above mentioned limit on the exposure time by taking a whole stack of frames and combining them later thus making objects visible that were undetectable in a single image. The following will identify the two major problems with this idea:

- Since the observer has no idea how fast and in what direction a particular piece of debris is moving it is impossible to observe this piece in the same pixel in every image of the series.

- Even if the first problem was somehow solved how can a detection program (we are interested in an automated search algorithm!) distinguish between a star and orbital debris ? (The roundness parameters of the DAOFIND task alone are not enough.)

The first problem is unsolvable. One has to live with it. This means that the telescope stays fixed with all drives switched off for the entire series of observations. Before combining the images then they will be shifted with respect to each other in many different trial directions and at many different trial "speeds" in an attempt to simulate the motion of a particular object and to bring all its light into a single pixel. At the end of this one is left with very many combined images to be searched. A particular object will only appear in very few (one or two) of these images, namely the ones which simulate its motion best.

The second problem can be dealt with in a more elegant manor simply by using an appropriate rejection algorithm when combining the images. In this way one can achieve that the stars disappear almost altogether. So the problem of how to distinguish between stars and orbital debris does not pose itself in the first place.

3. The Data

As described above, the input to the DEBRIS package consists basically of a stack of images that were taken with all telescope drives switched off. The best results are expected from observations close to 0 degrees declination. It is important to note that all images should have the same exposure time and must be equally spaced in time. All image reduction should be performed before entering an analysis, i.e. the images should be biassubtracted, corrected for dark current, flat fielded and if necessary illumination corrected. (See demonstration image demo1.) At present, the images should also have a particular orientation: north <--> left, east <--> up, south <--> right, west <--> down. The images do not have to be oriented in this way but it makes life a lot easier if they are.

4. The Analysis

The first step is the shifting and combining of the images. This is performed by the task DEBMV. The shifting for a particular image is performed according to three parameters which represent a trial motion. The output consists of the combined images (see image demo4) and various logfiles. The logfiles will be used at later stages of the analysis and should not be deleted or tampered with light heartedly. The same goes for file names: The DEBRIS package uses easy to understand naming conventions for image-, log- and coordinate-files. In this way a task will automatically find the files it needs without having to bother the user. DO NOT rename files unless you know exactly what you are doing.

The second step is the detection of orbital debris. The task DEBFIND scans the output images of DEBMV for local intensity maxima using the task DAOFIND in the APPHOTX package. Remember that stars have mostly been removed from the image yet residuals may still lead to unwanted detections. In many cases however these can be eliminated by using the roundness parameters of DAOFIND. The output of this step consists of one coordinate file per input image. Most of these will be empty (except for the header). Since there are a great number of coordinate files it would be a tedious task to check these files for detections one by one.

The third step is therefore the reporting of the results by DEBREPORT. This task reports in which images objects have been found, the magnitude of the objects and in how many "neighbours" a particular object was found. A "neighbour" of an image is an image with neighbouring shifting parameters. This quickly shows the user whether detections in two different images refer to the same object or not. It is also some sort of measure of the reliability of a detection.

4.1 DEBMV and DEBFIND vs DEBMVF

The task DEBMVF is a combination of the tasks DEBMV and DEBFIND. It serves exactly the same purpose but there is an important difference in the order in which the steps are executed. If DEBMV and DEBFIND are used for an analysis then first all images are created and then they are searched. This is impractical since it requires a large amount of available memory. Instead, DEBMVF searches every image right after its creation and is then free to delete the image if the user so wishes. So the actual analysis is best performed using DEBMVF deleting every image after it has been searched. Any image can be created again at any time using the information in the logfiles; if one wishes to create an image again just for the purpose of examination DEBMV should be used. DEBFIND is best used for searching images repeatedly with different parameter settings.

Throughout all documentation on the DEBRIS package almost all references to the DEBMV and DEBFIND tasks apply equally to the DEBMVF task.

5. Summary

The "course of action": The stack of input images are shifted with respect to each other in order to simulate the movement of a supposed piece of orbital debris. Then the images are combined using a rejection algorithm so that stars disappear. The combined images are searched for remaining brightness maxima and the result is reported in a manageable fashion.

Detailed descriptions of the individual procedures can be found in the respective help pages. Additionally, the help pages of the tasks IMCOMBINE and DAOFIND provide detailed information on the rejection and detection algorithms employed.


Back to The DEBRIS Page.
Joe Liske Imprint