psImageReadSection supported datatypes.

[robert.desonia@…]

I took a look at the SDRS when reviewing bug #103, and I found a bit of a
difference between the implementation I did and the description that I like to
bring up.

I used 'fits_get_img_equivtype' to determine the most appropriate image datatype
for reading, which takes into account the bzero/bscale values. Description of
this function from the CFITSIO manual is:

Th second routine [fits_get_imgequivtype] is similar [to fits_get_img_type],
except that if the image pixel values are scaled, with non-default values for
the BZERO and BSCALE keywords, then the routine will return the 'equivalent'
data type that is needed to store the scaled values. For example, if BITPIX = 16
and BSCALE = 0.1 then the equivalent data type is FLOAT_IMG. Similarly if BITPIX

16, BSCALE = 1, and BZERO = 32768, then the the pixel values span the range of

an unsigned short integer and the returned data type will be USHORT_IMG.

This, I believe, is the best way to handle datatypes while the reading of FITS
files, as it opens up support for all non-complex datatypes that psLib supports
while allowing bzero/bscale to be handled (e.g., preserving the pixel values
properly).

The SDRS description "This function will only read images of the native FITS
image types (psU8, psU16 (sic), psU32 (sic), psF32, psF64)" is therefore not a
required limitation and I suggest it be removed.

btw, the native FITS image types, sans bzero/bscale, are U8 (bitpix=8), S16
(bitpix=16), S32 (bitpix=32), F32 (bitpix=-32), and F64 (bitpix=-64).

-rdd

[eugene]

let's stick with this suggestion.

[Paul Price]

Changed the wording in the SDRS to read:

"This function need only read images of the native FITS image types
(\code{psU8}, \code{psS16}, \code{psS32}, \code{psF32}, \code{psF64})."

I figure this means you can do extra types if you want, but we only really care
about the above types. Is that OK?

[robert.desonia@…]

Sounds good.

[Paul Price]

Should be fixed in SDRS-07 and ADD-06 (7 September 2004).