imheader on 64-bit iraf

duvall · Active IRAF User Joined: 08 Mar 2006 Posts: 43

I'm sure this has been addressed, but ...

In the new 64-bit iraf, it seems to require that I have write permission on a .fits image to execute imheader. Message I get in response to imheader data.fits is :

ERROR: No write permission on file (String_File)

What's up with that?
Tom

fitz · Posted: Thu Sep 23, 2010 6:40 pm Post subject:

I'm not seeing a problem:

duvall · Active IRAF User Joined: 08 Mar 2006 Posts: 43

I learned a little more about my problem. It has to do with fits images written by IDL. I've copied one of these images into my local directory so that I'm the owner. But I still get the same error message:

imheader HMIfilter.128.fits
ERROR: No write permission on file (String_File)

If I use head to look at the header:
head HMIfilter.128.fits
SIMPLE = T / Written by IDL: Fri Sep 24 13:23:12 2010
BITPIX = -32 / Number of bits per data pixel
NAXIS = 4 / Number of data axes
NAXIS1 = 12001 /
NAXIS2 = 6 /
NAXIS3 = 128 /
NAXIS4 = 128 /
EXTEND = T / FITS data may contain extensions
DATE = '2010-09-24' / Creation UTC (CCCC-MM-DD) date of FITS header
COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT and Astrophysics', volume 376, page 359; bibcode 2001A&A...376..359H
END

I have tried a couple of different images and the common thing is that they were written with IDL.
Tom

fitz · Posted: Fri Sep 24, 2010 10:18 pm Post subject:

My guess: The files aren't an integer multiple of 2880-byte records or are somehow otherwise corrupted. By my reckoning, the files should be 786502080 bytes.

duvall · Active IRAF User Joined: 08 Mar 2006 Posts: 43

Yes, you are correct about the file size. IDL is apparently writing out some fraction of a 2880-byte record at the end. The older IRAF was tolerant of this 'idiosyncrasy' while the new one is not. I work with a number of IDL users and need to be able to pass images back and forth. And particularly when the file size is too big for the 32-bit limit, I don't currently have any alternatives. Is there some workaround for this? I can complain about the IDL fits writer, but my understanding is that this is a long-standing problem. I guess that I could write an SPP program to rewrite the files with the correct length.
Tom Duvall

duvall · Active IRAF User Joined: 08 Mar 2006 Posts: 43

Oops. Please forget the previous message. I think the file size is correct:

=12001.*6.*128.*128.*4./2880.
1638536.5333333

=1638537.*2880+2880
4718989440.

And this is the file size. As that error message has something to do with strings, the problem must be in the header.
Tom

duvall · Active IRAF User Joined: 08 Mar 2006 Posts: 43

Sorry for the burst of replies. I have found a small image that has the problem that might be amenable to testing. I have placed it in http://sun.stanford.edu/~duvall/Data/filters.fits.
Tom

fitz · Posted: Sat Sep 25, 2010 3:22 pm Post subject:

I can reproduce the problem on a linux system, but not a Mac. I'll get back to you once I track it down.

fitz · Posted: Sat Sep 25, 2010 5:37 pm Post subject:

Hi Tom,

The problem is yet another bug in the FITS kernel: It assumes the DATE keyword is given in the ISO form 'yyyy-mm-ddThh:mm:ss.s", but in your image only the date is given. The time is set to INDEF and when used in a calculation, overflows the value. The message is coming from a routine trying to format the string internally. This is fixed in the upcoming v2.15 release, for now you need to edit the DATE keyword to use the ISO format.

Thanks for the report,
-Mike

duvall · Active IRAF User Joined: 08 Mar 2006 Posts: 43

Mike,
Thanks for the tip about editing the date. hedit does work even if imheader does not and I was able to change the date.
Tom