[user feedback] image HDU not recognized

[kswang1029]

Describe the bug
This is a user feedback via the Helpdesk.

In the latest version of CARTA (installed from the cartavis.org website earlier this week), I'm unable to open a FITS file that I was previously able to open in CARTA 2.something. This week I've been visiting John Hibbard at the NRAO in Charlottesville and he recommended I email you.

Attached I've provided a screenshot of the problem. On the right you can see the CARTA window where I'm trying to open the FITS file and it claims there are no image HDUs. On the left, I have used fits in astropy.io to open the file and see that there are two extensions: a primary extension and an image extension. I also print out the full header for the primary, and the first 50 header entries of the image extension. The file is quite large, so it would be difficult for me to share it with you, but if the solution isn't immediately obvious from my screenshot and you need the file, I could start by sending you an empty FITS file that just contains the header information?

Expected behavior
Can load the image as in v2

Screenshots or videos

I tried with one of our test images with multiple HDUs and it works as expected.

In [1]: from astropy.io import fits

In [2]: hdus = fits.open('spire500_ext.fits')

In [3]: hdus.info()
Filename: spire500_ext.fits
No.    Name      Ver    Type      Cards   Dimensions   Format
  0  PRIMARY       1 PrimaryHDU     164   ()      
  1  image         1 ImageHDU        53   (830, 870)   float64   
  2  History       1 ImageHDU        23   ()      
  3  HistoryScript    1 BinTableHDU     39   117R x 1C   [300A]   
  4  HistoryTasks    1 BinTableHDU     46   88R x 4C   [1K, 27A, 1K, 9A]   
  5  HistoryParameters    1 BinTableHDU     74   718R x 10C   [1K, 20A, 13A, 46A, 1L, 1K, 1L, 74A, 11A, 41A]   
  6  error         1 ImageHDU        53   (830, 870)   float64   
  7  coverage      1 ImageHDU        53   (830, 870)   float64   

[kswang1029]

A test image is made based on the image header that the user supplied. The root cause is that the following two header entries messed up the header parser:
CUNIT1A = 'PIXEL '
CUNIT2A = 'PIXEL '

If we remove those two entries, the image can be loaded.

dice_one.fits.zip

[veggiesaurus]

so the WCS is incorrect, but does that mean we shouldn't be able to load the image in pixel coordinates? 🤔

[kswang1029]

so the WCS is incorrect, but does that mean we shouldn't be able to load the image in pixel coordinates? 🤔

The intrinsic unit is degree which is fine (that’s why if we remove those it loads and loads fine). For some reasons, CUNIT1A is interpreted as CUNIT1 so PIXEL is not valid for CTYPE1=RA—-TAN.