Introduction

"Gastro" stands for Global ASTROmetry. It aims at providing an environment for fitting WCS's and geometrical transformations between astronomical images. It heavily relies on the Poloka software.

Gastro does not aim at setting up WCS's of individual images using some reference catalog (this is part of Poloka). Gastro rather uses the input image WCS's to associate measurements of the same object. It then contains several possible uses of these associations :

Establishing a global astrometric solution for a set of images using both the objects in common and a reference catalog. This is typically used prior to stacking. This is what Scamp (from the Astromatix suite) does, with however a slightly different approach.
Establishing transformations from image to image within an image set. This is typically used prior to carrying out simultaneous measurements in the image set, e.g. to measure the lightcurve of a transient, or to measure the ellipticipty of galaxies on a set of exposures without stacking, but with a common position estimation.
Averaging photometric measurements of the same objects, possibly adjusting some parameters describing the photometric response of the instrument. Gastro has been used for this task in the context of the CFHTLS where sets of dithered exposures on dense stellar fields were taken in order to evaluate non-uniformities of he photometric response after flatfielding. In the last version of this task, Gastro has only been used to associate the measurements of the same object, and the associations were written to disk and processed in python.

Stars and lists of stars.

The astronomical objects are presented to the code in the form of std::list's of SomethingStar (which can as well be galaxies). All stars used here derive from BaseStar which contains a point with its errors (FatPoint), and a flux. All the routines that only deal with geometry (such as matching two lists based on spatial proximity) are coded for BaseStarList's and work for anything that derives from BaseStar (as long as BaseStar is the first on the inheritance list).

CcdImage

The input images have to provide measurements of astronomical objects with a position expressed in pixels, together with a WCS read from a fits image header (on an ascii version thereof). Not all WCS types are properly decoded, because we do not rely on the wcslib. The gnomonic WCS's with distortions encoded using the "PV" scheme (what e.g. Scamp produces and swarp reads) are properly handled. Wa also rely on some extra informations form the chip header such as an identifier for the exposure (for multi-chip imagers). In the short term, we are considering adding the support for SIP WCS's.

Associations

The Associations class aims at linking together measurements of the same object from the input catalogs, using spatial proximity on the sky. It relies on WCS's of the input images to convert the pixel-unit coordinates for the input catalogs into sidereal coordinates. Those are then projected on some tangent plane for matching.

The outcome is a set of MeasuredStarList's (one per CcdImage) and a list of common objects (a FittedStarList containing FittedStar s). Each MeasuredStar holds a pointer to a FittedStar, which materializes the association.

Once the associations are made, the FittedStarList is matched to a reference external catalog (the USNO-A2 by default), and the objects on common are put into a a RefStarList. Associated FittedStar's have a RefStar pointer.

Geometrical Transformations

This is implemented in Poloka.

The concept of geometrical transformation mainly refers to applications that transform a point of the plane into a point of the plane. We then have routines that transform images and lists of stars.

The abstract concept was implemented as an abstract class : Gtransfo. The actual implementations that already exist are polynomial transformations of GtransfoPoly, with a set or derived classes (GtransfoLin, GtransfoLinShift, GtransfoLinRot). We have also defined the do-nothing GtransfoIdentity, which is handy in several cases.

On top of providing the transformation, the classes should provide a fitting routine (but not all do...), which uses a collection of pairs of points to be fitted to the model the class implements. These list are called StarMatchList and can be constructed in various ways. Directly from starlists (see below), you can invoque the guessing routines in listmatch.h. There are also higher level wrapping routines in imagematch.h

WCS's are also implemented as Gtransfo's. The gnomonic WCS is implemented as TanPix2RaDec, possibly with distortions. TanRaDec2Pix implements the invers of the undistorted gnomonic WCS.

Astrometric fits

This package proposes two environment for the astrometric fits.

The main program pmfit.cc fits transformations between images that cover the same path in the sky, and the positions of the common objects. It does not use any external reference, but rather fixes one transformation (to the identity) and fits all the other transformations and the positions of the common objects. The result is then a common catalogue in the frame of the image which is compared directly to the common catalogue. This is used to relate positions between a set of images, required e.g. when measuring the lightcurve of a supernova at the same position in all images. This code only uses stars, and tries to identify the ones which are moving, and fits proper motions for those ones.

The other environment ( Astromfit) is meant to carry out more classical simultaneous astrometric fits, in a way similar, but not identical, to Scamp from astromatix. The code is designed in such a way that the AstromFit routines do not have to know any detail of the fitted model. At the moment, there are typically three possible fits:

The same as the one described at the paragraph above, however without the detection of proper motions yet.
An astrometric fit where every CCD has its own transformation to the reference frame (SimplePolyModel). In this setup all CCDs could possibly come from different instruments. The reference frame is provided by an external catalogue, USNO-A by default.
A constrained model (ConstrainedPolyModel) where the transformation for each CCD to the reference frame is the combination of one transformation per chip and one transformation per shoot (to absorb e.g. changes in focus and in refraction). This is of course only meaningful for mosaic cameras.

Environment variables.

Various parts of the code rely (or may depend) on envirnment variables. Here is an incomplete list of those:

USNODIR is where the usno catalog resides (/sps/snls12/usno-a2.0/ at CCIN2P3)
You may as well provide your own catalog on the command line or via an ASCII file pointed to by USNOFILE. The catalog should contain at least 3 columns which are x, y and flux.