[fitswcs] Polarization codes

[Mark Calabretta]

On Wed 2008/03/12 01:57:29 -0000, Paddy Leahy wrote
in a message to: Mark Calabretta <mcalabre at atnf.csiro.au>
and copied to: Paddy Leahy <j.p.leahy at manchester.ac.uk>, fitswcs at nrao.edu

Dear Paddy,

>1) Axes labelled "STOKES" are very frequently dummy axes with a single 
>value (almost invariably, for image as opposed to visibility data). It is 

The typical RA/DEC/FREQ/STOKES quadruple tells you where the measurement
was taken - where the telescope was pointed, how the conversion chain
and polarizers were configured.  It doesn't tell you what was measured,
e.g. flux density, brightness temperature, spectral index, opacity,
optical depth, emission measure, or whatever.

It may not seem so at first sight, but your proposal goes beyond this
in wanting to use the STOKES axis to indicate =what was measured=, e.g.
polarization angle, fractional polarization, etc.

Currently what was measured can only be inferred from BUNIT - 'Jy/beam'
means flux density, 'K' means brightness temperature, etc.  Clearly what
is needed is a BTYPE keyword, with BTYPE/BUNIT directly analogous to
CTYPE/CUNIT.

>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.

Reductio ad absurdum: we could generalise your proposal by introducing,
say, a 'BTYPE' axis, i.e. CTYPEia = 'BTYPE', and define enumerated
measurement types of which your STOKES types would be a subset.  CUNITia
for this axis would correspond with BUNIT.  This axis would nearly
always have to be degenerate.  Yes, it would work.  Yes, it's a horrible
kludge.

Another way of looking at it: in effect, BTYPE/BUNIT defines the
measurement axis, but with no need for the corresponding BRPIXia,
BRDELTia, BRVALia *because* the "coordinate value" (i.e. measurement)
is stored directly as a floating point value, rather than being deduced
from rules based on pixel coordinates.  (Actually, BSCALE and BZERO do
a job similar to the putative BRDELTia and BRPIXia with BRVALia = 0 for
the integer data types, but these are not pixel coordinates.)

>3) Because all FITS readers which "know" about polarization already will 
>be looking for a "STOKES" axis, my proposal is a minimum-effort solution. 

Not really, because most software wouldn't know what to do with these
other STOKES codes and some of it might even break.

>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).

Please propose BTYPE with a standard set of values, it's as fundamental
as BUNIT.  The FITS community will shower you with eternal thanks!

Regards, Mark