Repository navigation
Conversation
…be incorrect if the data was read in and written out without any changes
Contributor
|
Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.
|
Member
Author
|
pre-commit.ci autofix |
Contributor
|
@astrofrog - I think we can close this one ? |
Member
Author
|
Indeed! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While discussing checksums with @saimn in #14753 I realised that that bug only occurs under a very specific condition - if we read in data and write it out straight away, and that in fact everything works as expected if one modifies the data or sets the data. The fix ends for this issue on
mainactually ends up being simple, and is done in this PR.Essentially, if a compressed FITS file is read in and written out straight away, ZHECKSUM/ZDATASUM are missing compared to cases where the data is set or modified.
The following script illustrates the problem:
Running this on
maingives:In the first case, there is no checksum, which is expected. In the second case the decompressed HDU checksum and datasum are computed and stored in ZHECKSUM/ZDATASUM. However, if we read in the file with no checksums and export it immediately without touching data, then ZHECKSUM/ZDATASUM are missing, which is inconsistent. Furthermore, as shown in the fourth case, if we read the file in and reassign the data to itself, then ZHECKSUM/ZDATASUM are back, and if we change the data then of course the checksums change (fifth case).
The bug here was that the image checksums in
CompImageHDU._prewritetowere computed only ifself._has_dataisTrue, but if you just read in a compressed file and don't interact with the data, it is never loadded andself._has_dataisFalse, even though in principle there is data that could be used to compute a checksum. I have therefore re-arranged the code slightly to compute the image checksum regardless ofself._has_databut instead doing it only ifchecksumis specified and ifself.datais notNone(the check ofchecksumis needed because accessingself.datais expensive as it might trigger the whole data to decompress - we need to do this in any case if we are computing the checksum, but might as well avoid hitting self.data ifchecksum=False. With this minor change, the output is then:The checksums are the same in the second, third, and fourth case.