-
-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A workaround for unfixable header keys in ImageFileCollection #743
base: main
Are you sure you want to change the base?
Conversation
…g with missing content and their genuine values, breaking the ImageFileCollection for data with these malformed headers.
Per the PR checklist
I am seeing that this PR breaks 1 test: |
Thanks -- can you please ping when you have fixed that? Tests are currently not running on travis because they've dropped support for open source projects. Also, don't be shy about pinging me multiple times 😬 |
I fixed the failed test which in hindsight was an edge case of a None header. Also added a warning logger. Probably best practices would be to add a test that has such a malformed keyword and then make sure the correct |
I'm going to close/reopen to see if that picks up the new GitHub Actions CI. More substantive review tomorrow, I hope... |
Codecov Report
@@ Coverage Diff @@
## main #743 +/- ##
==========================================
- Coverage 97.55% 95.30% -2.26%
==========================================
Files 9 30 +21
Lines 1392 3895 +2503
==========================================
+ Hits 1358 3712 +2354
- Misses 34 183 +149
... and 26 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Unfixable header keys are currently populating the summary_dict with their genuine values and also missing value place holders, resulting in lists of values that are too long, breaking the ImageFileCollection for data with these malformed headers.
I tried to track down the root cause, and could pinpoint it to the
_dict_from_fits_header()
method called within_fits_summary
. My hunch is there's something special about these unfixable keys that gets them double counted asmissing_in_this_file
. A key clue is that the resulting list for offending keys is always 2*N-1 long, where N is the number of files.This workaround is really just that-- a stopgap measure to get this to work on the types of files I have. I suspect the right solution is to dig a bit deeper on
_dict_from_fits_header
, so I didn't go through with a full check of tests, assuming this workaround won't actually be in the final product.Here are urls to two example files that reproduce the problem:
The malformed keys are
GAIN.SPE
andFREQ.SPE
, though they do not appear in the error message, truncated below:Please have a look at the following list and replace the "[ ]" with a "[x]" if
the answer to this question is yes.
For documentation changes:
Note that it should not if you changed any examples!
For bugfixes:
For new functionality:
Please note that the last point is not a requirement. It is meant as a check if
the pull request potentially breaks backwards-compatibility.