[AstroPy] FITS image data dtype

Erik Bray embray at stsci.edu
Wed Jul 17 16:28:07 EDT 2013

On 07/17/2013 03:24 PM, Miguel de Val-Borro wrote:
> On Wed, Jul 17, 2013 at 12:14:16PM -0400, Erik Bray wrote:
>> FITS files store arrays in big-endian order natively.  Actually swapping the
>> bytes to native order can be costly, especially when the data is being accessed
>> by way of an mmap'd file (the default in PyFITS 3.1 and up).  And it's generally
>> unnecessary when working within Numpy--it is only necessary if passing those
>> bytes to other software that is expecting values in native byte order.
> The matplotlib function imshow shows the original map differently than
> after swapping the byte order to little-endian format.
> imshow(hdulist[1].data)
> https://docs.google.com/file/d/0B3Hv-zV2q5IcSjk2amw3ZmM3Mk0/edit
> imshow(hdulist[1].data.byteswap().newbyteorder())
> https://docs.google.com/file/d/0B3Hv-zV2q5IcTWZ2WXduMWttQUE/edit
> If I remember correctly I also had problems with numpy array operations
> on the maps with the '>f8' dtype for this kind of image data.

Hmmm..  This sounds really familiar but I think it's actually a bug in matplotlib.

Just be sure why don't you make sure that np.all(hdulist[1].data == 
hdulist[1].data.byteswap().newbyteorder())  If that doesn't return True I'll eat 
my shoe.

Unfortunately I don't think I ever figured out what the exact cause was.  But 
can you rule out for certain that the values are not different?


More information about the AstroPy mailing list