Re: Polarization codes

On Thu 2008/03/13 22:11:58 -0000, Paddy Leahy wrote
in a message to: Doug Tody <dtodynrao.edu>
and copied to: FITSWCS <fitswcsnrao.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


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