FITS table viewer

[pllim]

Someone was looking for something that can replace fv FITS Viewer, which has a table viewer. I'm just wondering if Ginga is the right package for such a thing, or is it out of scope?

I did a test with a sample FITS file that has the following structure (in reality, it can be a lot more extensions with multiple images and tables, and the tables can have many different columns each):

Filename: simple_im_tab.fits
No.    Name         Type      Cards   Dimensions   Format
0    PRIMARY     PrimaryHDU       4   ()              
1                ImageHDU         7   (100, 100)   float64   
2                BinTableHDU     12   3R x 2C      [20A, E]   

When I use MultiDim and select the table extension, I get the following errors from Ginga:

2016-09-03 08:33:03,961 | E | MultiDim.py:446 (set_hdu) | Error loading FITS HDU #2:
    too many indices for array

[ejeschke]

I think such a plugin would be fairly easy to write, based on the table widget and astropy table support. We don't have a strong need for that with our current instrument set though, and I don't have any spare time to put into writing one. @pllim, would you be interested?

[pllim]

@ejeschke , I am definitely interested but don't have time immediately. Perhaps in a few weeks if no one else gets to it first.

[pllim]

@ejeschke , I thought about this a bit more. Ideally, the table would be displayed where the image usually is. But wouldn't that require hacking AstroImage to also handle FITS table? Was that what you had in mind as well? If that is the case, then the name AstroImage no longer accurately reflects the things that it can do, as it is not longer limited to handling just images.

[ejeschke]

No, shouldn't require modifying AstroImage at all. It's just like when you start WBrowser, you can see that it starts a plugin in the central workspace instead of the right workspace. That's all.

[pllim]

Ideally, I would want to utilize Datasrc for the table object. I haven't look at the code in a few months, so I don't immediately know if that is possible without modifying AstroImage.

[ejeschke]

Datasrc can hold any kind of objects. So instead of AstroImage objects, you could put astropy tables, or wrapped tables, etc.

Do you want tables to show up with thumbnails, etc. sort of just like images? That probably would require a little more hacking to Thumbs, etc.

[pllim]

That's good to know, thanks! Thumbnail for a table is probably an overkill, but perhaps showing a blank thumbnail anyway would be helpful for selecting the table from Thumbs plugin.

[josePhoenix]

There's a nice-to-have feature that I feel I should mention here since it may influence how you design the interface, even if it's not in the first version of such a plugin. Some bintables, notably Kepler target pixel tables, have image-valued columns. Depending on how Astropy table support is implemented, that could be complicated to add in a plugin, but I thought I should mention it as that's the main thing I use fv for these days.

[pllim]

@josePhoenix , doesn't Kepler has its own software for its data? Unless JWST also uses such format, it is hard to justify such implementation. Good to know, but probably won't be implemented as first pass.

[josePhoenix]

No, they recommend using FITSView

[ejeschke]

It would be fairly straightforward to open binary image objects, I think. I assume they would just be read in as numpy arrays (maybe astropy supports this already?) . If you didn't want to manage those in the usual channel organization they could be displayed in a simple plugin in the right panel that basically consists of another ginga widget.

The question is whether you want to manage those images as other "top-level" images (i.e. track them in channels, display in Thumbs and Contents, etc.

[pllim]

@josePhoenix , is that Kepler table readable by Astropy Table?

[josePhoenix]

Just tried it now. Looks like no, but it's not obvious why. Here's an example: http://archive.stsci.edu/missions/k2/target_pixel_files/c7/213400000/90000/ktwo213490088-c07_lpd-targ.fits.gz

[pllim]

I'm guessing it's because of the embedded image. IMHO, Kepler data should first be readable by Astropy first before anything else. Maybe you can open an issue over at Astropy.

[pllim]

@josePhoenix , if Kepler data is too particular for general package like Astropy, another option would be for the Kepler software team to write a custom loader of some sort in Python. My point is the loader should be outside any graphics package.

[pllim]

Please see #369 for a possible solution. Thanks!

[ejeschke]

Please see #369 for a possible solution. Thanks!

That was fast!

[ejeschke]

@pllim, please see PR #370 as an alternate implementation for this issue. Let me know your thoughts.

[pllim]

Added in #370.