[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