[AstroPy] Support for OIFITS, reconstructed images
Thu Apr 4 06:59:40 CDT 2013
On Apr 4, 2013, at 4:58 AM, Brian Kloppenborg wrote:
> I do optical/NIR interferometric image reconstruction. I have two questions relating to how I should get some of our needs supported in AstroPy:
> First, the data from our instruments comes in an IAU-sanctioned extension of the FITS data format called OIFITS ( http://www.mrao.cam.ac.uk/projects/OAS/oi_data/oifits.html). There is a standard C library (which uses CFITSIO) for reading/writing these files, but it is very non-pythonic. What would be the best way get support for OIFITS into the AstroPy framework? Should I write something from scratch using astropy.io.fits (I've already written a new C++ library on top of CCFITS, which addresses several inconvenient CFITSIO access methods) or integrate a SWIG/CLANG wrapper over the existing C-based OIFITSLIB?
> Second, our image reconstruction methods produce FITS images that are a few milliarcseconds across (our highest formal angular resolution is ~0.3 mas, but we reconstruct with pixels that are ~10x smaller), but do not have any good coordinate information. All we know with confidence is the size of a pixel (we define it); North is up, and East is to the left. What information should we store within the images to make their use within AstroPy/APLpy easier?
Before that can be answered well, it needs to be outlined what such support of this convention entails (to be clear, it's not an IAU standard, but only a registered convention as far I see from the link you provided). Presumably the astropy.io.fits can read these files already, so I'm guessing you want a more convenient object returned than the usual FITS structures (there isn't any new kind of extension, is there?). If that's the case, the people who use these objects should be the ones to design them. Are you asking us to implement this, or are you asking how to add your code to astropy? (You can infer that I'd prefer the latter; most of the existing contributors have higher priorities for development.). I'd say that coming up with working code in Python that does this is the first step, and to make that code compatible with the astropy guidelines for coding style, dependencies, tests, and documentation. Eventually this would result in a pull request to have it merged into the astropy core if it seemed to have good support in the relevant community.
If you have questions about the best way to do the implementation, I think the astropy-dev mailing list is a good place to start.
More information about the AstroPy