imheader on 64-bit iraf
Tom Duvall wrote on Sep 23, 2010
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
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
Mike Fitzpatrick wrote on Sep 23, 2010
I'm not seeing a problem:
Checking the code itself, the image is mapped READ_ONLY.
Is it maybe the case that the image has a bscale/bzero and the problem is that you don't have write permission in the current directory or /tmp?
ecl> imcopy dev$pix zz.fits
dev$pix -> zz.fits
ecl> !chmod 444 zz.fits
ecl> ls -l zz.fits
524 -r--r--r-- 1 fitz wheel 532800 Sep 23 11:28 zz.fits
ecl> imhead zz.fits
zz.fits[512,512][short]: m51 B 600s
Checking the code itself, the image is mapped READ_ONLY.
Is it maybe the case that the image has a bscale/bzero and the problem is that you don't have write permission in the current directory or /tmp?
Tom Duvall wrote on Sep 23, 2010
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
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
Mike Fitzpatrick wrote on Sep 23, 2010
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.
Tom Duvall wrote on Sep 23, 2010
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
Tom Duvall
Tom Duvall wrote on Sep 23, 2010
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
=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
Tom Duvall wrote on Sep 23, 2010
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
Tom
Mike Fitzpatrick wrote on Sep 23, 2010
I can reproduce the problem on a linux system, but not a Mac. I'll get back to you once I track it down.
Mike Fitzpatrick wrote on Sep 23, 2010
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
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
Tom Duvall wrote on Sep 23, 2010
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
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
Last post on Sep 23, 2010