SSW Keyword/Tag Definitions

S.L.Freeland, Last Rev: 14-October-1999

This document describes a minimal set of keyword definitions which permit application of SSW software tools to existing and new solar data sets. While the definitions are described as FITS Keywords, these are equivilent to the IDL structure tag definitions. Many SSW utilities operate on either FITS files or IDL structures and there are SSW routines which interconvert between the two ( fitshead2struct/.pro and ). One very important implication of this interconvertability is that existing FITS files which do not include one or more of these tags are easily brought into the fold by definition of a function which adds the missing tags or adjusts incorrectly defined tags to the structure interpretation. This type of function is easily written using SSW structure manipulation SW. You do not have to regenerate any FITS files! An additional implication is that there is NO file format imposed or implied by SSW - it is an IDL based system which just happens to have alot of FITS users and includes extensive FITS support utilities. For example, the routine reads multiple 2D FITS files into a vector of IDL header structures and a corresponding 3D data cube which allows vectorized treatment of the large FITS image data bases, simplifies movie making, and offers many other advantages over traditional FITS processing techniques. The routine is available to add or modify "partially conforming" data bases - for example, if any one of a few possible time or pointing standards is present, the others are derived according to the SSW definitions described below and included in the output structures. This facilitates integration of new data bases and maximizes the use of downline software available to the data base.

Use of these suggested standards permit immediate use of many utilities available under SSW including:

Many thanks to Dominic Zarro, Markus Aschwanden, Jean-Pierre Wuelser, Bill Thompson, Craig DeForrest, Richard Schwartz, Mons Morrison, Jeff Newmark, Russ Howard, and other SSW contributors for participating in discussions or providing documentation which led to distillation of these minimal SSW standards. Special thanks to Craig DeForrest for the use of his ztools WWW documentation which was used as the starting point for this document.

Pointing Tags

Details about units and coordinate systems

Tag Status Source Definition
FITS std The width and height of the image, respectively, in pixels.
FITS std The reference pixel coordinates. For example, if alignment is with respect to the lower left corner of the image, CRPIX1 and CRPIX2 should both be set to 1. If alignment is with respect to the center of the image, then CRPIX1 should be set to (NAXIS1+1)/2 and CRPIX2 should be set to (NAXIS2+1)/2

May be zero
FITS std The reference data coordinates corresponding to CRPIX1 and CRPIX2. For example, if the pixel coordinates specify the origin, then set CRVAL1 and CRVAL2 to zero.

FITS std The width and heighth of a pixel in data units, where units are specified by CTYPE1 and CTYPE2, respectively. For square pixels, CTYPE1 = CTYPE2

FITS std
Definition of the data units - ie., the interpretation of CDELT1 and CDELT2. For example, if your telescope has a platescale of 2.6 arcsec per pixel, set CDELT1 to 2.6 and set CTYPE1 to "arcsec".

CROTA Suggested FITS std,
W.Thompson, R.Howard
Rotation angle of the image about the axis perpendicular to the plane of the image.
The rotation is specified in degrees CCW relative to the Y direction. If this field is not specified, it is assumed to be zero.
XCEN Suggested De Facto Solar Convention East-West FOV center of image relative to sun center in CDELT1 units, positive West.
XCEN is related to the above FITS keywords by:
XCEN = CRVAL1 + CDELT1 * [(NAXIS1+1)/2 - CRPIX1 ]
YCEN Suggested De Facto Solar Convention North-South FOV center of image relative to sun center in CDELT2 units, positive North.
YCEN is related to the above FITS keywords by:
YCEN = CRVAL2 + CDELT2 * [(NAXIS2+1)/2 - CRPIX2 ]

Timing tags

