iraf.net

Hi all. I am fairly new to IRAF, but have been around other imaging software for a while. I am having a strange inconsistency between IRAF and ds9, specifically with the FITS header after opening the same image via IRAF and directly from ds9. The FITS header when opening using the displ command via IRAF only shows the first 5 lines or so when the header is displayed via ds9. However, when the same image is opened via ds9, the full header is displayed. (see the link below for a screenshot. The header and image on the left came from the image opened via ds9, and the image and header on the right came from displaying the image via IRAF. It is the same file.)

This has some strange consequences, such as a lack of WCS and physical coordinate systems, pixel values and buffer size behavior. I am hoping someone may have an idea how to 'send' the rest of the header info from IRAF to ds9 with each image. Any help would be greatly appreciated.

Thanks,

Timmy

Screen shot of the two images and FITS headers side-by-side. This is the same file opened two different ways. Left via ds9, right via IRAF: http://i.imgur.com/PAHzQM1.png

EDIT: I feel like this may be caused by the different values in the 'bit per pixel' value', but I am unsure in what capacity since my images are 'real' according to the imhe command via IRAF.

IRAF version: 2.16.1
ds9: 7.3b5 (it is a beta, but this issue happened with the 'current' version as well--using the beta at the suggestion of the folks at ds9)
Mac OS X: 10.8.5

This is a long-standing problem with DS9: The display protocol from IRAF sends scaled pixel values and a linear (pixel) WCS along with the image name, the server (DS9) is supposed to open the image itself to get more accurate values but instead simply uses the approximations sent in the protocol and so you get no WCS or actual pixel values. When you display a FITS file standalone, however, the image is actually opened and DS9 then uses the full WCS and true pixel values.

This is something SAO has to fix in DS9, there is nothing on the IRAF side that can be done to change the behavior. As an alternative you could use XImtool (now distributed with v2.16.1) but then lose things like a regions capability. Some tasks (e.g. IMEXAM) will be able to work with an image displayed standalone in DS9 but usually only for basic functions and not in all cases (e.g. when using image cubes or mosaics of various types).

Hi Fitz. Thank you so much for your reply. I have used ds9 for many years (just not via IRAF) and am pretty bummed it has this issue. It seems like this is something that would be a major point to get straight before releasing it. I have briefly booted up Ximtool and so far, it seems like the same issue is still present; physical coordinates are not kept (or even displayed) when using imcopy to make a subimage from a full sized one. I am very unfamiliar with ximtool though, so maybe I just need to keep fiddling with it.
Thanks again,

Timmy

Re: XImtool Note that there are some projections (e.g. TPV and SIP) that aren't supported in the WCS display, or WCS representations that use non-standard keywords (e.g. some DSS images). To verify that it works at all, try using "dev$ypix" as the test image for DISPLAY and you should see ra/dec coords.

Re: DS9 This is the most obvious (and oldest) problem, various other releases have their own issues (e.g. v7.2 breaks cursor readback).