Adding FITS convenience function to Ginga util

[pllim]

I have been using this in my Ginga plugins to find and load an extension of interest in my multi-extension FITS images:

from astropy.io import fits 

def fits_extnamever_lookup(filename, extname, extver):
    """Return ext num for given name and ver."""
    extnum = -1
    with fits.open(filename) as pf:
        for i, hdu in enumerate(pf):
            if hdu.name.startswith(extname) and hdu.ver == extver:
                extnum = i
                break
    return extnum

This is because sometimes (DQ, 1) is in extension 2, sometimes in extension 3, which is beyond my control.

There are 2 ways we can do this:

1. If there is already a way for Ginga FITS file handlers to open an extension by (extname, extver) pair instead of extnum only, then this is unnecessary (I couldn't find such functionality when I looked, but I could have just missed it).
2. We can add this somewhere in ginga.util.io_fits module. Since you have two different FITS file handlers, it is not obvious to me what would be the most elegant way to implement this in a way that I do not break existing behaviors.

[ejeschke]

I think we ought to follow astropy's conventions for this; namely, that you can tack on [name, ver] to the path and it will do the right thing. And ideally these parameters just get passed to index into the astropy HDUList in the opener . The fitsio opener should also be modified to allow the syntactical convention, as best as we can do it.

[pllim]

Actually, this lookup function might still be useful, depending on how flexible you want Datasrc dictionary lookup to be. Currently I have to convert, say, image.fits[('DQ', 1)] to image.fits[3] so I can grab the cached data using chinfo.datasrc['image.fits[3]'].

[ejeschke]

@pllim, can you try commit 593c2fc50ca47b96b4020ec8a9fe108725560ef6? This adds support for loading by (extname, extver). This also adds support for the image name so that the data src should contain a reasonable name for it.

Note that MultiDim is still not updated (yet) to open the HDU by this method (it is still using straight indexes), so you might need to keep your function around for a bit longer. But I think it can be refactored to open them via (extname, extver) so that you get more reasonable names in the Contents and Thumbs.

[pllim]

@ejeschke , the latest version broke MultiDim (as you pointed out?) and some of my plugins. This is because the keys in Datasrc changed from

['image1[1]', 'image2[1]', 'image1[3]']

to

['image1', 'image2', 'image1[3]']

[pllim]

Update: I updated #176 with the fix.

[pllim]

This is fixed.

[ejeschke]

@pllim, I've added a change that you may find very useful. When you create an AstroImage object, you can give it a name kwarg parameter. This name will be used in preference to anything the loader does. So essentially you have full control over the image names used in the Datasrc, and that show up in the plugins.