Ginga cannot open GMOS multi-extension FITS by default

[pllim]

As reported by @gderosa2004, even using the latest dev version . Here is the file info:

>>> from astropy.io import fits
>>> pf = fits.open('ergS20071007S0122.fits')
>>> pf.info()
Filename: ergS20071007S0122.fits
No.    Name         Type      Cards   Dimensions   Format
0    PRIMARY     PrimaryHDU     215   ()              
1    MDF         BinTableHDU     42   750R x 8C    [1J, 1E, 1E, 5A, 1J, 1J, 1J, 1J]   
2    SCI         ImageHDU      1583   (6218, 743)   float32   

This Ginga command

ginga --loglevel=20 --log=ginga.log ergS20071007S0122.fits

gives the following error in the GUI:

Failed to load file 'ergS20071007S0122.fits': too many indices for array
  File ".../ginga-2.5.20151028003943-py2.7.egg/ginga/Control.py", line 571, in load_image
    image.load_file(filepath, **kwdargs)

and in the log file:

2015-10-29 10:41:50,276 | E | Control.py:576 (load_image) | Failed to load file 'ergS20071007S0122.fits': too many indices for array
2015-10-29 10:41:50,300 | E | Task.py:387 (execute) | Task '<ginga.main.Ginga object at 0x7f1304065e50>.task0' terminated with exception: local variable 'image' referenced before assignment
2015-10-29 10:41:50,318 | E | Task.py:391 (execute) | Traceback:
  File ".../ginga-2.5.20151028003943-py2.7.egg/ginga/misc/Task.py", line 377, in execute
    res = self.func(*self.args, **self.kwdargs)
  File ".../ginga-2.5.20151028003943-py2.7.egg/ginga/Control.py", line 690, in load_file
    image.set(loader=image_loader, image_future=future)

2015-10-29 10:41:50,321 | E | Task.py:941 (execute) | Task '<ginga.main.Ginga object at 0x7f1304065e50>.task0' raised exception: local variable 'image' referenced before assignment

DS9 has no problem skipping the table in EXT 1 and opens image in EXT 2 using the following command:

ds9 ergS20071007S0122.fits

However, specifying the extension explicitly in Ginga successfully opens the image:

 ginga --loglevel=20 --log=ginga.log "ergS20071007S0122.fits[2]"

[ejeschke]

There is a possible fix for this in commit 4a9b9bc05c8bb212a3fb90e077ca20c6bee1ffd9. I check the HDU type and pass by those that are not ImageHDU or PrimaryHDU.

Would it be possible to get a copy of this FITS file or a similar one for future testing?

[pllim]

@ejeschke , I emailed your the data file.

[ejeschke]

Thanks, @pllim. I verified that the above commit now opens the file. However, the WCS does not work. Looking into that now.

[ejeschke]

Commit 0c6a3ea031a0468fe126f8d73c1e5f3192abdaab contains a fix so that ginga now recognizes not to do a second conversion to the user's preferred coordinate space (e.g. FK5->galactic) when the coordinate system is "LINEAR" (as shown by the CTYPE in HDU 2 of this data file. It now reports the units returned from the wcs. But the units do not match what ds9 shows. However they do match what I get if I look up pixel coordinates via astropy commands in a python shell.

So I don't know which set are correct. If ds9's values are correct then I think we need to get an astropy wcs guru to check the output of the astropy wcs on this HDU.

[pllim]

@nden, do you handle astropy WCS now? Is this something you can assist with?

[pllim]

@ejeschke, thank you for the fix. I can confirm that Ginga can indeed open SCI extension by default now and automatically skips the table.

[pllim]

@ejeschke, can we close this now that the WCS matter is moved to #205?

[ejeschke]

Yes, I think the basic load issue is solved.