[AstroPy] Co-ordinating Python astronomy libraries?

Perry Greenfield perry@stsci....
Sun Jul 18 14:55:54 CDT 2010


I don't disagree with any of this. I think the idea that data should  
have an intrinsic means of mapping to real coordinates is a perfectly  
good abstraction. Of course FITS wcs can complicate that with multiple  
WCS representations and the like, but for most things, people wouldn't  
need to know the details. There are messy details behind the scenes  
though, like when taking slices and such and making sure the WCS is  
properly updated for such things.

As for pure python vs wrapping libraries, I agree as well. Some C  
libraries are limiting in what they allow for good python object  
representations. I don't know if that is going to be an issue with WCS  
or not (and I've been making similar arguments very recently in a  
different setting, believe it or not). The existing WCSLIB isn't a bad  
place to start, but I wouldn't rule out eventually replacing it with a  
pure python implementation. It's probably not the highest priority  
thing to do unless we find some intrinsic limitation that really has  
to be removed though.

Perry

On Jul 18, 2010, at 3:16 PM, Erik Tollerud wrote:

> I definitely agree that settling on a standard WCS library is a very
> good idea, and PyWCS seems the natural choice as the base to merge
> other work into.  But I also think there's two levels to think about
> for a WCS library - there's the level that has already been
> implemented in a few different places as essentially python wrappings
> around other WCS libraries  But then on a higher level, there's tying
> this into other classes so that, if you don't want to think about WCS,
> you shouldn't have to.  You should be able to do something like
>
> wcs = WCS('myamazingdata.fits')
> im = CCDImage(wcs)
> im.plot()
>
> or just
>
> im = CCDImage('myamazingdata.fits')
> im.plot()
>
> or the like, and have the WCS class automatically take care of
> figuring out everything about the coordinates of the resulting plot.
> The user should be able to access the WCS details if they want to, but
> it shouldn't be necessary, assuming the file matches the WCS standard.
> Now this could well be two seperate independent packages (the
> ccd-related one, and the WCS library), but I think it's important to
> consider this as a major target for the interface at the WCS level.
>
>
> I also think (along with other cases) show why it is not necessarily
> good enough to think of these tools as unix-like/fully modular
> separate pieces that can operate independent of each other. To make a
> really useful class-based library, the classes need to all recognize
> each other when they naturally should.  E.g. you should be able to use
> spectrophotometric data to calibrate photometry, if you want, or use
> photometric results to calibrate your spectra.  Hence, they can't live
> in totally segmented worlds.  Further, you get a lot of user-level
> gains by using consistently the same tools to do similar tasks.  For
> example, I wrote a "models" module in astropysics to do all
> function-fitting, and a "fitgui" to go along with it, so whenever you
> need to fit a 1D function, it always uses the same class to do it, and
> the user in principle only needs to learn the interface to that class
> once.
>
> Now it might be that it's a better solution to write very simple
> interfaces for classes like spectra and images with essentially only
> low-level access to the data, and leave it to other packages to do all
> the thinks I'm talking about above that inter-link them.  But at some
> level, the constructs are all going to need to be linked together for
> many astronomical applications.
>
> And as for the pure python vs. C wrapping question:  I definitely
> agree that if there is a pre-existing non python module out there to
> do the task, wrapping is much easier and there's no reason not to use
> it if it can be reasonably easily wrapped in python.  But if there
> exists a pure-python version that is comparable in speed for the
> typical applications, I would say that's a better choice, because it
> allows for much greater flexibility.  If you want to subclass
> something based on a C library, the subclass will almost always be
> useless because it will be far too slow in python because the rest of
> the module is built in C and the translation to python constructs will
> either slow things down, or just not be available to optimize a python
> subclass. But the optimizations of a pure-python module have to be in
> place for it to work at all.  Of course, it's absolutely right that
> there has to be careful checks that everything was done correctly in
> the python implementation before it can actually be released as
> official, but I think pure python is the goal, given enough time or
> effort.
>



More information about the AstroPy mailing list