Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1556

News	FAQ
Search	Home

Introduction

This document discusses the design and implementation of coordinate systems for images in AIPS++. Loosely speaking, an AIPS++ ``image'' has a regularity which allows that coordinates do not need to be stored with each pixel. In this sense, images differ from the more general data structure, such as that used for uv-data, for which coordinates must be stored for every data element.

Another property of an AIPS++ image is that of interpolability - adjacent pixels are related to one another in such a way that it makes sense to interpolate a value between them. This is not a property possessed by ``IF'', ``polarization'', or ``source id'' axes, which may instead be regarded as multi-valued pixels (polarization), or lists of images (IF, and source id). These may produce regular data structures which are superficially similar to an image, but some part of the ``coordinate'' information would be stored in the descriptor for the pixel values or list elements as the case may be.

In a simple view of a coordinate system, part of an image's regularity may be seen as arising from the data elements, or pixels, being separated by integral multiples of some fundamental increment in each of its N axes. This is the model adopted by FITS; each axis of an N-dimensional image has a coordinate reference pixel, the coordinate value at that pixel, and a coordinate increment. An additional parameter may also be used to describe a rotation of coordinates although this is not rigorously defined. In this model, non-orthogonal pairs of coordinate axes, such as right ascension and declination in a polar projection, are treated as special instances of the simple case.

However, the FITS view of coordinate systems sits uncomfortably with non-linear coordinates in 1-dimension, such as might arise from frequency-velocity axes, logarithmic axes, and so on. The, difficulties are compounded by pairs, triples, or higher aggregations of dependent axes, as might arise from most conventional map projections of celestial coordinates. In fact, the FITS methodology cannot handle a general linear transformation of a set of ``orthogonal'' linear axes.

It is worth discussing the various shades of intergradation between what is considered to be a regular image, and the general data structure characterized by uv data.

• At the simplest level we may have a collection of pixels which, by virtue of the way they are organized, and the nature of the coordinate system itself, does not need coordinates to be stored with each pixel.

  It is possible for a regular N-dimensional array of numbers to have this property, and this forms the conventional view of a regular image. Since the individual pixels are addressable by pixel coordinates, that is, integral array indices (p₁, p₂,...), the only other requirement is a pre-defined algorithm for converting these to image coordinates (i₁, i₂,...).

  Run-length lists also allow integral indexing, although via a somewhat more complicated mechanism. Instances of these can also fall into this simple category.

• Consideration of what actually constitutes the algorithm for computing $\bf I$ = (i₁, i₂,...) from $\bf P$ = (p₁, p₂,...) leads us to a higher level of abstraction. Let us write the mapping function, f (), as

  $$\bf I \bf P$$ (1)

  where $\bf I$, and $\bf P$ are vector quantities. In the simple case where f () is completely separable we may write

  (i₁, i₂,...) = (f₁(p₁), f₂(p₂),...). (2)

  This is the mathematical condition for what is usually referred to as ``orthogonal'' or ``rectilinear'' coordinates. However, the term ``separable'' is more mathematically meaningful. Separability is at the heart of the FITS coordinate model, celestial coordinates and linear transformations being an addition to it. FITS also assumes that the functions f₁(), f₂(), etc. can be expressed as linear equations involving a few coefficients, although presumably it could be extended to include the notion of logarithmic, inverse, or other non-linear coordinate axes.

  However, suppose that some or all of the functions f₁(), f₂(),... could not be expressed in mathematical form, but instead could only be defined in terms of a table lookup. In terms of an AIPS++ image it is still not necessary to store image coordinates with every pixel, although rather more storage is required to define the mapping function.

  FITS currently solves this problem by the use of random parameters.

• Taking the previous example to its logical conclusion we must consider the case where the mapping function is not separable, and is expressible only as a lookup table. In the completely degenerate case where table entries are required for each pixel, we arrive at the most general structure where coordinates are stored with each pixel. (It may, however, still be meaningful to talk of such an image as being regular if, for example, adjacent pixels are not independent of each other, that is, if it makes sense to interpolate them. However, this is a fine point which is outside the scope of the present discussion.)

Between these extremes there exists a wide range of possibilities in which the mapping function may be partly separable, and need be expressible only partly via lookup tables.