[fitsbits] WCS for HEALpix and HTM data.

[Mark Calabretta]

On Wed 2003/05/07 16:37:18 -0400, Tom McGlynn wrote
in a message to: fitsbits at donar.cv.nrao.edu

>One thing that has come up recently in a couple of contexts
>is dealing with image data that is stored using a pixelization
>that is not the standard rectangular grid.  The HEALPix format
>is very popular for images in the CMB community while HTM is being used
>for a lot of very large catalog data and one can easily imagine
>HTM images.
>
>Has anyone begun working on WCS specifications for these?  The
>underlying pixelizations are inherently 1-dimensional, but I
>can imagine something like:

Tom,

Pixelations don't come within the ambit of FITS WCS for the reasons
explained in Sect. 5.6 of WCS Paper II (A&A 2002, 395, 1077).
Basically, it's because they define a distribution of points on the
sphere, not a mapping of the sphere onto an image plane (plane of
projection).  Hence, in order to "display" a pixelation a map
projection must be defined separately.

In other words, pixelations differ fundamentally from the projected
images that FITS WCS deals with.  In the former, you have a set of
points which are pretty-nearly equispaced over the surface of the
sphere and are free to do with them what you please.  In the latter,
you effectively have the end-result of projecting an awkward
distribution of points on the sphere onto a plane in such a way that
they ended up on a square grid.

>NAXIS    = 2
>NAXIS1   = NumberOfPixels used
>NAXIS2   = 1
>
>CRVAL1   = 0.    // Reference pixel at center of coordinates (like CAR or AIT)
>CRVAL2   = 0.
>
>CDELT1   = Only certain discrete values are valid here depending
>            on how finely the sphere has been divided.
>CDELT2   = Same as CDELT1 (or just ignored)
>
>CRTYP1   = RA---HTM (or RA---HPX)
>CRTYP2   = DEC--HTM "
>
>CRPIX1   = The pixelizations give pixels over the entire sky as a linear 
stream.
>            If only part of the sky is given, then CRPIX1 gives the offset of the
>            first pixel that the user is including.
>CRPIX2   = 1  // Not used.

Use of these image-oriented keywords would be inappropriate for a
pixelation.

>This will not be trivial for display programs,

Again, in order to "display" the pixelation a spherical projection must
be defined explicitly.  The representations shown on the HEALPix homepage
(http://www.eso.org/science/healpix/) appear to use an orthographic
projection but in principle anything could be used.

> becuase the region of the sky that
>is included when something less than a whose sky image is given will never be
>rectangular and may not even be contiguous.  I've not been a subscriber to the
>WCS mailing list.  Has there been discussion there?

Note the significant difference between a pixelation and Max Tegmark's
icosohedral projection.  While the latter is severely non-contiguous
it could in principle be "displayed" because it exists on the plane.
However, FITS WCS does not support it because it uses an hexagonal
close-packed arrangement of pixels (so-called "non-square pixels") and
such data storage is not defined for FITS images.  To display such an
image an interpolation function would also have to be defined to map
the hexagonally arranged pixels onto the square (Cartesian) arrangement
used by all display devices (that I know of).

Having said that, because of their regularity, it should be possible to
devise a method of assigning coordinates to the pixels of a pixelation
without having to specify the coordinates of each individual pixel.
This might be done to save storage but no such scheme should use the
CRPIXj, CDELTi, CRVALi, or CTYPEi keywords.  If a standard storage
sequence is defined for each order of the pixelation, and the whole
sphere is recorded, then only four parameters are needed: the order
of the pixelation (determines the total number of pixels and their
distribution), plus three Euler angles to define the orientation of
the pixelation's "native coordinate system" with respect to the
spherical coordinate system of interest.  Sub-imaging, however, is
more complicated and would require a more elaborate scheme.

Mark Calabretta
ATNF