Problem with FITSIO high level interface

[sherrinm]

I have had problems with reading the header of an M31 Andromeda FITS file - which was part of my wife's S177 UK Open University Astronomy project - using the HIGH level routines

The file is from the http://www.spacetelescope.org (NASA/ESA Hubble Space Telescope) so has reasonably parentage :

http://www.spacetelescope.org/static/projects/fits_liberator/datasets/m31/f001a066.zip

using FITSIO cd ("S177")

f001a = FITS("f001a066.fits") file: f001a066.fits mode: r extnum exttype extname 1 image_hdu

size(f001a[1]) (7055,7055)

data = read(f001a[1]); data[7055,7055] 29976

header = readheader(f001a[1]) ERROR: couldn't parse keyword value: "1.9511305786508E+00," in parse_header_val at /Users/malcolm/.julia/v0.3/FITSIO/src/hdutypes.jl:161 in readheader at /Users/malcolm/.julia/v0.3/FITSIO/src/hdutypes.jl:204

The keyword value has a trailing ',' which throws the error in parse_header_val

Using the LOW level API gave no problems:

f001 = fits_open_file("f001a066.fits") n = fits_get_hdrspace(f001)[1] for i = 1:n println(fits_read_keyn(f001,i)) end

Looking at the header from a LOW level data dump, the problem is with the SKEW value but I suspect it is actually the entry above which has no key or value, just a comment, which I suspect is the real culprit

("CROTA1","1.9373114911858E+00","Rotation angle of first axis (deg)") ("CROTA2","1.9373114911858E+00","Rotation angle of second axis (deg)") ("","","Warning: CROTA2 is inaccurate due to considerable skew") ("SKEW","1.9511305786508E+00,","1.9234924037208E+00 /Measure of skew")

A work around in the parse_header_val routine (my hack-- I am a reformed Perl programmer after all) was :

function parse_header_val(my_val::String) if length(my_val) == 0 return "" end val = (my_val[end]==',') ? chop(my_val) : my _val try return int(val)
etc....

But clearly a fix is better in reader header() to ensure that the values don't have trailing ',' or other nasty characters to begin with.

[kbarbary]

I don't think the warning comment above is a problem here.

Looking at the raw header,

[...clip...]
        Warning: CROTA2 is inaccurate due to considerable skew                  
SKEW    =  1.9511305786508E+00,  1.9234924037208E+00 /Measure of skew           
CDELT1  = -2.8324823369599E-04 /RA pixel step (deg)                             
[...clip...]

it looks like the intended value was actually two numbers. (I'm almost certain that this header record doesn't follow the FITS standard, by the way...) CFITSIO still parses it, but not as intended, assigning the second number to be part of the comment rather than the value. Since we're not going to get the intended value anyway, I think the best thing to do in parse_header_val is probably just to return the string "1.9511305786508E+00," rather than raising an error. I'll look into making this change. (We might also have to move to saving the raw unparsed header cards in FITSHeader so that we can write the header back out identically to how it was read in.)

[sherrinm]

True that it might not follow the standard

BUT

1. It comes from a NASA/ESA source, so hardly an unusual source
2. The low level API can deal with it
3. There may be more out there, this is the FIRST I looked at.

On 27 March 2015 at 17:31, Kyle Barbary notifications@github.com wrote:

I don't think the warning comment above is a problem here.

Looking at the raw header,

[...clip...] Warning: CROTA2 is inaccurate due to considerable skew SKEW = 1.9511305786508E+00, 1.9234924037208E+00 /Measure of skew CDELT1 = -2.8324823369599E-04 /RA pixel step (deg) [...clip...]

it looks like the intended value was actually two numbers. (I'm almost certain that this header record doesn't follow the FITS standard, by the way...) CFITSIO still parses it, but not as intended, assigning the second number to be part of the comment rather than the value. Since we're not going to get the intended value anyway, I think the best thing to do in parse_header_val is probably just to return the string "1.9511305786508E+00," rather than raising an error. I'll look into making this change. (We might also have to move to saving the raw unparsed header cards in FITSHeader so that we can write the header back out identically to how it was read in.)

— Reply to this email directly or view it on GitHub https://github.com/JuliaAstro/FITSIO.jl/issues/24#issuecomment-87023646.

[kbarbary]

Sorry if it wasn't clear: I was agreeing that we should do the best we can to try to read it, even though it is non-standard. The high-level interface is clearly not doing the best it can and should be fixed.

[kbarbary]

With #25, you should now be able to read the header. However, as discussed there, we're not trying to parse the value at all. For discussion about parsing non-standard values or fixing non-standard header records in general, I think we should open a new, more specific, issue.