float decimal format not understood by astropy.io.fits

[embray]

When trying to read data in a fits file I got the following error, while old good pyfits understood data types correctly.

from astropy.io import fits
f = fits.open('file.fits')
f[0].data
$> Format 'F9.0' is not valid--field width and decimal precision must be positive integers

Is there a fix or workaround? Many fits files uses this convention.

[embray]

Hmm, definitely sounds like a bug. I don't know what the last version of pyfits you used was, but IIRC the code that's parsing these ASCII table format specifiers is relatively new--I need to check back and see if this bug is in pyfits too.

[embray]

Yeah, I'm not sure what I was going off of when I wrote that, but there's no reason the precision field should be non-zero (the standard is a little unclear about this, but I don't see any reason it shouldn't be allowed)

[embray]

Attached a fix for this, hopefully for inclusion in v1.0. Also fixed a minor formatting issue regarding zero-precision fields that I noticed in reading the FITS standard. As far as I can tell it strongly wants us to write a decimal point for float-valued fields, even if there are no digits after the decimal point.

[embray]

Just as a suggestion for a possible workaround (though I haven't tried it) is to change the the column's format string before reading in the data. For example:

>>> hdul = fits.open('path/to/file.fits')
>>> table = hdul[1]
>>> table.header['TFORM1'] = 'F10.1'
>>> table.data

or some variation thereof might work. The bug here only occurs if the "precision" part of the format is zero. But for the purposes of reading in the data it should still work if you change the precision part of the format.

[eteq]

This looks good to me. And it is a bug fix so fine for v1.0

@toastmaker, can you test this to make sure it works for your file? If we're ready for an RC and you still havn't had a chance to test, we can merge this and there can always be another PR.

[embray]

A sample file would definitely be nice.

[landscape-bot]

Repository health increased by 0.00% when pulling 8662812 on embray:fits/issue-3422 into 6d296b9 on astropy:master.

• 2 new problems were found (including 1 error and 1 code smell).
• 3 problems were fixed (including 1 error and 1 code smell).

[eteq]

I'm going to go ahead and merge this so we can include it in an RC, but a sample file would still be useful, @toastmaker - we can always add it later.