Open kerrm opened 7 months ago
PS -- in case it's useful, when you use HEALPix projection, the header is correct.
Thanks @kerrm , I'll look into this. Have you seen the behavior with any other tools?
I haven't seen it in other tools -- this was very ad hoc, though, and I only noticed it because BITPIX BIT me.
Philippe kindof reproduced the issue with the same version of fermitools (2.2.0). For him, the header is still mangled, but the 2nd value of BITPIX is -32, as it should be! Ultimately the real problem is the repeated values, which for these keywords breaks FITS compliance in any case.
I made a model map using gtmodel with the CAR projection:
gtmodel srcmaps=ext_4FGL_J1409.1-6121e_ccube_CAR.fits srcmdl=ext_4FGL_J1409.1-6121e.xml irfs=P8R3_SOURCE_V3 evtype=32 expcube=lt_summed.fits bexpmap=ext_4FGL_J1409.1-6121e_ecube_CAR.fits outtype=CCUBE edisp_bins=-2
The header of the resulting FITS file, pasted below, is correct "at the top" but is later clobbered by what seems to be the header from the counts cube. (Repeated cards start at 2nd instance of "SIMPLE".) The 2nd entry for BITPIX is 32, and when you use astropy to load this file, it **very incorrectly interprets the map data as integers. ds9, on the other hand, uses the first instance (BITPIX=-32) and thus correctly loads the data as floats.
Now, I don't know what the "correct" behavior is with regards to duplicate cards as far as the FITS standard goes, but it's pretty clear that the 2nd values are incorrect and shouldn't be there, so that's the bug.