[AstroPy] FITS image data dtype

Miguel de Val-Borro miguel.deval at gmail.com
Wed Jul 17 16:52:35 EDT 2013


On Wed, Jul 17, 2013 at 04:28:07PM -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.

Yes, it returns True. It could be a bug in matplotlib and not something
related to pyfits, I will try to find more information to debug the
problem.  At least it's good to know that swapping the byte order helps
to be able to display the image.

Thanks,
Miguel



More information about the AstroPy mailing list