[AstroPy] PyFITS 0.6.2 available

[Clive Page]

On Thu, 28 Feb 2002, Perry Greenfield wrote:

> I'm not sure I can go into a detailed comparison but I will outline
> many of the reasons we decided to go a different way (albeit more costly
> in development costs). I haven't used pCFITSIO so I may inadvertently
> misrepresent some things; I hope Nor will correct me in such cases.

Perry

Thanks for your very instructive posting.  I now fully understand your
motivation.  I have been happily using CFITSIO for many years and have
made some attempts to put a higher level interface on it, but with limited
success.  But you face the problem that CFITSIO already has support for a
host of features that people already use in their C and Fortran programs,
and will expect in PyFITS.  For example:

- scaling using BZERO/BSCALE in images and tables (I note that's on your
list of things to do soon)

- full support for null values in all data types (and IEEE special values
in floating-point cases)

- support for vector columns and variable length arrays in BIN tables

- almost transparent access to ASCII and BINARY tables (I will I didn't
have to put that "almost" there).

- support for long string keywords (comments flowing over several lines)

- support for units in keyword comments

- support for arrays of strings (rA:SSTRw/nn convention and an earlier
one)

- syntax to filter tables from command-line using row expressions etc

- access to FITS files over the net using FTP and HTTP

- automatic data type conversion in many cases

- support for HIERARCH keyword convention.

- support for automatic decompression of compressed files

Now I have only ever used about half of these, but I suspect other FITS
programmers have used a different subset, so PyFITS will need to support
rather a lot to keep the majority of users happy.  That could be quite a
lot of work.

> 3) It is not possible to memory map FITS files in CFITSIO.

I can see that memory mapping is desirable in many areas.  But I have some
reservations.  I have past experience of using the Starlink HDS library,
which relied on memory mapping.  But there is a downside if you run out of
physical memory - the system reads your file and then pages it to disc,
usually another disc.  So each logical read turns into a physical read, a
write, and another read, and efficiency drops catastrophically.  There is
another problem: here in the XMM-Newton project we use a FITS
infrastructure (built in top of CFITSIO) which always reads each input
file to memory before doing anything with it.  Just last month we came
across our first FITS file which exceeded the memory addressing limits of
Solaris 2.6 (2 GB I think); our only solution may be to move to a 64-bit
verison of the operating system.

Regards

-- 
Clive Page,
Dept of Physics & Astronomy,
University of Leicester,    Tel +44 116 252 3551
Leicester, LE1 7RH,  U.K.   Fax +44 116 252 3311

_____________________________________________________
AstroPy mailing list  -  astropy at stsci.edu
http://lheawww.gsfc.nasa.gov/~bridgman/AstroPy/