Tag Status Source Definition
REQ (*)
W.Thompson, R.Howard The time and date of the start of the observation, in Earth-adjusted UT in a timestamp format recognized by the SSW ANYTIM routine. CCSDS ASCII Calendar Segmented (ISO 8601). Example: 1988-01-18T17:20:43.123Z
FITS Std The duration of the observation, in seconds (floating point). Permits calculation the "mean time" of an observation with the agreed standard for DATE_OBS.
Yohkoh / SOHO
Milliseconds of day (long integer)
Modified Julian Day (long integer). Used in conjunction with TIME to provide efficient binary time representation.
SMM / Yohkoh Integer number of days since 1-1-79 (short integer). Used in conjunction with TIME to provide efficient binary time representation.
FITS std The date on which the observation was made, UT. SSW utilities do not directly use this tag, but its inclusion in headers is suggested for FITS conformability. (To access this tag in an IDL structure, remember to use DATE_d$OBS.)
Common usage The time at which the start of the observation occurred, UT. This tag is not explicitly defined in the FITS standard, but has been adopted into common usage. (To access this tag in an IDL structure, remember to use TIME_d$OBS.)

Auxiliary tags

The following auxiliary tags are suggested for bookeeping and may permit cross referencing ephemeris and other SSW database information.
Tag Status Source Definition
W.Thompson, R.Howard
The name of the telescope, observatory, or mission (string) .
For example,"Yohkoh", "SOHO", "GOES-M", "TRACE". Important for space based observatories which do not have an earth-like view (L1 for example) since transformations will depend on satellite and 'apparent' solar ephemeris.
W.Thompson, R.Howard
The name of the specific instrument (string).
For example, "SXT", "EIT", "SXI-M", "TRACE"
W.Thompson, R.Howard
Wavelength of observation - FITS standard is floating point in nm. Some SSW instruments have chosen to use a string descriptor, particularily for broadband observations

A note about time conversions...

Although DATE_OBS is specified as a required item, it is the definition which is important. The function (by R.A.Schwartz et al), which is included in the SSW generic library, can produce this format from all known time standards used in the solar physics community. The function anytim is the suggested single point time conversion routine for SolarSoft applications. The function is intended to be Y2K compliant as it properly handles all conversions within the range January 1, 1950 through December 31, 2049. There are no time range restrictions for either of the binary formats ( TIME and DAY or TIME and MJD) or for string formats which use the fully qualified (4 digit) year, including the formal definition of DATE_OBS above. Inclusion of one of the binary formats is suggested for efficient downline processing, although the time string to binary conversion using anytim is trivial.


Pointing overview

Pointing registration is accomplished in 2-D by defining a Cartesian coordinate system that lays upon the natural pixel coordinate system of the image. This "unitted" coordinate system is defined by a single datum of correspondence between the two systems, a scale for the unitted system, and a rotation angle.

Pixel coordinates

Pixellized images are assumed to be arranged in horizontal rasters running left to right, which in turn are stacked from bottom to top. X coordinates run left to right and are the fastest-running index; Y coordinates bottom to top and are the slower index.

There is an additional complication: FITS uses a different pixel coordinate system than does IDL. IDL takes (0,0) to be the lower left corner of the image, while FITS takes (1,1) to be the lower left corner.

Each pixel is taken to be centered on the appropriate coordinate: the extreme lower left corner of the lower left pixel is (-0.5,-0.5) in IDL pixel coordinates; or (0.5,0.5) in FITS pixel coordinates. This is important, for example, when keeping track of CRPIXn

Image coordinates

The "unitted" coordinates in the image are themselves the subject of some ambiguity. The SOHO and Yohkoh communities seem to use "Solar" coordinates a lot; these coordinates have the names "solar-x" and "solar-y", and are angular coordinates defined only for small angles away from Sun center, from the vantage point of the Earth.

Images are usually maps of some scalar quantity against 2-D angle; however, from a particular vantage point and for small angles (such as solar images as seen from Earth), they may be converted to maps versus position. The conversion requires knowledge of the observer's position relative to the Sun . This is accomplished with by keeping track of the observer's B-angle ('colatitude'), longitude, and radius from the Sun

