Loading image changes reported BITPIX value

[rsiverd]

Also reported to pyfits: spacetelescope/PyFITS#36

With current pyfits (3.1.2) or astropy (0.2.4), the act of reading an image into a numpy array appears to force the reported value of BITPIX to -32. If the image is actually integer (e.g., BITPIX=16), pyfits/astropy.io.fits reports an incorrect BITPIX value when checked after loading pixel data.

This affects normal and Rice-compressed images. Floating-point (BITPIX -32) images are "unaffected." I suspect this is not the intended behavior.

Test image available here:
http://astro.phy.vanderbilt.edu/~siverdrj/survey11n.e.20100613.061.fits.fz

import pyfits as pf
hdulist = pf.open('survey11n.e.20100613.061.fits.fz')
hkeys1 = hdulist[1].header.copy()[:5]       # copy first, BITPIX = 16
scidata = hdulist[1].data                    # this changes the BITPIX
hkeys2 = hdulist[1].header.copy()[:5]       # this one has BITPIX -32 !

print "BITPIX (before): %3d" % hkeys1['BITPIX']
print "BITPIX (after):  %3d" % hkeys2['BITPIX']
print "Comparison: %s" % (hkeys1 == hkeys2)

Output:
BITPIX (before): 16
BITPIX (after): -32
Comparison: False

[perrygreenfield]

Do bscale or bzero exist in the header?

On Oct 1, 2013, at 2:22 PM, rsiverd wrote:

Also reported to pyfits: spacetelescope/PyFITS#36

With current pyfits (3.1.2) or astropy (0.2.4), the act of reading an image into a numpy array appears to force the reported value of BITPIX to -32. If the image is actually integer (e.g., BITPIX=16), pyfits/astropy.io.fits reports an incorrect BITPIX value when checked after loading pixel data.

This affects normal and Rice-compressed images. Floating-point (BITPIX -32) images are "unaffected." I suspect this is not the intended behavior.

Test image available here:
http://astro.phy.vanderbilt.edu/~siverdrj/survey11n.e.20100613.061.fits.fz

import pyfits as pf
hdulist = pf.open('survey11n.e.20100613.061.fits.fz')
hkeys1 = hdulist[1].header.copy()[:5] # copy first, BITPIX = 16
scidata = hdulist[1].data # this changes the BITPIX
hkeys2 = hdulist[1].header.copy()[:5] # this one has BITPIX -32 !

print "BITPIX (before): %3d" % hkeys1['BITPIX']
print "BITPIX (after): %3d" % hkeys2['BITPIX']
print "Comparison: %s" % (hkeys1 == hkeys2)

Output:
BITPIX (before): 16
BITPIX (after): -32
Comparison: False

—
Reply to this email directly or view it on GitHub.

[rsiverd]

Yes, both BSCALE and BZERO are present.

This image is unsigned short (USHORT_IMG in CFITSIO), meaning BITPIX=16,
BSCALE=1.0, and BZERO=32768. I believe this is a special case normally
interpreted as integer.

On Tue, Oct 1, 2013 at 1:45 PM, perrygreenfield notifications@github.comwrote:

Do bscale or bzero exist in the header?

On Oct 1, 2013, at 2:22 PM, rsiverd wrote:

Also reported to pyfits: spacetelescope/PyFITS#36

With current pyfits (3.1.2) or astropy (0.2.4), the act of reading an
image into a numpy array appears to force the reported value of BITPIX to
-32. If the image is actually integer (e.g., BITPIX=16),
pyfits/astropy.io.fits reports an incorrect BITPIX value when checked after
loading pixel data.

This affects normal and Rice-compressed images. Floating-point (BITPIX
-32) images are "unaffected." I suspect this is not the intended behavior.

Test image available here:

http://astro.phy.vanderbilt.edu/~siverdrj/survey11n.e.20100613.061.fits.fz

import pyfits as pf
hdulist = pf.open('survey11n.e.20100613.061.fits.fz')
hkeys1 = hdulist[1].header.copy()[:5] # copy first, BITPIX = 16
scidata = hdulist[1].data # this changes the BITPIX
hkeys2 = hdulist[1].header.copy()[:5] # this one has BITPIX -32 !

print "BITPIX (before): %3d" % hkeys1['BITPIX']
print "BITPIX (after): %3d" % hkeys2['BITPIX']
print "Comparison: %s" % (hkeys1 == hkeys2)

Output:
BITPIX (before): 16
BITPIX (after): -32
Comparison: False

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1502#issuecomment-25476741
.

[embray]

Closing as a duplicate--for now tickets need only be issued in one or the other. I will port them as necessary.

[embray]

Ah, I just saw your last comment @rsiverd. If they're expected to be scaled as unsigned integers open the file with uint=True to enable unsigned ints.

I've been thinking of making this the default given that it's such a common convention. Problem is just that's a convention and not part of the FITS standard (which really should have added support for this formally just about forever ago).

[rsiverd]

On Thu, Oct 10, 2013 at 3:22 PM, Erik Bray notifications@github.com wrote:

Ah, I just saw your last comment @rsiverd https://github.com/rsiverd.
If they're expected to be scaled as unsigned integers open the file with
uint=True to enable unsigned ints.

I've been thinking of making this the default given that it's such a
common convention. Problem is just that's a convention and not part of the
FITS standard (which really should have added support for this formally
just about forever ago).

Perfect, thanks (just saw this). This is what I needed as it appears to
work fine with floating-point images too.