[fitswcs] Polarization codes

Mark Calabretta mcalabre at atnf.CSIRO.AU
Thu Mar 27 23:39:09 EDT 2008


On Thu 2008/03/27 14:09:40 -0000, Paddy Leahy wrote
in a message to: Mark Calabretta <mcalabre at atnf.csiro.au>
and copied to: fitswcs at nrao.edu

Dear Paddy,

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

This seems to trip people up - I have been in the past, and maybe Eric
also: the 8-char limit applies to the keyword, not the keyvalue.  The
latter is limited only by what you can fit in one keyrecord, i.e. 68
chars.  Also, the only restriction on the keyvalue is that it must be a
printable ASCII character.

>* BUNITia vs implicit units:
>
>I'm not convinced that BUNITia is necessary. The magnitude of the vector 

In principle, they're not necessary but in practice they are.  In any
case, I agree with your point that default units should be defined for
each measurement type.

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

I suggested '%' for colour components because of its explicit
normalization.  Otherwise you need a way to distinguish between
components in the range 0 - 255, say, or components in the range
0.0 - 1.0 (e.g. chromaticities), or some other range.

>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 

This is essentially what we already have for CTYPEia.  If the name is
recognized as a particular type, e.g. those defined by the WCS papers,
then it has a specific interpretation.  If not, then it has a default
interpretation, i.e. the original linear coordinate system.  The same
would apply more easily to BTYPEia.  Of course, it would make sense to
agree on a set of names for common measurements.

>* 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?

These are two very different questions!  After all these years, many
major astronomical packages still do not implement the WCS standard.

They way it works these days is basically the way it's always worked:
  1) Develop the methodology (think of Eric's original coordinate work).
  2) Document it publically (AIPS memos 27 and 46).
  3) Prove that it works by implementing it and getting it into
     widespread use (AIPS).
  4) Encourage other people to adopt it (IRAF, etc.).
  5) Try to get it cast in stone (WCS standard, WCSLIB).
The last step maybe tortuous but fortunately it's optional.  (There is
also a 6th step but I don't want to discourage you!)

If you want (4) and maybe (5) to succeed, then you had better get (1),
(2) and (3) right.  However, even if you get them wrong, in practical
terms you have de facto title to a bit of the FITS namespace, in this
case BTYPEia, BUNITia, BSCALia and BZEROia.  In any case, these keywords
do not conflict with any other documented FITS usage so noone can stop
you from using them; this is the concept of private extensibility
extolled by Don Wells.

Cheers, Mark





More information about the fitswcs mailing list