iraf.net

Dan,> We have written some fortran programs for doing IRAS sort of things
> to IRAF images. However, we often need to set pitxxx pixels to
> deleted data values (also known as BLANK in the header language
> of FITS). We have been unable to find intehxxxx in the manuals
> how to set a pixel ina .pix file to a blank value.
>
> Can you tell us either
> 1) what the nature of the dtxx data representation of a BLANK
> or deleted pixel in .pix file myuxx might be (ie. is it
> -32767 or +1.0e90 or something).
>
> -or-
>
> 2) is there a subtroutintxxx (damn keyboard) subroutine we
> should be calling to create or write BLANK pixels? Well, there is no totally satisfactory solution at the moment; this will
change before too long. To summarize: - RFITS has a task parameter "blank", which is to be the IRAF pixel
value corresponding to fits pixels having value BLANK.

- WFITS has no equivalent parameter (reason explained below). - some of the new (iraf 2.8) image structures could be used in new SPP
application programs to handle deleted data values, e.g. pixel list
i/o, masks, but these facilities are not available in IMFORT programs. - additional image structure facilities will be added in the future. - IEEE floating point support will become available in FITS, helping
solve problems involving scaling type real pixels for image transport. Thus, if you read an original fits image into iraf using RFITS, you can
set the iraf pixel value corresponding to BLANK-valued pixels, but you have
to be careful, because from then on, applications will treat those pixels as
ordinary data values: e.g. a scaling transformation will scale the "blank"-
valued pixels just like any others. You can NOT set the fits BLANK when you
write out IRAF images with WFITS; the only way to do this safely would have
been to test each pixel for the appropriate iraf "blank" value, then explicitly
write the fits BLANK value to tape, an expensive process. Care is needed when choosing the iraf "blank" value with rfits (see help
page). If the image is type integer or short, and subsequent downstream
images remain so without transforming the "blank" pixel values, wfits can
write out an integer fits image containing the exact same value as the original
(though without the BLANK header keyword). However, if the image is of type
real, you must be very careful when choosing the rfits "blank" value. For
example, choosing a value very far outside the real dynamic range of the data,
like +/-INDEFR, will really mess things up if the image is later written back
out as a fits file with wfits because the linear transformation currently
needed to encode real numbers as integers works off the actual range of pixel
values. Yes, it is possible to specify BSCALE and BZERO to wfits rather than
autoscaling, but it may be hard to predict the actual "blank" pixel values,
and may be machine dependent (especially in multiple rfits/wfits iterations). It is probably safest to pick rfits "blank" values just outside the
dynamic range of the data, and pay careful attention to what happens to them
in further processing. The reason for all this is that there are much more efficient ways to
deal with bad pixels than to have every single operation read and check the
value of each pixel countless times at runtime, which would be necessary if
we just used a particular data value (one for each datatype) for BLANK pixels.
Help is on the way for SPP programming (pixel lists & masks), but I don't
know how little or much of that will be available for IMFORT applications.
Some of the problems with fits & real images will be solved when ieee/fits
becomes available.Steve Rooke (iraf@noao.edu)