[fitswcs] Polarization codes

Paddy Leahy j.p.leahy at manchester.ac.uk
Thu Mar 13 18:11:58 EDT 2008


On Thu, 13 Mar 2008, Doug Tody wrote:

> Hi Paddy -
>
> This sounds like a visualisation or analysis issue.  Probably the
> physical dataset should stick with (I,Q,U) if that is how data is
> observed.

On this basis we should never save anything but raw data, and re-compute 
everything on the fly.  That's a good philosophy for archives, but not for 
a general data-storage format.

As you pointed out, polarization is one of the four fundamental parameters 
(along with time, frequency & sky position) that are needed for a complete 
description of astronomical observations. For each of the other three 
(counting the recommendations on time in the draft FITS standard v.3), 
FITS defines numerous alternative ways of recording equivalent 
information, and it is routine to save data after transforming from one of 
these systems to another more convenient for the task at hand (e.g. 
frequency -> wavelength, TAI -> TDB, Equatorial -> Galactic).  On the same 
basis you should be able to choose, and freely convert between different 
ways of representing polarization (which is not always recorded directly 
as linear combinations of stokes parameters). In fact this *is* a routine 
internal operation in any polarimetry package; we just lack an agreed 
data-sharing convention.

Which is crazy because providing it for polarization is much simpler 
than for any of the other three.

> If a rendered value is computed, that could result in a
> packed value represented as a 2-D image or image plane, with a UCD
> or some layered convention used to describe what the pixel quantity
> represents (or alternatively just use JPEG or some such).  As you say,
> there is no standard way to describe things in this level of detail,
> but it would be best to not over complicate the core standards.

I could give quite a few other examples of applications that need 
polarization angles etc rather than stokes parameters, most of which need 
the floating-point values, not byte-scaled ones.

What I'm proposing is absolutely trivial compared to the WCS conventions 
already agreed (so I only expect the process to tale 3 or 4 years...). If 
we put it off, we just generate a thicker tangle of competing conventions 
later on which will be much harder to sort out. (I write as a member of 
the CMB community which is currently moving into polarization in a big 
way. Now is definitely the time to get standards in place for that 
community).

Paddy




More information about the fitswcs mailing list