[fitsbits] Representation of polarimetry data in WCS

[Malcolm J. Currie]

An important consideration is what will the recipients of your FITS
files expect or can hasndle.  If they're going to be using certain
applications packages, you might find out what formats those packages
support.

My preference was not to have a Stokes axis, because each element
measures a different thing.  I know the purists are outnumbered by the
pragmatists, and it's now in the standard, so I'm not going to win that
argument.  Still...

I like a MEF with each Stokes-parameter array in its own IMAGE extension
with suitable extension type information* to indicate which array is
provided.  The secondary arrays like the polarization intensity can also
be included in this arrangement.  As they're not Stoke parameters, but
derivatives, they weren't included in CTYPEn = 'STOKES' in WCS Paper I.

Another approach is to use a `Greenbank Convention' binary table, where
each row contains the different polarization array along with
array-specific metadata, and primary HDU contains the dataset's global
metadata.

Disadvantages of these suggestions include the fact that there's no
conventional agreement on recognising the various array types.  An
arbitrary FITS reader can still import the data, but won't necessarily
know what to do with or the meaning of the various components.  Some
documentation will be needed.

You can of course, have a Stokes axis for the Stokes-parameter arrays,
and store the additional arrays like polarization intensity in IMAGE or
binary-table extensions.  For the Stokes parameters I'd advocate
following the documented convention, not least because others are likely
to do the same.  [I'm a grumpy old man who thinks FITS is for data
interchange.]

I don't know of a standard or widely used convention for handling the
ancillary arrays.  It is something of a specialist field.  In Starlink,
although our Standard Data Formats document did advocate not to use a
Stokes axis but separate arrays, one of our two polarimetry packages
ignores that recommendation.

That's a good question about the 4-3 notation.  Now that you mention it,
I only recall seeing CTYPEn = 'STOKES'.  Surely other algorithms that
operate on 'STOKES' would be documented.

Malcolm Currie
Rutherford Appleton Laboratory


* EXTTYPE is a keyword omitted in the FITS extension paper---sorry
Don---that I needed to export from our hierarchical data structures in
order to retain the structure information, and if necessary recreate the
hierarchy from the FITS extensions.  Omitting EXTTYPE has caused EXTNAME
to be used for both the name of a component and its type, e.g. VARIANCE,
QUALITY, integration-time map.  I raised this with Bill Pence a while
back.  Another bolted horse I fear.