Subject: The Registration of Time Bins in FITS Files

From: Arnold Rots <arots at xebec.gsfc.nasa.gov>
Date: Thu, 14 Jul 1994 15:35:18 -0400

Relating Pixel Coordinates (Counting Indices) to Physical Coordinates
=====================================================================

The Proposed FITS Convention
----------------------------

The NOST Standards document, in its section on the proposed
conventions regarding World Coordinate Systems, states, correctly,
that the common convention in FITS, and the one put forward by Greisen
and Calabretta, is to regard the counting index (integer pixel
coordinate) as referring to the center of each pixel.  Though this
deviates from practices common in other fields, it is felt that such a
convention is the most intuitive in an astronomical context.  No
explanation is given, but the observation is, in our view, correct.

Since there is no formal standard, though, the document encourages
FITS writers to document the convention that is used in embedded
comments.

The Problem
-----------

As stated above, we consider the observation that astronomers
naturally refer to the center (rather than the edge) of a pixel as the
point that coordinates refer to as correct and justified.  However,
there is one glaring exception to this rule: the time coordinate.

When velocity bins, frequency bins, or spatial bins are tagged with a
coordinate value, that value does usually refer to the center of that
bin, but when time bins are tagged with a time stamp, that time stamp
most commonly refers to the start of the bin, or the end of it, but
seldom the middle.  There are two main reasons for this.

1. What is directly measurable is either the start or the end of an
integration, but not the halfway point.  Alternatively, one might say
that if one had to specify an integration period, one would use start
and/or stop time, not the average value of (absolute) time.

2. In various instruments, a certain event (e.g., a pulse) may initiate
a number of separate time series measurements, with different bin
sizes: one quantity may be read out every second, while another is
accumulated over 16 seconds, etc.  If one collects these measurements
(say, in a table), it makes eminent sense to stamp them with the start
time of the collective integrations.  It would be much more cumbersome
to stamp everything with its halfway time.

Consequently, if one looks in various FITS archives that hold time
series data, there is no consistency in the definition of what
location in the pixel (bin) the time stamps refer to.  Some people
have taken pains to comply with the informal FITS convention, while
others, no doubt, did not even realize that there was a convention
that might conceivably apply to this situation - they just did the
"natural" thing.

As a result, the convention in use has not even always been documented
in comments in the FITS header.  Even if it were, though, it would be
unsatisfactory.  It is of crucial importance for time series analysis
software to know where the relative and the absolute time stamps fall
(if there are different pixel sizes it is not even a matter of a
constant offset).  Essential information should not be buried in
comment or history keywords; it should be provided in "real" keywords.

Our Proposed Solution
---------------------

Based on the considerations given above, we have a strong need for a
keyword indicating the convention used for registering pixels along
the TIME axis.

We propose to use for this purpose the keyword:

		TIMEPIXR

which indicates the (relative) registration of TIME pixels, through a
value between:

	0.0 <= TIMEPIXR <= 1.0

Actually, one should probably state that the value of TIMPIXR
*usually* would be between 0.0 and 1.0.

TIMEPIXR indicates the position in the pixel that corresponds to the
coordinate values defined by the regular WCS-type keywords.  For
instance:

	TIMEPIXR= 0.0  / time stamps refer to the START of the pixel
	TIMEPIXR= 0.5  / time stamps refer to the CENTER of the pixel
	TIMEPIXR= 1.0  / time stamps refer to the END of the pixel

If the keyword TIMEPIXR is absent, we shall assume a default value of
0.5, consistent with the convention that coordinate values usually
refer to the center of the pixel, in FITS.

We considered a generalized version of this keyword, but decided
against that.  As far as we can see, the problem only occurs for the
TIME coordinate axis, and there seems no need to complicate matters by
allowing the same mechanism to apply to other coordinates.

  - Arnold Rots