|
List Info
Thread: Polarization codes
|
|
| Polarization codes |
  United Kingdom |
2008-03-11 13:26:15 |
Dear All,
I was surprised to find recently that the current FITS WCS
conventions do not appear to provide an unambiguous (i.e.
machine-
interpretable) way of specifying such routine polarization
products as
polarization angle and fractional polarization. I'm not sure
if this
mailing list is the right place to raise the issue but since
the current
"Stokes" codes were defined in WCS paper I it
seems a good place to start.
Reminder: on the current definition (WCS Paper I, Table 7),
the official
stokes parameters I, Q, U, V are assigned STOKES 1,2,3,4,
while various
products such as RR through XY (which are linear
combinations of I,Q,U,V)
are assigned STOKES -8 through -1.
I propose that we extend the existing list to include all
the meaningful
non-linear combinations of I,Q,U,V. I may be naive, but it
seems to me
that there are only a small number of such non-linear
combinations of
interest. I think the following thirteen items are a
complete list:
Linear polarization angle 1/2 Arctan(U,Q)
Linearly polarized intensity Sqrt(Q^2 + U^2)
Elliptically polarized intensity Sqrt(Q^2 + U^2 + V^2)
Unpolarised intensity I - Sqrt(Q^2 + U^2 +
V^2)
Circularly polarized intensity |V|
Fractional Q Q/I
Fractional U U/I
Fractional V V/I
Fractional linear polarization Sqrt(Q^2 + U^2) / I
Fractional elliptical polarization Sqrt(Q^2 + U^2 + V^2) /
I
Fractional circular polarization |V| / I
Fractional unpolarized emission 1 - Sqrt(Q^2 + U^2 + V^2)
/ I
undefined polarization ---
Some of these (e.g. |V| and |V|/I) may not be needed but are
included
to ensure this issue will not have to be re-visited in the
future.
Thhe most useful of these are assigned "STOKES"
codes by AIPS, viz:
5 => Linearly polarized intensity (pace "Going
AIPS" p.5-6 which says
"Percent
polarization" in error)
6 => Fractional polarization
7 => Polarization position angle
AIPS also uses STOKES 0 => beam, 8 => Spectral index
and 9 => Optical
depth, but these seem inappropriate definitions (all of
these may in
general need polarization labels as well). These codes are
written to FITS
headers by AIPS.
"Once FITS always FITS" would require that we
avoid using codes 0, 8, 9
and either adopt the existing AIPS usage for codes 5,6,7 (if
not rendered
ambiguous by the usage of oteher fits writers) or choose new
unambiguous
codes (e.g. starting at 10 or 100) for the above set of
eleven.
What do people think, and what is the best way of going
about (eventually)
getting a formal ruling?
regards,
Paddy Leahy
======================================================
Dr J. P. Leahy, Jodrell Bank Centre for Astrophysics,
Current address: Osservatorio Astronomico di Trieste
INAF, Via GB Tiepolo 11, 34143 Trieste, Italy
Tel.+39 040 3199160 Fax +39 040 309418
_______________________________________________
fitswcs mailing list
fitswcs listmgr.cv.nrao.edu
h
ttp://listmgr.cv.nrao.edu/mailman/listinfo/fitswcs
|
|
| Re: Polarization codes |
  Australia |
2008-03-11 20:34:09 |
On Tue 2008/03/11 18:26:15 -0000, Paddy Leahy wrote
in a message to: fitswcs nrao.edu
>I propose that we extend the existing list to include
all the meaningful
>non-linear combinations of I,Q,U,V. I may be naive, but
it seems to me
>that there are only a small number of such non-linear
combinations of
>interest. I think the following thirteen items are a
complete list:
Dear Paddy,
The conventional axes, STOKES, COMPLEX, CUBEFACE (and
potentially RGB,
CMYK, etc.) have been defined to allow closely related
images to be
aggregated into one data structure. However, they do not
form a proper
image axis since it doesn't make sense to interpolate either
coordinates
or pixel values along such axes.
The traditional use of the STOKES axis reflects the fact
that radio
correlators typically measure either two or four
polarizations and it
is natural to want to store them together in a single array,
e.g. for
polarization calibration or to form the products that you're
interested
in here. (Vector-valued pixels would be more appropriate
but FITS
doesn't provide them; this is the next best thing and is
essentially
equivalent in terms of data storage).
At a practical level, the STOKES axis is only useful because
of the way
the values have been chosen; they reflect the very limited
ways that
polarizations are measured at the telescope or that Stokes
values are
derived from them. For example, the ATCA measures either
(XX,YY), or
(XX,YY,XY,YX) and, with STOKES codes (-5,-6) or
(-5,-6,-7,-8), these
are representable via CRPIX, CDELT, and CRVAL. If,
perversely, you had
(I,XX,RL) with STOKES codes of (1,-5,-3), then that would
not be
representable because the codes are not equi-spaced.
Thus, in the general case, defining extra STOKES codes won't
help you to
aggregate derivative polarization products into one array,
and if you're
not interested in aggregation then it's not really the way
to do it.
The proper way would be to define a keyword that describes
what the
pixel values measure (not strictly a WCS issue), potentially
it would
be useful for more than just polarizations. Currently there
is nothing
more than BUNIT (or roll your own) - clearly a gap that
needs filling.
Regards,
Mark Calabretta
ATNF
_______________________________________________
fitswcs mailing list
fitswcs listmgr.cv.nrao.edu
h
ttp://listmgr.cv.nrao.edu/mailman/listinfo/fitswcs
|
|
[1-2]
|
|