Higher-level interface

[kbarbary]

I'm interested in putting a little work into a higher-level interface for FITSIO, something akin to esheldon/fitsio. If you look at that package, I think the equivalent thing in Julia would be to define types for HDUs such as TableHDU, ImageHDU, and ASCIITableHDU. This would allow you to define indexing operations on the data of an HDU, such as:

f = fits_open_file("data.fits")
f[1]  # returns an HDU instance.
f[1][25:35, 10:20]  # returns a subpatch of the data in the HDU

However, this design seems a little weird to me, because the HDU types would have the same pointer as the main FITSFile instance, and would have to move the current HDU to the correct extension before doing any operation. (Maybe that's not so bad?) It doesn't seem like you can have index notation without defining such types. I guess the alternative would be to have methods like

fitsread(f, 1, 25:35, 10:20)

Any thoughts?

[kbarbary]

cc: @ziotom78

A possibly-related question: Why is the function hdu_int_to_type implemented as a function rather than, say, a dictionary, and why does it return symbols? Is there a way the symbols might be used in performing operations on the HDU?

And while I'm at it, why are _cfitsio_datatype and _cfitsio_bitpix implemented as functions? I presume for performance?

[ziotom78]

Hi @kbarbary,

You're right, probably the best way to implement hdu_int_to_type is to use a dictionary. I decided to return symbols because I am a LISPer and prefer them over strings when there is a function that must return a fixed subset of choices… (Of course, had Julia enumeration types I would have used them instead.)

Regarding your questions about _cfitsio_datatype and _cfitsio_bitpix, I am not the author of these function, so I don't know the answer.

[kbarbary]

Thanks for the reply @ziotom78. I wonder if there is a standard "Julia" way to handle such situations that would be better suited to enumerations? Just curious. The question about _cfitsio_* was more for @nolta so we'll see what he says.

[nolta]

Great, glad you're interested in working on this! I'll take a look at esheldon's api.

I don't remember if there's any deep reason _cfitsio_* are functions. Probably just seemed the best thing to do at the time.

[kbarbary]

I've done a little work implementing a higher-level interface. There's a working demo here:

http://nbviewer.ipython.org/gist/kbarbary/c7eaa69aa1d7c38b81de

You can see the code in my hdutypes branch: https://github.com/kbarbary/FITSIO.jl/tree/hdutypes

So far, only ImageHDU is implemented, and even that has a few missing features. There's also no header-reading functionality yet. But the demo should give the general idea.

[nolta]

Cool, looks neat. If you want to merge it, that's fine with me.

[kbarbary]

Thanks! I'll clean things up a bit and add some docs before merging. Really just wanted to get an initial thumbs up/down on whether you think it should go in eventually.