[fitswcs] Polarization codes

[Paddy Leahy]

On Fri, 14 Mar 2008, Mark Calabretta wrote:

<snipped>... but I'm pleased to see we are in 40% agreement! Maybe more as 
you'll see.

>
> (I'm not sure what you have in mind for "undefined").

Intended for archives which write a standard list of header keywords, but 
may contain data for which the polarization is not known, too messy to
specify (eg. response varies substantially over the FOV) or not defined
(eg. polarization-independent beams, maps of UHECR arrival directions).

>> 2) The polarization specification is not an option in a list which
>> includes quantities like "optical depth" and "brightness" but is always
>> required in addition (even when the polarization product is something like
>> position angle).
>
> I agree with the first part (which is the same as your first point), but
> not with the comment about position angle since that is the measurement,
> e.g. how would you combine it with brightness, spectral index, or
> anything else?

Example: From (IQUV) absorption spectra, calculate the optical depth 
separately for polarized and unpolarized emission. The ratio (fractional 
polarization of optical depth) tells you something interesting about the 
absorbing material. The polarized absorption may also be anisotropic, 
hence there may be an angle for the polarized optical depth. This can 
happen in theory for absorption by Zeeman-split lines, although I have to 
admit that I've not heard about a measurement in an astronomical context.

Obviously an analogous procedure is possible for spectral index, though 
I'm not sure what it would mean (differential "spectral indices" for Q and 
U might indicate Faraday rotation). The usual angle of polarization 
specifically refers to brightness (i.e. it gives the polarizer angle for 
maximum response to emission), hence should be distinguished from angles 
defined from optical depth etc. It's only because the other angles are 
hardly ever used that you can usually forget this. (Like you, I want 
conventions that will prove robust in the long term).

Building on your point that really we are dealing with vector-valued 
quantities, right now the STOKES "axis" in practice just specifies 3 ways 
of building such a vector (XX,..) (RR...) (I...), i.e. 3 coordinate 
systems in the same space. Representations including angles are polar 
coordinates, again in the same space. As Doug Tody mentioned, FITS handles 
somewhat-similar cases (eg. frequency/velocity) by providing alternative 
axis descriptors, and I suppose by analogy there could be alternative axis 
descriptors for polarization. The axis descriptor would imply the 
mandatory units like degrees and % (or plain number), saving all those 
BTYPEi /BUNITi lines. Not sure if I like this because there are many more 
possible quadruplets of polarizations quantities than quantities 
themselves, so the standard would have to limit itself to a few "natural" 
permutations. Also this would leave the current stokes "axis" looking even 
more anomalous than now.

Instead, to preserve your contiguity requirement, which would be a nice 
thing to do, how about this: Stokes 11-14 imply a 1 to 4 element vector 
with components described by a new set of cards, eg

dataset 1:
NAXIS3  = 4
...
CTYPE3  = 'STOKES'
CRPIX3  = 11
POLCO1  =  'I'    / Implied unit is BUNIT
POLCO2  =  'Q/I'  / Dimensionless ratio
POLCO3  =  'U/I'  / Dimensionless ratio 
POLCO4  =  'V/I'  / Dimensionless ratio

dataset 2:
NAXIS3  = 3
...
CTYPE3  = 'STOKES'
CRPIX3  = 11
POLCO1  = 'LinPolInt' / [BUNIT] Linearly polarized intensity
POLCO2  = 'PolAng'    / [deg] Polarization angle in degrees
POLCO3  = 'I'         / [BUNIT] Total intensity

Not sure if it's better to have the values as strings or numeric codes, 
but in either case there would be a strictly limited set of allowed 
values (viz: existing STOKES codes plus the ones in my original post), 
with mandatory units (BUNIT/ratio/deg as appropriate).

Obviously this is byzantine compared to my original proposal. Depends how 
important contiguity is felt to be, given that you can always write 4 
extensions or stick 4 images in a bintable instead.

regards,
 	Paddy