[fitswcs] Polarization codes

[Mark Calabretta]

On Thu 2008/03/13 22:11:58 -0000, Paddy Leahy wrote
in a message to: Doug Tody <dtody at nrao.edu>
and copied to: FITSWCS <fitswcs at nrao.edu>

Dear Paddy,

>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 

My instinctive feeling is that polarization is intrinsically different
from direction, frequency, and time which is why it's causing trouble.
The EM field is completely described by four polarization quantities so
if you want to measure it completely then you need to measure all four.
This suggests that the measurement itself should be represented as a
four-element vector (recall the interpolability test).  

I alluded to this before; STOKES, COMPLEX, RGB, CMYK, would best be
handled as vector-valued pixels rather than conventional axes (the
exception, CUBEFACE, is an artificial storage mechanism).  You would
need to generalize BTYPE/BUNIT to BTYPEi/BUNITi, where i is the vector
element.  For your example of (I,Angle,Fraction) you might have

  BTYPE1 = 'Stokes I - brightness temperature'
  BUNIT1 = 'K'
  BTYPE2 = 'Polarization angle'
  BUNIT2 = 'deg'
  BTYPE3 = 'Fractional polarization'
  BUNIT3 = '%'

You could also have

  BTYPE1 = 'Stokes I - flux density'
  BTYPE1 = 'Stokes I - spectral index'
  BTYPE1 = 'Stokes I - whatever'

Problems with unrepresentable STOKES axes would then vanish.  With
appropriate rescaling (BSCALEi/BZEROi) you could even define alternates

  BTYPE1A = 'HSV value'
  BTYPE2A = 'HSV hue'
  BTYPE3A = 'HSV saturation'
  etc.

(OK, I'm dreaming.)

Regards, Mark