iraf.net

Hello Alan, The message about [NO PIXEL FILE] reported by imheader is actually
a bug in the imheader task. (It is error number 1 in the buglog:
iraf$local/bugs.log) The message can be ignored, as all IRAF tasks
can access the image pixels. The HDR$ notation means the pixels are in
the same directory as the image header. You can reset imdir to be
HDR$ or a subdirectory of HDR$: cl> reset imdir = HDR$
cl> reset imdir = HDR$pix/In this way, any IRAF task that creates an image will place the pixels
in the same directory as (or subdirectory of) the header. IMFORT tasks
will always place pixels in the header directory; the HDR$ notation is
always seen in an image header created with an IMFORT program. Once the
pixels end up in HDR$, the easiest way to move them to your current "imdir"
is the task imrename. It will rename the image header and move the
pixels as well. Once you've converted your local data format to IRAF images,
you have a choice of how to store the data for easy access by IRAF.
You could store them in tar format (facilitated by having the headers
and pixels in the same or nested directories); you can write FITS format
files with the IRAF WFITS program (even to a Sun cartridge with restricted
block size); or you could write FITS disk images and then tar them to
the cartridge. The method you chose would depend on how permanent a
data archive you want as well as how many different machines you may
be reading the data on. I would recommend FITS format for long term storage of the data
and possible transport from one site to another. I'd recommend tar backups
of IRAF images for efficient, local, short term storage. The IRAF image
format is an evolving format and as such is not a good choice for
permanent archive. See the manual page on WFITS. A modification was made in April 1988
to allow the user to specify the block size in bytes, not necessarily
a multiple of 2880. As the manual page explains, this is a violation of
the current FITS standard, and such a tape will have to be read in by a
FITS reader that also supports the non-standard block sizes (e.g., IRAF).
However, it makes it possible to store FITS format images on the
Sun 1/4" QIC cartridges with their restricted block sizes. The third
possibility is to write FITS disk image and tar them to the cartridge.
This is possible, and was the "work-around" prescribed for Sun cartridge
owners before WFITS could write FITS format with non-standard block sizes.
I see no advantage to this technique except possible transportability to
sites with a FITS reader that doesn't support the non-standard block size. The best choice of these possibilities depends on your requirements.
I'll leave it to you at this point. I hope this is of some help.Suzanne Jacoby
sjacoby@noao.edu
5355::sjacoby or noao::sjacoby
(602-325-9364)
(602-323-4160 IRAF HOTLINE with an answering machine)