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

[Erik Bray]

Great--I'm glad it was as simple as that.

It's on my todo list to specifically detect the case of extra trailing bytes so 
that a more specific error can be raised (or probably just a warning since 
trailing bytes don't make the rest of the file unreadable).

Erik

On 10/30/2014 12:03 PM, Indy Leclercq wrote:
> 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
>