List Info

Thread: Re: Polarization codes




Re: Polarization codes
user name
2008-03-13 19:09:50
On Thu 2008/03/13 15:44:55 -0000, Paddy Leahy wrote
in a message to: Mark Calabretta <mcalabreatnf.csiro.au>
and copied to: fitswcsnrao.edu

Dear Paddy,

>Jy/beam and brightness temperature are both ways of
specifying the same 
>quantity, viz. brightness, intensity or whatever you
want to call it.

They may differ by a constant factor, but still they
differ.

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

...and it should be mentioned (for the lurkers) that
(I,Q,U,V) themselves
are not measured directly in practice, but calculated from
either
(RR,LL,RL,LR) or (XX,YY,XY,YX).

In your original 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             ---

the ones arrowed are those that I agree could have new
STOKES codes
(I'm not sure what you have in mind for
"undefined").  Admitting
these will increase the likelihood that a STOKES axis of
length > 2
will be unrepresentable (as I discussed initially), but I
guess that's
too bad.

The rest trespass into the area of what is measured, e.g.
linear
polarization angle is the measurement for which BUNIT must
be an
angular measure. 

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

No argument there, as previously discussed, that is how the
STOKES codes
are currently used.

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

I agree with the first part (which is the same as your first
point), but
not with the comment about position angle since that is the
measurement,
e.g. how would you combine it with brightness, spectral
index, or
anything else?

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

I agree with extra codes for the four quantities indicated
above.  As
for the others, since the proposal is to define standard or
quasi-
standard usage, I am trying to preclude usage that I don't
think is a
good idea in the longer term.

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

Coding BTYPE may be slightly more difficult than coding
extra STOKES
codes but clearly it would be effort well spent.

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

It never would be complete, but in many instances BTYPE
would only be of
interest in labelling graphs - like CTYPE used to be and
often still is.
A basic set could be defined initially and new ones
registered in a
central repository, like that of keywords, at a later time.

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

It's only one little keyword - and, looking on the bright
side, the
requirement for it to take at least seven years to get
anything ratified
in FITS has now been dispensed with!

Regards, Mark


_______________________________________________
fitswcs mailing list
fitswcslistmgr.cv.nrao.edu
h
ttp://listmgr.cv.nrao.edu/mailman/listinfo/fitswcs

Re: Polarization codes
user name
2008-03-13 21:39:27
On Fri, 14 Mar 2008, Mark Calabretta wrote:

<snipped>... but I'm pleased to see we are in 40%
agreement! Maybe more as 
you'll see.

>
> (I'm not sure what you have in mind for
"undefined").

Intended for archives which write a standard list of header
keywords, but 
may contain data for which the polarization is not known,
too messy to
specify (eg. response varies substantially over the FOV) or
not defined
(eg. polarization-independent beams, maps of UHECR arrival
directions).

>> 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).
>
> I agree with the first part (which is the same as your
first point), but
> not with the comment about position angle since that is
the measurement,
> e.g. how would you combine it with brightness, spectral
index, or
> anything else?

Example: From (IQUV) absorption spectra, calculate the
optical depth 
separately for polarized and unpolarized emission. The ratio
(fractional 
polarization of optical depth) tells you something
interesting about the 
absorbing material. The polarized absorption may also be
anisotropic, 
hence there may be an angle for the polarized optical depth.
This can 
happen in theory for absorption by Zeeman-split lines,
although I have to 
admit that I've not heard about a measurement in an
astronomical context.

Obviously an analogous procedure is possible for spectral
index, though 
I'm not sure what it would mean (differential "spectral
indices" for Q and 
U might indicate Faraday rotation). The usual angle of
polarization 
specifically refers to brightness (i.e. it gives the
polarizer angle for 
maximum response to emission), hence should be distinguished
from angles 
defined from optical depth etc. It's only because the other
angles are 
hardly ever used that you can usually forget this. (Like
you, I want 
conventions that will prove robust in the long term).

Building on your point that really we are dealing with
vector-valued 
quantities, right now the STOKES "axis" in
practice just specifies 3 ways 
of building such a vector (XX,..) (RR...) (I...), i.e. 3
coordinate 
systems in the same space. Representations including angles
are polar 
coordinates, again in the same space. As Doug Tody
mentioned, FITS handles 
somewhat-similar cases (eg. frequency/velocity) by providing
alternative 
axis descriptors, and I suppose by analogy there could be
alternative axis 
descriptors for polarization. The axis descriptor would
imply the 
mandatory units like degrees and % (or plain number), saving
all those 
BTYPEi /BUNITi lines. Not sure if I like this because there
are many more 
possible quadruplets of polarizations quantities than
quantities 
themselves, so the standard would have to limit itself to a
few "natural" 
permutations. Also this would leave the current stokes
"axis" looking even 
more anomalous than now.

Instead, to preserve your contiguity requirement, which
would be a nice 
thing to do, how about this: Stokes 11-14 imply a 1 to 4
element vector 
with components described by a new set of cards, eg

dataset 1:
NAXIS3  = 4
...
CTYPE3  = 'STOKES'
CRPIX3  = 11
POLCO1  =  'I'    / Implied unit is BUNIT
POLCO2  =  'Q/I'  / Dimensionless ratio
POLCO3  =  'U/I'  / Dimensionless ratio 
POLCO4  =  'V/I'  / Dimensionless ratio

dataset 2:
NAXIS3  = 3
...
CTYPE3  = 'STOKES'
CRPIX3  = 11
POLCO1  = 'LinPolInt' / [BUNIT] Linearly polarized
intensity
POLCO2  = 'PolAng'    / [deg] Polarization angle in degrees
POLCO3  = 'I'         / [BUNIT] Total intensity

Not sure if it's better to have the values as strings or
numeric codes, 
but in either case there would be a strictly limited set of
allowed 
values (viz: existing STOKES codes plus the ones in my
original post), 
with mandatory units (BUNIT/ratio/deg as appropriate).

Obviously this is byzantine compared to my original
proposal. Depends how 
important contiguity is felt to be, given that you can
always write 4 
extensions or stick 4 images in a bintable instead.

regards,
 	Paddy

_______________________________________________
fitswcs mailing list
fitswcslistmgr.cv.nrao.edu
h
ttp://listmgr.cv.nrao.edu/mailman/listinfo/fitswcs

Re: Polarization codes
user name
2008-03-13 22:14:28
On Fri 2008-03-14T02:39:27 +0000, Paddy Leahy hath writ:
> Example: From (IQUV) absorption spectra, calculate the
optical depth
> separately for polarized and unpolarized emission. The
ratio (fractional
> polarization of optical depth) tells you something
interesting about the
> absorbing material. The polarized absorption may also
be anisotropic,
> hence there may be an angle for the polarized optical
depth. This can
> happen in theory for absorption by Zeeman-split lines,
although I have to
> admit that I've not heard about a measurement in an
astronomical context.

Isn't this pretty much the data used by a solar
magnetograph?
If so, we need input from practicing solar astronomers
before we're done.

--
Steve Allen                 <slaucolick.org>            
   WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165   
Lat  +36.99855
University of California    Voice: +1 831 459 3046          
Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~
sla/     Hgt +250 m

_______________________________________________
fitswcs mailing list
fitswcslistmgr.cv.nrao.edu
h
ttp://listmgr.cv.nrao.edu/mailman/listinfo/fitswcs

[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )