iraf.net

Hello,I have an image that was created with IDL. When I display the image in skycat or ds9 (outside of IRAF) everything seems to normal, e.g. the pixel ranges are normal.When displayed in ds9 via IRAF the pixel values become hugely negative. The same is shown when doing imstat on the image.skycat reports BITPIX=-32 but IRAF doesn't find the same. Using hselect to get the value of BITPIX returns nothing, and searching through the header shows there is no keyword for BITPIX. Yet reading in the header information through IDL shows that BITPIX=-32.Is there someone who could look at the image for me and see what is going wrong?Cheers.

BITPIX is a keyword required by the FITS standard, it could just be that DS9 and skycat are using -32 as a default. In any case, you can use the IMHEAD task to see what iraf thinks the image is, and turn on the 'long' param to see the whole header. Post this output or feel free to upload the image to the anonftp archive at ftp://iraf.noao.edu/pub and I'll have a look.-Mike

Hi Mike,I have looked at the header with imhead and it says the pixel type is real but doesn't have the BITPIX keyword.The really weird thing is that I can't seem to add the BITPIX keyword to this image. I have tried, with hedit, to both update the keyword and add the keyword. In neither case does the keyword appear when examining the header with imhead nor does hselect return a value. The pixel values, however, do change.I have put the image, cutout_r_0153170101.fits, on the anonftp site.Thanks for looking at this for me.Craig

I had a look at the image. It in fact has two BITPIX keywords in the header, both with -32 values indicating a floating point image. It also has a BSCALE and BZERO keyword, and the BZERO=32768.The problem is, the FITS kernel doesn't support scaling on real images for some reason, and it appears to be misinterpreting the pixel values as a result. You can't use the image as is, however it is easy to fix by deleting the BSCALE/BZERO keywords with HEDIT, then use IMARITH to add 32768 to get the proper pixel values. I don't remember the reasoning for not supporting scaling on real images, but I'm reluctant to change it without more investigation.-Mike

Hi Mike,I opened the fits file in emacs and you are right, there are two BITPIX keywords. That probably happened because I was trying to add the keyword, with hedit, after I couldn't see it in the header (using imhead <file> l+) and because hselect didn't return any value.I have looked at the original image, with emacs, and there is only one BITPIX keyword, but still it doesn't show up in the header and hselect doesn't return a value. Do you know why this would happen? Why IRAF can't find that keyword when it is there? Is it supposed to be hidden?Anyhow, I did what you suggested and now the images display better. Thanks!

Some FITS keywords like BITPIX, NAXIS, etc don't show up in the header listing which prints only the "user area" of the header. It would be an error if they weren't present, but the values show up in other ways (e.g. an IMHEAD reporting the image as 'real').
-Mike

As was already mentioned, some core keywords are hidden from the user and applications because they must be managed by the FITS kernel (a low level layer in IRAF). Some of this is also due to the IRAF abstraction of an image so that IRAF can support multiple image types (e.g. imh vs fits). However it is certainly sometimes desirable to see the full FITS header. The FITSUTIL package (currently an add-on package) is useful for this with the FXHEAD task.As for scaling of real valued data, I would have to check but I think the standard only uses BSCALE/BZERO on integer images. This was the original FITS format where only integers were allowed and the scaling parameters were used to represent real values. Later the standard was extended to have IEEE floating point by the (kludgy) method of negative BITPIX values. Having a native floating point format in FITS obviates the need for scaling.Yours,
Frank Valdes