modifying BZERO,BSCALE in spp
rclark wrote on Jun 19, 2009
I'm sometimes getting the dreaded 'invalid floating point operation' error with
some images I'm trying to save in fits files. After some effort I've figured out
what's causing it but I'm not sure of the best way to handle it.
In the original fits file the image is stored as short int--
BITPIX = 16, BZERO and BSCALE are not present. The image data
values fit within the available range.
The image is read using IMGS2R and handled internally as real.
Operations are performed, mainly geometric transformations. There
are interpolation artifacts. Some noise may be present.
Yep, you guessed it. A handful of pixels are now just out of range for short int.
When the 'corrected' image is written to the output file (created with
immap using the NEW_COPY mode) the error occurs.
Interestingly, on a Sun solaris system running IRAF 2.11 this is handled
by silently wrapping the values (e.g. 33000 -> -32536) But version 2.13 on
a linux system gives the error.
Several options are possible. I'm not sure how to do any of them.
For the moment I'm clipping the image values to values that can be
converted to short int. But I don't like this as a general solution. This
procedure should work with any image type that uses our geometry
model. Some of them are stored as different data types (short int WITH
scaling, long int or float) where this clipping is not appropriate.
How do I check the BITPIX, BSCALE, BZERO values in the original
and modify them in the NEW_COPY for the output? The i_* names
listed in SPP don't seem to allow direct access to them.
Options that I need to consider include
BITPIX=16, BZERO, BSCALE not initially present:
clip the data values, or add the scaling keywords
BITPIX=16, BZERO, BSCALE already present:
modify the scaling if necessary
BITPIX=32 or -32:
Probably don't need to do anything
If scaling is not initially present, how is it added? Either manually
or automatically?
If scaling is present in the original, how is it modified in the copy?
Manually? Automatically?
So basically, in SPP, what are the rules for messing around with these
three keywords? Is there any discussion of this someone could
point me to?
In the hope that if the scaling keywords were initially present they
might be automatically adjusted as necessary I tried adding the B*
keywords set to null scaling with HEDIT on a couple of test images (a
good one and an evil one) but with no effect. The B* keywords were
added to *the end* of the header in the originals and were missing
in the processed copy. And the bad image still caused the error.
Any help would be greatly apreciated
Richard
some images I'm trying to save in fits files. After some effort I've figured out
what's causing it but I'm not sure of the best way to handle it.
In the original fits file the image is stored as short int--
BITPIX = 16, BZERO and BSCALE are not present. The image data
values fit within the available range.
The image is read using IMGS2R and handled internally as real.
Operations are performed, mainly geometric transformations. There
are interpolation artifacts. Some noise may be present.
Yep, you guessed it. A handful of pixels are now just out of range for short int.
When the 'corrected' image is written to the output file (created with
immap using the NEW_COPY mode) the error occurs.
Interestingly, on a Sun solaris system running IRAF 2.11 this is handled
by silently wrapping the values (e.g. 33000 -> -32536) But version 2.13 on
a linux system gives the error.
Several options are possible. I'm not sure how to do any of them.
For the moment I'm clipping the image values to values that can be
converted to short int. But I don't like this as a general solution. This
procedure should work with any image type that uses our geometry
model. Some of them are stored as different data types (short int WITH
scaling, long int or float) where this clipping is not appropriate.
How do I check the BITPIX, BSCALE, BZERO values in the original
and modify them in the NEW_COPY for the output? The i_* names
listed in SPP don't seem to allow direct access to them.
Options that I need to consider include
BITPIX=16, BZERO, BSCALE not initially present:
clip the data values, or add the scaling keywords
BITPIX=16, BZERO, BSCALE already present:
modify the scaling if necessary
BITPIX=32 or -32:
Probably don't need to do anything
If scaling is not initially present, how is it added? Either manually
or automatically?
If scaling is present in the original, how is it modified in the copy?
Manually? Automatically?
So basically, in SPP, what are the rules for messing around with these
three keywords? Is there any discussion of this someone could
point me to?
In the hope that if the scaling keywords were initially present they
might be automatically adjusted as necessary I tried adding the B*
keywords set to null scaling with HEDIT on a couple of test images (a
good one and an evil one) but with no effect. The B* keywords were
added to *the end* of the header in the originals and were missing
in the processed copy. And the bad image still caused the error.
Any help would be greatly apreciated
Richard
Mike Fitzpatrick wrote on Jun 19, 2009
In the original fits file the image is stored as short int-- BITPIX = 16, BZERO and BSCALE are not present. The image data values fit within the available range. The image is read using IMGS2R and handled internally as real. Operations are performed, mainly geometric transformations. There are interpolation artifacts. Some noise may be present. Yep, you guessed it. A handful of pixels are now just out of range for short int.
When the 'corrected' image is written to the output file (created with immap using the NEW_COPY mode) the error occurs. Interestingly, on a Sun solaris system running IRAF 2.11 this is handled by silently wrapping the values (e.g. 33000 -> -32536) But version 2.13 on a linux system gives the error.
It isn't surprising the Sun and Linux systems behave differently, but I don't quite know how you're writing out the image: are you calling something like imps2r() to write the real values into the output image or are you writing them with the equivalent short type routine? If the values are within range of a floating point number you shouldn't see an FPE when writing to a short (if anything, I'd expect an 'integer overflow' error).
Several options are possible. I'm not sure how to do any of them. For the moment I'm clipping the image values to values that can be converted to short int. But I don't like this as a general solution. This procedure should work with any image type that uses our geometry model. Some of them are stored as different data types (short int WITH scaling, long int or float) where this clipping is not appropriate.
Image pixels can be any type in an application and then converted to yet another type when written to the file. Scaling kicks in automatically with unsigned short images, but it is illegal to e.g. have a floating point image with BSCALE/BZERO values in the header.
How do I check the BITPIX, BSCALE, BZERO values in the original and modify them in the NEW_COPY for the output? The i_* names listed in SPP don't seem to allow direct access to them.
The IMIO model is such that you don't necessarily know what image type you are writing, this can be set by the user at runtime by specifying a different image extension. As such, BITPIX isn't what you should be looking for, in SPP you would look at the IM_PIXTYPE field of the image descriptor. Except for unsigned short images (BITPIX=-16), the BSCALE/BZERO keywords are actually removed from the header area of mapped images when using NEW_COPY mode.
So basically, in SPP, what are the rules for messing around with these three keywords? Is there any discussion of this someone could point me to?
The rule basically is, you can't mess with these keywords. For discussion of
the scaling, see the FITS Kernel User's Guide (http://iraf.net/irafdocs/fits_userguide/), specifically
FITS SCALING AND DATATYPE.
The FITS kernel will scaled correctly at reading time an input FITS image based on the values of BSCALE and BZERO. When creating a new image or making a new copy and if the image datatype during computacion is REAL or DOUBLE, the values of BSCALE and BZERO will be one and zero respectively, while the value of BITPIX will be -32 or -64, indicating that the FITS image is in FITS IEEE standard format. When in input image has a BITPIX value of 8, the internal IRAF size will be 16 since this is the minimum size for computation if the values of BSCALE and BZERO are the default, otherwise the size will be 32. If BITPIX is 16, the same principle applies.
For unsigned 16 bits, the IRAF datatype is ushort and the FITS image datatype will be BITPIX 16 and BSCALE of one and BZERO of 32768.
-Mike
Last post on Jun 19, 2009