[fitswcs] Polarization codes

[Paddy Leahy]

Hi Mark et al  (is anyone else reading these posts?)

On Thu, 13 Mar 2008, Mark Calabretta wrote:

> 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.
> 
Jy/beam and brightness temperature are both ways of specifying the same 
quantity, viz. brightness, intensity or whatever you want to call it.

One question you should always ask about any brightness measurement is the 
polarization it represents. The existing STOKES codes are incomplete here at 
least in the sense that they omit |V|, Sqrt(Q^2 + U^2) and Sqrt(Q^2 + U^2 + 
V^2) all of which have dimensions of brightness, and one of which is frequently 
written to FITS files (with STOKES code  5). As for the dimensionless 
quantities (fraction, angle) it remains significant that they were constructed 
from brightness data (as opposed to, for instance, optical depth values).

Among the other quantities you list above, some are also proxies for brightness 
(emission measure). Optical depth and spectral index each strictly require 
polarization to be specified (usually Stokes I is assumed but polarized 
absorption experiments are done from time to time, and the spectral index of 
polarized emission is a crucial parameter in my work). Flux density strictly 
speaking is a property of specific objects rather than a field defined on the 
sky, but obviously all the non-linear Stokes combinations can be constructed 
from flux densities as well as brightness.

In short 1) *any* dataset derived from measurements of EM radiation, 
astronomical or otherwise, requires the polarization to be specified at least 
implicitly.

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

3) The existing "STOKES" codes are inadequate to do the job but could easily be 
extended to cope.

>> 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.
> <snip>
>  Yes, it would work.  Yes, it's a horrible kludge.

But a kludge already mostly implemented and already widely used for 
polarization maps archived to FITS from AIPS.

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

Obviously any extension of the standard would require some new coding for full 
implementation. So far I haven't come across a reader than chokes on the 
non-standard codes written by AIPS.

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

Per argument above, at least for astronomical/imaging data, polarization and 
your BTYPE are needed separately. And while for polarization you can provide a 
complete list (and a short one), even in the astronomical arena it would be 
hard to argue that any such list of types would be complete...
let alone for more general FITS usage (grain yield per hectare??).

So let's not hold up a simple fix for the lack of a theory of everything...

regards,
 		Paddy