Many generic solar SW utilities are available under SSW for things like solar ephemeris, grid overlay, NOAA AR overlay, image co-alignment, solar feature tracking and subfield extraction from full disk data sets, etc. Major contributors in these areas include T. Metcalf, J.P.Wuelser, G.Slater, L.Wang, B.Handy, M.Morrison, C.DeForrest, D.Zarro, W.Thompson, and S.Freeland.

Dominic Zarro has recently developed a powerful, object oriented suite of image mapping, rotation, reprojection, and overlay tools which can interface to solar data sets which provide the pointing information and time references keywords described in this document.

The ztools package by Craig DeForrest provide passing support for some coordinate systems that are not semi-cartesian. In particular, heliographic coordinates and image-plane radial coordinates are supported. Currently, there is no way to specify an image's coordinate system explicitly; Craig has worked around the problem by naming the coordinates themselves. For example, a map of the solar magnetic field in heliographic coordinates would have CTYPE1="degrees-longitude" and CTYPE2="degrees-latitude" instead of merely "degrees". Craig has made a start at implementing a general coordinate-system naming regimen, with the V4 package of IDL routines; if you have a suggestion for how to incorporate coordinate system naming into FITS images, please let him know.



It's important to specify the time at which an observation occured. Unfortunately, the standard ways to do this are complex and have been rendered more complex by some of the historical accidents of FITS interpretation with IDL in the solar community. In addition, the time given in the header is not well defined by either the FITS standard or the SOHO documentation.

Keyword ambiguity

In particular, the FITS standard defines the keyword DATE-OBS to specify the date on which an observation took place; but nothing more precise. Some teams (eg MDI/SOI data specification) use TIME-OBS to specify when an observation took place. The SOHO standard (Howard & Thompson) uses DATE_OBS to store all the time and date information.

There's an additional complication: Because of limitations of the IDL language, there has been an ambiguity between dashes and underscores in the structure returned by So many FITS files exist which have DATE_OBS and DATE-OBS confused. (Newer versions of do not generate the same ambiguity.) So timestamp interpretation is not simple.

Reference Time

There is a problem with the definition of the timestamp tags -- neither the FITS standard nor the SOHO definitions specify the exact time to be given in the DATE_OBS or TIME-OBS tags; the observation is treated as instantaneous. This treatment is not entirely valid in solar physics, as we keep finding temporal variations in the Sun, on the shortest measureable time scales.

The de facto standard for DATE_OBS appears to be to use the start time of the observation. (Some instruments, eg MDI, use the middle of the observation, as that represents a better "mean time" for the observation as a whole; caveat emptor!) For timing critical investigations, where the mean time of the observation is needed, people can use DATE_OBS +EXPTIME/2 as the time of the observations.

The ztools use DATE_OBS for the time of an observation. If DATE_OBS is not found, then many routines try to use DATE-OBS and TIME-OBS.

Time Zones

As instruments get spread around the solar system, speed-of-light effects become important to observation timing. The SOHO standard for the time in the DATE_OBS stamp is "Earth-adjusted UT" -- that is, the UT time at Earth when an observer would have seen the same feature as is pictured.

One should be aware that the solar radius is 2.3 light seconds. This leads to some small temporal effects for spacecraft (such as STEREO) that will subtend significant elongation angles. For low-altitude coronal studies that require less precision than, say 10 seconds this should not be a problem. However, angle-induced timing errors of up to 1 minute will be seen in wide-field spectrographs in other parts of the solar system. If STEREO does indeed include LASCO-type instruments, we will probably need to deal with this.


FITS Standard maintained by the NASA/GSFC Fits Support Office. They are largely compatible with the tags used by the SOHO spacecraft instruments.

FITS Standards Documents

FITS Standard
The "Official" standard is maintained by the NASA/GSFCFits Support Office.
Howard & Thompson
A document dated 19-March-1997 that contains a proposal for SOHO FITS keyword usage.
SOI Keywords
A list of the FITS keywords used by the SOI/MDI SOHO instrument, and brief definitions for each.