[AstroPy] unexpected pyfits behavior float32 converted to float64
embray at stsci.edu
Wed May 9 11:49:51 EDT 2012
On 05/09/2012 11:22 AM, Erik Bray wrote:
> 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.
>> 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:
> "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?
As a followup: I did a little more digging on this issue, and found out
that despite the deceptive documentation, this has actually been the
behavior of PyFITS for quite a long time:
If the raw data is 16-bit ints they are scaled up to 32-bit floats. And
if they're 32-bit ints (or 64-bit I think) they're scaled to 64-bit
floats. I think this is so that one can generally expect the size of
their data to double when reading scaled data.
More information about the AstroPy