General Design

Astronomical instruments come in a variety of forms, each with unique features and requirements that are not readily transferable between different instruments, observatories, and systems. However, there are also many similarities between them, and the data reduction process is often similar regardless of the instrument. The AstroData package is designed to provide a common interface to astronomical data, regardless of the instrument that produced it.

While at first glance this may seem counterintuitive—after all, how can a spectrograph and a camera share the same interface?—breaking down their common features and only developing their unique aspects once has proven to significantly reduce the amount of code required to support each instrument. As an example of such a system, see the Gemini Data Reduction System (DRAGONS), which uses AstroData to support data from all of Gemini’s instruments.

As a developer, AstroData consists of several concepts used to automatically resolve data based on the instrument and observation type:

  1. AstroData - This is the primary class from which all other data classes are derived. It is a container for the data and metadata associated with a single astronomical observation. It is also an iterable object, with each iteration returning a “slice” of the data, which is itself an AstroData object. This is discussed further in Slicing.

  2. Astrodata Tag - These are high-level metadata that describe the observation and link it to the recipes required to process it. They are discussed further in Tags.

  3. Descriptors - These are a way to access the metadata in a uniform manner, and can be used to access quantities reuiring introspection of the data itself.

Thee three concepts are discussed in detail in the following sections. Together, they provide a way to access astronomical data in a uniform manner, regardless of the instrument that produced it, while still being “aware” of any percularities of a given instrument completely controlled by the developer.

Note

Understanding the differences between AstroData objects, AstroData tags, and AstroData descriptors is critical to understanding and implementing to full range of features AstroData provides. One way to think of them is:

1. AstroData manages data and associated metadata, which may include Tags and Descriptors. 2. Tags are high-level metadata descripting the observation, observatory, and instrument, that AstroData uses to automatically resolve how to read in and process a data file. 3. Descriptors are a way to access data not found in the metadata, or requiring some manipulation of the data itself to determine a given value. Like a python property, but without the attribute syntax (to reflect that it may be costly to call).

AstroData was originally designed for the Gemini Observatories, which primarily use the FITS and FITS MEF formats for their data. While AstroData comes out-of-the-box with FITS-specific readers and syntax, extending it to include other file formats is straightforward. See AstroData and Derivatives for more details.

Note

While there is currently only FITS support, we plan to include native asdf support as well in the future.

When using a FITS or FITS-like file, an AstroData object consists of one or more self-contained “extensions” (data and metadata) plus additional data and metadata that is relevant to all the extensions. In many data reduction processes, the same operation will be performed on each extension (e.g., subtracting an overscan region from a CCD frame) and an axiom of AstroData is that iterating over the extensions produces AstroData “slices” which retain knowledge of the top-level data and metadata. Since a slice has one (or more) extensions plus this top-level (meta)data, it too is an AstroData object and, specifically, an instance of the same subclass as its parent.