[fitswcs] Polarization codes

[Paddy Leahy]

On Wed, 12 Mar 2008, Mark Calabretta wrote:

>
> On Tue 2008/03/11 18:26:15 -0000, Paddy Leahy wrote
> in a message to: fitswcs at nrao.edu
>
>> I propose that we extend the existing list to include all the meaningful
>> non-linear combinations of I,Q,U,V. I may be naive, but it seems to me
>> that there are only a small number of such non-linear combinations of
>> interest. I think the following thirteen items are a complete list:
>
> Dear Paddy,
>
> The conventional axes, STOKES, COMPLEX, CUBEFACE (and potentially RGB,
> CMYK, etc.) have been defined to allow closely related images to be
> aggregated into one data structure.  However, they do not form a proper
> image axis since it doesn't make sense to interpolate either coordinates
> or pixel values along such axes.
>
> The traditional use of the STOKES axis reflects the fact that radio
> correlators typically measure either two or four polarizations and it
> is natural to want to store them together in a single array, e.g. for
> polarization calibration or to form the products that you're interested
> in here.  (Vector-valued pixels would be more appropriate but FITS
> doesn't provide them; this is the next best thing and is essentially
> equivalent in terms of data storage).
>
> At a practical level, the STOKES axis is only useful because of the way
> the values have been chosen; they reflect the very limited ways that
> polarizations are measured at the telescope or that Stokes values are
> derived from them.  For example, the ATCA measures either (XX,YY), or
> (XX,YY,XY,YX) and, with STOKES codes (-5,-6) or (-5,-6,-7,-8), these
> are representable via CRPIX, CDELT, and CRVAL.  If, perversely, you had
> (I,XX,RL) with STOKES codes of (1,-5,-3), then that would not be
> representable because the codes are not equi-spaced.
>
> Thus, in the general case, defining extra STOKES codes won't help you to
> aggregate derivative polarization products into one array, and if you're
> not interested in aggregation then it's not really the way to do it.
> The proper way would be to define a keyword that describes what the
> pixel values measure (not strictly a WCS issue), potentially it would
> be useful for more than just polarizations.  Currently there is nothing
> more than BUNIT (or roll your own) - clearly a gap that needs filling.

Well, we agree on the last point anyway.

I would defend my specific proposal on the following grounds:

1) Axes labelled "STOKES" are very frequently dummy axes with a single 
value (almost invariably, for image as opposed to visibility data). It is 
a convenient way of storing that information, just as e.g. for dummy 
frequency axes. Convenient because FITS readers are highly likely to 
recognise are correctly parse the information, not because it is the 
"nicest" possible way of encoding it.

2) My proposal won't lead to any ambiguity because it is impossible for 
the data to be described simultaneously by one of the existing stokes 
types and also by one of the proposed ones.

3) Because all FITS readers which "know" about polarization already will 
be looking for a "STOKES" axis, my proposal is a minimum-effort solution. 
Readers don't have to search in yet another place in the header for 
polarization information: which makes incorporating the extended 
definition much easier. (NB I'm not claiming that polarization info is 
always encoded on a "STOKES" axis --- it isn't --- but that is one place 
you always have to look).

regards,
 		Paddy