[fitswcs] Polarization codes

[Mark Calabretta]

On Thu 2008/03/27 21:46:57 PDT, Steve Allen wrote
in a message to: FITSWCS <fitswcs at nrao.edu>

>Did anyone else get that message from Paddy Leahy?
>I've checked my junk filters and I didn't see it, and it's not
>in the fitswcs archive.  But turning to Mark's reply

Strange, it wasn't in the queue either.  I've appended it.
Cheers, Mark

>>>

Date: Thu, 27 Mar 2008 14:09:40 +0000 (GMT)
From: Paddy Leahy <j.p.leahy at manchester.ac.uk>
To: Mark Calabretta <mcalabre at atnf.csiro.au>
Cc: fitswcs at nrao.edu
Subject: Re: [fitswcs] Polarization codes

On Mark's  CTYPE = "VECTOR-xxx" idea:

I would support this approach if it has a reasonable chance of being 
endorsed by the IAU FITS WG. It certainly provides a comprehensive 
solution to my original problem (except for the detail of agreeing code 
names for the various polarization products).

A few specific questions/comments, mostly for Mark but the last & most 
important for everyone?

* CTYPE = 'VECTOR-Polarization': Can we do this? What happened to the 
8-character limit on CTYPE values?

* BUNITia vs implicit units:

I'm not convinced that BUNITia is necessary. The magnitude of the vector 
is a dimensional quantity whose units are naturally specified by BUNIT. I 
have yet to come across a coordinate system in practical use where the 
coordinates are not covered by the following three cases:

(a) Dimensional ones, with the same unit as used for the overall vector 
magnitude. At least one coordinate in any set must fall into this 
category. (GR textbooks tend to cite examples where x is measured in 
metres and y is measured in inches, but does anyone every really do this? 
And if they do do we want to allow this in FITS files?)

(b) Angles: the existing FITS standard mandates that these must be 
expressed in degrees (and this is not widely flouted).

(c) Ratios: here only practical options are to use the plain ratio (which 
I tend to do) or the percentage (which Mark seems to favour). I don't 
think it would be a problem to agree on one or the other and write it into 
the standard, especially as this would be a "new page" with no previous 
baggage.

I suppose some other non-ratio dimensionless numbers might appear, which 
might be an argument for using % to indicate genuine ratios.

* BTYPEia

If this proposal has anything to do with my original request, it is 
essential that an agreed dictionary of BTYPE values be included in the 
standard (which would naturally make explicit the appropriate units for 
each type, viz (a) same as vector magnitude, hence BUNIT (b) degrees (c) 
ratio or percentage.  Mark has mentioned three cases: (i) polarization 
(obviously) (ii) complex plane (iii) colour space. The initial dictionary 
should probably also include general position vectors. At one point Mark 
proposed (tongue in cheek, I suspect) a comprehensive dictionary of 
possible data types. The VO work on UCDs suggests to me that this would be 
a virtually endless task, so I strongly favour limiting the initial 
dictionary to cases that are needed now, and solely to polarization if the 
other cases lead to protracted arguments.

* From a practical point of view, the key question is, what is the chance 
of this getting the support of the IAU FITS-WG?  Or to put it another way, 
what are the chances of getting this implemented in the major astronomical 
packages?  Clearly the drawback is that the existing special axis 
convention, hoary as it is, has only recently been formally adopted 
(thanks to Mark and Eric's epic efforts), and now we have a proposal for 
an alternative way of encoding the same information (albeit clearly better 
and more general).

regards,
        Paddy

On Mon, 17 Mar 2008, Mark Calabretta wrote:

<snip>
> As an example, we might have a dual description:
>
> NAXIS3  = 3
> ...
> CTYPE3X = 'VECTOR-Polarization'
> BTYPE1X = 'I'
> BUNIT1X = 'K'
> BTYPE2X = 'FracLinPol'
> BUNIT2X = '%'
> BTYPE3X = 'PolAng'
> BUNIT3X = 'deg'
>
> CTYPE3C = 'VECTOR-HSV'
> BTYPE1C = 'Value'
> BUNIT1C = '%'
> BZERO1C = ...
> BSCAL1C = ...
> BTYPE2C = 'Saturation'
> BUNIT2C = '%'
> BZERO2C = ...
> BSCAL2C = ...
> BTYPE3C = 'Hue'
> BUNIT3C = '%'
> BZERO3C = ...
> BSCAL3C = ...
>
> where the zero values and scales are floating point numbers chosen
> appropriately to scale the polarization components to colour components
> in the proper range.  Note how the HSV order has been permuted as
> (Value,Saturation,Hue) to match (I,FracLinPol,PolAng).
>
> Now we must consider what will happen when old FITS readers encounter
> these new keywords.  Firstly we must recognize that there is no chance
> that any software that has not been updated will be able to deduce the
> correct meaning for new usage, no matter how it is implemented.
>
> Of those in the example above, the only keywords that old readers will
> "see" are
>
> NAXIS3  = 3
> CTYPE3X = 'VECTOR-Polarization'
> CTYPE3C = 'VECTOR-HSV'
>
> How will they interpret these?  If conformant to the WCS standards, then
> they will provide default values for CRPIXia, CDELTia, and CRVALia and
> will compute coordinate values equal to the pixel coordinate value.
> This is meaningless but harmless.  Output labelled with types of
> 'VECTOR-Polarization' (n.b. not 'STOKES') and 'VECTOR-HSV' should alert
> any human interpreters that something is wrong.