Want the ability to read in "LONPOLE" and potentially other arguments (e.g. SIP coefficients) from FITS headers.

[nihardalal]

We were trying to read in the WCS from a fits file that had been initially written with galsim, and then potentially written over with astropy, so the header had a "LONPOLE" argument.

When trying to write a new GalSim image, we realized that LONPOLE is never actually read by galsim, which can be confusing when you look at a header. It might be a good idea to add the ability to read in LONPOLE?

This was largely in _read_header in the GSFitsWCS class - happy to send more reproducibility details below if needed.

[rmjarvis]

Why do you need LONPOLE to be read in? It's not a useful value, as far as I can tell. I'm pretty sure even astropy just carries it around as something to report. I don't think they ever use it for any calculation:

https://github.com/search?q=repo%3Aastropy%2Fastropy+lonpole&type=code&p=1

Did you get some kind of error behavior from GalSim not reading it?

[nihardalal]

Chris and I were hoping to use it to rotate the axis of an image - we are aware that there's other arguments to do this like the PC matrix, but I think that LONPOLE might be easier to visualize and implement for rotations of a space telescope?

In our current use case, there's a catalog of observations that are made with an effectively 210 degree lonpole, so when we pass the assumed WCS to the galsim image, we get a 30 degree rotated image from what we actually would like.

Let me add Chris (@hirata10) to this thread and see if he has any better input regarding this.

[rmjarvis]

GalSIm's GSFitsWCS supports either CD or PC with CDELT. I actually don't know what the official WCS spec for LATPOLE/LONPOLE is exactly. I tried to search for it the WCS specs online, but didn't find anything definitive. I think it's at least degenerate with these other key words.

If astropy does support it, you can use the AstropyWCS class in GalSim to use that rather than GSFitsWCS (or implicitly through FitsWCS).

[rmjarvis]

There is also PyAstWCS, which uses the starlink-pyast module. In my experience, that is the most comprehensive FITS backend available. So I suspect they implement LONPOLE correctly. Whatever that is. ;-)

[hirata10]

The LONPOLE keyword is defined in FITS Paper II, §2.2, 2.3. Basically after the projection center, it is the 3rd Euler angle that rotates the projection plane.

For some projection types, the 3rd angle is essential (e.g., the classic Molleweide map of the CMB described in RA/Dec needs to know both the location of the Center and the tilt of the Plane). For zenithal projections (e.g., TAN, STG) it is of course redundant with multiplying the CD matrix by

[  -cos(LONPOLE)    sin(LONPOLE)  ]
[  -sin(LONPOLE)   -cos(LONPOLE)  ]

on the left.

Both astropy and ds9 are happy with LONPOLE. We use it in PyIMCOM if you want to make a mosaic that is not aligned with RA/Dec (though if LSST isn't doing that then we probably will not use that functionality).

This came up in @kara-elese's project, where we were using it as a way to move the "same" camera around and simulate lots of images for calibration (and then changing the single LONPOLE variable is easier to track than all the CD coefficients). But it sound like the AstropyWCS class might be our best choice for our immediate needs?

[nihardalal]

I'm gonna close this issue. On a more careful read of the documentation, I am now realizing that GSFitsWCS is meant to be a lightweight implementation of WCS. It seems like AstropyWCS should work correctly in our use case. Thanks for the pointers @rmjarvis !