[AstroPy] Fits file missing END card error when END is present in the header

Thu Oct 30 15:35:58 EDT 2014

If you absolutely need to read this without modification and would like to live dangerously, you "may" be able to add the parameter

ignore_missing_end=True

to the fits.open call. I've had this issue before and seem to remember this working out. Its documented here as part of the PrimaryHDU<http://docs.astropy.org/en/v0.4.2/io/fits/api/hdus.html> class, hence I'm not sure if fits.open will pass the parameter down this far or not.

jde

Jonathan D. Eisenhamer
STScI Science Software Branch
eisenhamer at stsci.edu
+1 410 338 5073
g+/gtalk: stscieisenhamer at gmail.com
aim/skype/icq: triccare

http://www.stsci.edu/
http://hubblesite.org/
http://amazing-space.stsci.edu/
________________________________________
From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Indy Leclercq [indy.leclercq at manchester.ac.uk]
Sent: Thursday, October 30, 2014 12:03
To: Astronomical Python mailing list
Subject: Re: [AstroPy] Fits file missing END card error when END is present in the header

Hi Erik,

Thanks for pointing that out – I didn’t make these files myself and after poking around a bit it would seem that there are indeed some extra bytes in the files that don’t open properly. I think that’s what the problem was here – will have to talk to the person who made the files!

Cheers,

Indy

On 30 Oct 2014, at 17:51, Erik Bray <embray at stsci.edu> wrote:

> One suggestion I can offer is that there are some cases where the "missing END
> card" error is a bit misleading (patches welcome to fix this issue). This is
> because there is no way in FITS to know how many HDUs *should* be in a file, so
> if there are extra bytes at the end of a FITS file it will start reading those
> bytes as though it's supposed to be the start of another FITS header. But then
> when it doesn't find an END card before the end of the file it raises that error.
>
> One case I've seen very commonly is if somebody opened in a FITS file in a text
> editor and then closed it again, many editors will append a newline to the end
> of the file. Other cases have occurred where the software that wrote the FITS
> files appended extra bytes incorrectly.
>
> Erik
>
>
> On 10/30/2014 11:39 AM, Indy Leclercq wrote:
>> Hello,
>>
>> I’ve been processing a batch of similar of FITS files in python using astropy
>> 0.4.2 on Mac OSX 10.9, and on one subset of them (with a header in identical
>> format to the others), fits.open throws an error saying that there is a missing
>> END card in the file. Viewing the header in the terminal shows that the END card
>> is there, and as I said before, the routine works fine on files with essentially
>> the same header.
>>
>> Could anyone shed some light on this, or is this a weird bug? I can bypass this
>> with the ignore_missing_end kwarg, but still find it weird.
>>
>> Here are example of working and non-working headers (copied from a terminal more
>> command)
>>
>> This file opens fine:
>>
>> SIMPLE = T / Standard FITS file
>> BITPIX = -32 / IEEE 4-byte float
>> NAXIS = 3 / Number of image dimensions
>> NAXIS1 = 5155 / Size of 1st dimension in pixels
>> NAXIS2 = 1070 / Size of 2nd dimension in pixels
>> NAXIS3 = 376 /
>> OBJECT = 'GALFACTS_S1 Stokes I' / Object name
>> CTYPE1 = 'RA---CAR' / 1st axis type
>> CRVAL1 = 102.050003 / Reference pixel value
>> CRPIX1 = 2578.00 / Reference pixel
>> CDELT1 = -0.0166667 / Pixel size in world coordinate units
>> CROTA1 = 0.0000 / Axis rotation in degrees
>> CTYPE2 = 'DEC--CAR' / 2nd axis type
>> CRVAL2 = 0.000000 / Reference pixel value
>> CRPIX2 = 53.25 / Reference pixel
>> CDELT2 = 0.0166667 / Pixel size in world coordinate units
>> CROTA2 = 0.0000 / Axis rotation in degrees
>> CTYPE3 = 'FREQ' / 3rd axis type
>> CRVAL3 = 1524717952.000000 / Reference pixel value
>> CRPIX3 = 1.00 / Reference pixel
>> CDELT3 = -420000.0000000 / Pixel size in world coordinate units
>> CROTA3 = 0.0000 / Axis rotation in degrees
>> EQUINOX = 2000.00 / Equinox of coordinates (if any)
>> BUNIT = 'Kelvin' / Units of pixel data values
>> END
>>
>>
>> But this one doesn’t:
>>
>> SIMPLE = T / Standard FITS file
>> BITPIX = -32 / IEEE 4-byte float
>> NAXIS = 3 / Number of image dimensions
>> NAXIS1 = 6000 / Size of 1st dimension in pixels
>> NAXIS2 = 1074 / Size of 2nd dimension in pixels
>> NAXIS3 = 376 /
>> OBJECT = 'GALFACTS_N4 Stokes I' / Object name
>> CTYPE1 = 'RA---CAR' / 1st axis type
>> CRVAL1 = 335.000000 / Reference pixel value
>> CRPIX1 = 3000.50 / Reference pixel
>> CDELT1 = -0.0166667 / Pixel size in world coordinate units
>> CROTA1 = 0.0000 / Axis rotation in degrees
>> CTYPE2 = 'DEC--CAR' / 2nd axis type
>> CRVAL2 = 0.000000 / Reference pixel value
>> CRPIX2 = -1181.50 / Reference pixel
>> CDELT2 = 0.0166667 / Pixel size in world coordinate units
>> CROTA2 = 0.0000 / Axis rotation in degrees
>> CTYPE3 = 'FREQ' / 3rd axis type
>> CRVAL3 = 1524717952.000000 / Reference pixel value
>> CRPIX3 = 1.00 / Reference pixel
>> CDELT3 = -420000.0000000 / Pixel size in world coordinate units
>> CROTA3 = 0.0000 / Axis rotation in degrees
>> EQUINOX = 2000.00 / Equinox of coordinates (if any)
>> BUNIT = 'Kelvin' / Units of pixel data values
>> END
>>
>> Thanks for any help you could provide!
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20141030/d728b00b/attachment.html>