You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to use reproject with an integer-valued image that has the BLANK keyword set. This turns out to lead to an exception, at least with the interpolating mode:
ValueError: mmap length is greater than file size
The problem is because of hdu_to_numpy_memmap(). It has various guards in place to only memmap if the HDU data array aligns exactly with what's on disk. The presence of BLANK causes Astropy to change my u16 data to f32, which means that the memmap should not be performed, but as things currently stand, the check doesn't get this right.
The current guard code is:
if (
hdu.header.get("BSCALE", 1) !=1orhdu.header.get("BZERO", 0) !=0orhdu.fileinfo() isNoneorhdu._data_replacedorhdu.fileinfo()["file"].compressionisnotNone
):
returnhdu.data
I could easily add a test for the existence of the BLANK keyword, but I'm wondering if there's a "better" way to check for this case. Looking at the Astropy FITS code, there's a field called _data_needs_rescale alongside the existing _data_replaced; it's False for this HDU, but maybe that's an Astropy bug, and it should be true? There are also an hdu._blank field. Naively, maybe it's an Astropy bug that _data_replaced is not True in this situation?
I'm happy to submit a pull request for this, as well as provide a specific reproduction case, but I was wondering if anyone had input about the best approach to take.
The text was updated successfully, but these errors were encountered:
pkgw
added a commit
to pkgw/pywwt
that referenced
this issue
Oct 16, 2024
Hi —
I'm trying to use reproject with an integer-valued image that has the BLANK keyword set. This turns out to lead to an exception, at least with the interpolating mode:
The problem is because of
hdu_to_numpy_memmap()
. It has various guards in place to only memmap if the HDUdata
array aligns exactly with what's on disk. The presence of BLANK causes Astropy to change myu16
data tof32
, which means that the memmap should not be performed, but as things currently stand, the check doesn't get this right.The current guard code is:
I could easily add a test for the existence of the BLANK keyword, but I'm wondering if there's a "better" way to check for this case. Looking at the Astropy FITS code, there's a field called
_data_needs_rescale
alongside the existing_data_replaced
; it's False for this HDU, but maybe that's an Astropy bug, and it should be true? There are also anhdu._blank
field. Naively, maybe it's an Astropy bug that_data_replaced
is not True in this situation?I'm happy to submit a pull request for this, as well as provide a specific reproduction case, but I was wondering if anyone had input about the best approach to take.
The text was updated successfully, but these errors were encountered: