[AstroPy] Support for OIFITS, reconstructed images

[Brian Kloppenborg]

At present the OIFITS data format is for storing binary tabular data.
Internally, the data is like a normalized database, so unpacking it to a
single table would result much duplication of data. Today files are
fairly small (< 1MB), so even a 10x increase in size wouldn't be a big
deal, but this will change in the next few years.

My C++ library keeps everything compact and lets the user
filter/merge/sort on OI_DATA objects (stores pointers to duplicated data
quantities), then export to tabular data once they are done. Something
similar to this could be implemented fairly easily in AstroPy. (My
library uses CCFITS and CFITSIO, so simply SWIG/CYTHON-ing the library
probably isn't an option, unless AstroPy wants to distributed those
libraries too.)

Cheers,
Brian

On 04/04/2013 04:21 PM, Perry Greenfield wrote:
> 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.


>
> Perry
>
> 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:
>>
>> http://docs.astropy.org/en/v0.2.1/io/registry.html
>>
>> Then you could do e.g.
>>
>> f = OIFITS.read('some_oifits_file.fits')
>>
>> Cheers,
>> Tom
>>
>>
>> On 4 April 2013 15:58, Brian Kloppenborg <bkloppenborg at gmail.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:
>>> http://fits.gsfc.nasa.gov/registry/oifits.html
>>>> 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.).
>>> 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.
>>>
>>> Cheers,
>>> Brian
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy