[AstroPy] Support for OIFITS, reconstructed images
Thu Apr 4 09:21:42 CDT 2013
I think it is mostly visibility data which doesn't fit an image model very well. It's possible that some sort of table could handle it though. They may want a table that supports operations that are usually done with visibility data so that may mean a significant amount of customization of tables.
On Apr 4, 2013, at 10:08 AM, Thomas Robitaille wrote:
> I am not familiar with the OIFITS standard, but if the contents can
> basically be represented by a sub-class of a Table or NDData object,
> you could develop that sub-class, then add a reader/writer for that
> sub-class using the existing I/O infrastructure:
> Then you could do e.g.
> f = OIFITS.read('some_oifits_file.fits')
> On 4 April 2013 15:58, Brian Kloppenborg <email@example.com> wrote:
>> Hi Perry,
>> On 04/04/2013 01:59 PM, Perry Greenfield wrote:
>>> 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).
>> Indeed, although developed under the auspice of IAU working group 54 it
>> is just a registered FITS convention:
>>> 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
>> Indeed, astropy.io.fits can read and write these files already, I would
>> like to see a more convenient interface to OIFITS files merged into the
>> AstroPy library. This is something that I would do, rather than asking
>> other developers. The process by which this is done (which you explain
>> below) is what I was after.
>>> 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.
>> Thanks. I'll check out these documents and get coding. I'll take the
>> SWIG/Clang question to them as well.
>> AstroPy mailing list
> AstroPy mailing list
More information about the AstroPy