[fitswcs] Polarization codes

[Don Thompson]

Hi,

>Hi Mark et al  (is anyone else reading these posts?)

I am. Although I only understand about 2% of what is being said.

What mailing list is this?

Don Thompson, a computer guy...definitely not an optics guy.









On Thu, Mar 13, 2008 at 12:19 PM, Paddy Leahy
<j.p.leahy at manchester.ac.uk> wrote:
>
>  Hi Mark et al  (is anyone else reading these posts?)
>
>
>  On Thu, 13 Mar 2008, Mark Calabretta wrote:
>
>  > The typical RA/DEC/FREQ/STOKES quadruple tells you where the measurement
>  > was taken - where the telescope was pointed, how the conversion chain
>  > and polarizers were configured.  It doesn't tell you what was measured,
>  > e.g. flux density, brightness temperature, spectral index, opacity,
>  > optical depth, emission measure, or whatever.
>  >
>  > It may not seem so at first sight, but your proposal goes beyond this
>  > in wanting to use the STOKES axis to indicate =what was measured=, e.g.
>  > polarization angle, fractional polarization, etc.
>  >
>  > Currently what was measured can only be inferred from BUNIT - 'Jy/beam'
>  > means flux density, 'K' means brightness temperature, etc.  Clearly what
>  > is needed is a BTYPE keyword, with BTYPE/BUNIT directly analogous to
>  > CTYPE/CUNIT.
>  >
>  Jy/beam and brightness temperature are both ways of specifying the same
>  quantity, viz. brightness, intensity or whatever you want to call it.
>
>  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). As for the dimensionless
>  quantities (fraction, angle) it remains significant that they were constructed
>  from brightness data (as opposed to, for instance, optical depth values).
>
>  Among the other quantities you list above, some are also proxies for brightness
>  (emission measure). Optical depth and spectral index each strictly require
>  polarization to be specified (usually Stokes I is assumed but polarized
>  absorption experiments are done from time to time, and the spectral index of
>  polarized emission is a crucial parameter in my work). Flux density strictly
>  speaking is a property of specific objects rather than a field defined on the
>  sky, but obviously all the non-linear Stokes combinations can be constructed
>  from flux densities as well as brightness.
>
>  In short 1) *any* dataset derived from measurements of EM radiation,
>  astronomical or otherwise, requires the polarization to be specified at least
>  implicitly.
>
>  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).
>
>  3) The existing "STOKES" codes are inadequate to do the job but could easily be
>  extended to cope.
>
>
>  >> 2) My proposal won't lead to any ambiguity because it is impossible for
>  >> the data to be described simultaneously by one of the existing stokes
>  >> types and also by one of the proposed ones.
>  > <snip>
>
> >  Yes, it would work.  Yes, it's a horrible kludge.
>
>  But a kludge already mostly implemented and already widely used for
>  polarization maps archived to FITS from AIPS.
>
>
>  >> 3) Because all FITS readers which "know" about polarization already will
>  >> be looking for a "STOKES" axis, my proposal is a minimum-effort solution.
>  >
>  > Not really, because most software wouldn't know what to do with these
>  > other STOKES codes and some of it might even break.
>
>  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.
>
>
>  >
>  > Please propose BTYPE with a standard set of values, it's as fundamental
>  > as BUNIT.  The FITS community will shower you with eternal thanks!
>  >
>
>  Per argument above, at least for astronomical/imaging data, polarization and
>  your BTYPE are needed separately. And while for polarization you can 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??).
>
>  So let's not hold up a simple fix for the lack of a theory of everything...
>
>  regards,
>                 Paddy
>
>
>
>  _______________________________________________
>  fitswcs mailing list
>  fitswcs at listmgr.cv.nrao.edu
>  http://listmgr.cv.nrao.edu/mailman/listinfo/fitswcs
>