iraf.net

Hello,I'd like to report an issue I have discovered when changing the INHERIT keyword in MEF fits files. When I set the value of the INHERIT keyword in the DQ extension from "F" to "T" and then back to "F" again, I get an "ERROR: Pixel storage file is truncated" error when I try to copy / display / etc the DQ extension.I have put a short script (script.cl) and a fits file (flat.fits.tar.gz) that can be used to reproduce the problem at ftp.gemini.edu:/pub/.It appears that when the value of INHERIT is set to "T" in the DQ extension, the keywords from the PHU are actually copied into the header of the DQ extension, but when INHERIT is set back to "F", the keywords remain in the header of the DQ extension. I think that maybe when INHERIT is set back to "F", the header size is decreased, but because the keywords remain, they no longer "fit" in the header. So, some of the pixel data is taken up with the header, which then causes the "Pixel storage file is truncated" error.There are more detailed comments in script.cl.I am using v2.14 of IRAF on redhat.If you need any more information, please let me know Many thanks,Emma

Sorry, that wasn't supposed to be a link, that was supposed to be "ftp into ftp.gemini.edu and then cd to /pub and get the files from there" Thanks!

The gemini ftp archive might not be publicly visible, I can get to it but it appears empty. Could you instead post your script to the anonftp archive at ftp://iraf.noao.edu/pub so I can look?Otherwise, the preferred method to change the inherit behavior is by using it in the kernel extension. The FITS kernel does read the file to get the various offsets and structure information and changing the value may affect the way the file is written out when done. I'd have to see how you were doing this to comment further but I'm not sure whether changing the INHERIT keyword is a bug or just a bad idea.-Mike

Hi Mike,You can't list the contents of /pub at ftp.gemini.edu ... all the files are hidden. You just need to know the names of the files (script.cl and flat.fits.tar.gz) to be able to "get" them ... they are there, promise Emma

Sneaky. Anyway, got the files, will get back to shortly.

Emma,I can reproduce the problem, but is there a real-world reason why you're manually changing the INHERIT keyword rather than simply copying/referring to the extension using e.g.[code:1:b9841a03c1]cl> imcopy foo.fits[DQ,inherit-] bar.fits[/code:1:b9841a03c1]The problem with changing inherit from 'F' to 'T' manually is that there's no reliable way to automatically know which keywords belong in the PHU such that they still apply to the other extensions correctly. I agree the kernel shouldn't choke the way it does with a pixel truncation error, but it's a bit like manually changing the NAXIS keywords to resize the image, and the least of your problems if you're corrupting the headers.Can't you use the 'inherit' kernel parameter to do what you need? If not, why not?-Mike

Hi Mike,Thank you for your quick reply. I had already changed the code to what you had suggested I just thought that getting the "Pixel storage file is truncated" error was a horrible bug and that you should know about it Comparing the INHERIT keyword to the NAXIS keyword has made me understand why we shouldn't change the INHERIT keyword Thank you for your help!Emma