[daip] FITS header

[Eric Greisen]

Ian Pattison writes:
 > Eric,
 > 
 > If I understand correctly, from Marks e-mail, he measured the position of
 > your test pixel with WCSLIB and it agreed with the position you measured
 > in ds9. I was under the impression that ds9 was NOT accounting for the
 > skew, and making the pixels square (forcing the pixels to be square in
 > AIPS, via CDELT, resulted in the same pixel location as ds9). Does this
 > mean that ds9 positions are, in fact, not correct?
 > 
 > You mentioned that you are changing the way AIPS reads in the CDi_j
 > information, so that skew is accounted for - could I implement your
 > suggested changes at my end, i.e.  without the modified code.

You have not understood correctly:

1. I do not know what ds9 is doing.  If I have aips make the pixels
square with an average increment and use the average rotation angle,
then at a couple of well separated locations I get the same answer as
ds9.  It could of course be that ds9 fully implements wcslib and the CD
matrix and that the average is just very good especially where I chose
my samples (it is awfully hard to get ds9 to stop where one wants
exactly but I suppose I could work the other direction...)

2. I cannot change aips to account for skew without drastic changes to
the format of header files and to 100's of routines.  I did change the
routine that attempts to convert a CDi_j matrix into aips limited
capabilities so that it will get parameters closer to the average I
forced by hand.  But what it now gets is still not "square" pixels -
just 2% non-square rather than 4% non-square.  AIPS radio data do not
require skew or other rather complicated geometries in the new WCS
agreements, so it is hard to justify the expense and certainty of
error and user disruption that changing to wcslib would entail,
especially if aips is supposed to have a limited lifetime.

Eric Greisen