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
{{ message }}
Repository navigation
test_comp_image_hcompress_image_stack with cfitsio 3.380 #4647
This is the second failure when compiling with cfitsio 3.380 (and numpy 1.11b3):
____ TestCompressedImage.test_comp_image_hcompress_image_stack ___________
args = (<astropy.io.fits.tests.test_image.TestCompressedImage object at 0x7fcf3a85e810>,)
kwargs = {}
@functools.wraps(func)
def wrapper(*args, **kwargs):
# Originally this just reused self, but that doesn't work if the
# function is called more than once so we need to make a new
# context manager instance for each call
with self.__class__(category=self.category):
> return func(*args, **kwargs)
astropy/tests/helper.py:361:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <astropy.io.fits.tests.test_image.TestCompressedImage object at 0x7fcf3a85e810>
@ignore_warnings(AstropyPendingDeprecationWarning)
def test_comp_image_hcompress_image_stack(self):
"""[...]"""
cube = np.arange(300, dtype=np.float32).reshape((3, 10, 10))
hdu = fits.CompImageHDU(data=cube, name='SCI',
compressionType='HCOMPRESS_1',
quantizeLevel=16, tileSize=[5, 5, 1])
hdu.writeto(self.temp('test.fits'))
with fits.open(self.temp('test.fits')) as hdul:
> assert (hdul['SCI'].data == cube).all()
E assert <built-in method all of numpy.ndarray object at 0x7fcf3a662210>()
E + where <built-in method all of numpy.ndarray object at 0x7fcf3a662210>
= array([[[ 0...dtype=float32) == array([[[ 0....dtype=float32)
E Detailed information truncated, use "-vv" to show.all
This may be the same problem as #4646; however it looks different to me (and numpy is involved here as well).
Full log here.
This also happens on all architectures.
After reading the astropy documentation for CompImageHDU I wonder why the test ever worked? Without checking the detailed computation, I would expect that the image is not exactly the same after writing to disk and reading back. Just the quantization seems to be different from exact integer. However, I don't know whether the difference is within the expectations: -0.065 ... 0.065 (~ 1./16.).
The change on the cfitsio side which caused this regression is the following one:
modified the 4 FnNoise5_(type) routines in quantize.c to correctly
count the number of non-null pixels in the input array. Previously the
count could be inaccurate if the image mainly consisted of null pixels.
This could have caused certain floating point image tiles to be
quantized during the image compression process, when in fact the tile
did not satisfy all the criteria to be safely quantized.
Basically the quantization was not done correctly in some cases (including the one in astropy), so in practice the data where left unchanged.
Therefore the suggested change looks to me the right way to fix the issue.
This fail for TestCompressedImage.test_comp_image_hcompress_image_stack shows up there as well (for Python 2.7, 3.4, 3.5, 3.6), and is the only fail in the Astropy test suite.
In Macports, Astropy uses the separate port for CFITSIO, which at the moment is at version cfitsio @3.390_1, numpy is at @1.11.3_0+gfortran.
cc @MSeifert04@pllim as astropy.io.fits maintainers - What to do? Adapt the test?
Activity
astrofrog commentedon Feb 29, 2016
@olebole do you see the same issue with cfitsio 3.380 and numpy 1.10? And what about with the previous cfitsio and numpy 1.11b3?
olebole commentedon Feb 29, 2016
It did work with numpy 1.11b3 and the old (3.370) cfitsio. cfitsio 3.380 and numpy 1.10 is not tested yet. I could try this manually if needed.
astrofrog commentedon Feb 29, 2016
@olebole - that would be great, to narrow it down - thanks!
olebole commentedon Feb 29, 2016
cfitsio 3.380 and numpy 1.10 has the same issue, so it is clearly a problem caused by the cfitsio update.
olebole commentedon Mar 1, 2016
Re-running it with more verbosity gives
olebole commentedon Mar 1, 2016
After reading the astropy documentation for CompImageHDU I wonder why the test ever worked? Without checking the detailed computation, I would expect that the image is not exactly the same after writing to disk and reading back. Just the quantization seems to be different from exact integer. However, I don't know whether the difference is within the expectations: -0.065 ... 0.065 (~ 1./16.).
Loose identity test of a HCOMPRESSed image
aurel32 commentedon Mar 2, 2016
The change on the cfitsio side which caused this regression is the following one:
Basically the quantization was not done correctly in some cases (including the one in astropy), so in practice the data where left unchanged.
Therefore the suggested change looks to me the right way to fix the issue.
Loose identity test of a HCOMPRESSed image
Loose identity test of a HCOMPRESSed image
Loose identity test of a HCOMPRESSed image
cdeil commentedon Jan 6, 2017
Macports was updated to Astropy 1.3 just now: https://trac.macports.org/ticket/53162
This fail for
TestCompressedImage.test_comp_image_hcompress_image_stackshows up there as well (for Python 2.7, 3.4, 3.5, 3.6), and is the only fail in the Astropy test suite.In Macports, Astropy uses the separate port for CFITSIO, which at the moment is at version
cfitsio @3.390_1, numpy is at@1.11.3_0+gfortran.cc @MSeifert04 @pllim as
astropy.io.fitsmaintainers - What to do? Adapt the test?pllim commentedon Jan 6, 2017
If the test result is supposed to be different on Macports, we can either mark it as
xfailfor that setting or, like you said, adapt it.Loose identity test of a HCOMPRESSed image