[AstroPy] unexpected pyfits behavior float32 converted to float64

[Erik Bray]

On 05/09/2012 10:18 AM, Jim Vickroy wrote:
> On 5/8/2012 9:05 PM, Michael Droettboom wrote:
>> It actually appears that this is converting 32-bit integers to 64-bit
>> floats. Does the file have BZERO or BSCALE specified? If so, it is
>> normal behavior to convert to 64-bit floats so that user code doesn't
>> have to deal with offset and scaling issues.
>>
>> Mike
>
> Thanks Mike.
>
> The FITS files do have BZERO and BSCALE defined. My mistake (twice)
> saying 32-bit float since BITPIX=+32. I was expecting conversion to
> 32-bit floats. Since converting 32-bit integers to 64-bit floats is the
> standard Pyfits behavior, I will perform the conversion explicitly
> (numpy astype).
>
> -- jv

The conversion from ints to floats is definitely the intended (albeit 
understandably surprising) behavior.

Interestingly, the PyFITS documentation is lying about this:

http://packages.python.org/pyfits/users_guide/users_image.html#reading-scaled-image-data

"For floating point storage data, the scaled data will have the same 
data type. For integer data type, the scaled data will always be single 
precision floating point (numpy.float32)."

I don't know what the reason is for this though.

Should PyFITS default to lower precision and lower memory use, or higher 
precision and higher memory use?  For the average image, scaling up to 
float64 should not be an issue for older systems.  Though on larger 
images it might start to be a problem.  Perhaps there should be an 
option for this?

Erik