FIX: Handling bad marker coils when reading KIT data #8981#8989
FIX: Handling bad marker coils when reading KIT data #8981#8989larsoner merged 15 commits intomne-tools:mainfrom
Conversation
…hether a marker coil exists before retrieving its coordinates.
…hether a marker coil exists before retrieving its coordinates.
|
@agramfort I think this is ready for review. It's my first contribution - sorry about the commit messages, I didn't realise the tags should be included in each commit, rather than just the PR title. |
mne/io/kit/kit.py
Outdated
| if key in dig: | ||
| elp.append(dig.pop(key)) | ||
| if 'hpi_5' in dig and dig['hpi_5'].any(): | ||
| elp.append(dig.pop('hpi_5')) |
There was a problem hiding this comment.
it seems this if just below is exactly to catch the issue of missing hpi_5. Maybe we can use the same logic for all hpi's ?
There was a problem hiding this comment.
Yes I think that's what it's doing, but not sure why it was checking specifically for hpi_5 and not the others.
Also, based on the additional condition dig['hpi_5'].any(), it seems like [0, 0, 0] is considered as invalid coordinates. Again not sure if this is something specific to hpi_5 or should be checked for all marker coils. I don't think we should treat [0, 0, 0] as invalid in general though.
There was a problem hiding this comment.
Yes I think that's what it's doing, but not sure why it was checking specifically for hpi_5 and not the others.
I added this because there was one dataset I think was from @paulsowman that had the first four only. But I suppose it makes sense that you might be missing any one (or up to two?) of the five.
There was a problem hiding this comment.
It looks like this special case is no longer needed. All hpi_* should be treated the same way.
While unifying it, we can try getting rid of the .any and see if it breaks anything. Maybe np.isfinite(dig['hpi_5']).all() is a better check.
There was a problem hiding this comment.
Agreed and implemented. Doesn't seem to break anything.
Hooray for your first contribution!! FYI, it's not crucial to put tags like |
|
I don't have enough test KIT files so maybe we should just take your fix
here and it seems
the less likely to introduce a regression
… |
|
Thanks @larsoner
Indeed we have another dataset with two missing coils. The present fix cannot handle that situation yet, as it would fail at the assertion a few lines below:
assert elp.shape in ((7, 3), (8, 3))
In the case of two missing coils, the shape becomes (6, 3). I tried removing this assertion temporarily, but it seems to run into more problems later on.
________________________________
From: Eric Larson <notifications@github.com>
Sent: Friday, March 5, 2021 3:13:22 AM
To: mne-tools/mne-python <mne-python@noreply.github.com>
Cc: Di Zhu <di.zhu@mq.edu.au>; Author <author@noreply.github.com>
Subject: Re: [mne-tools/mne-python] FIX: Handling bad marker coils when reading KIT data #8981 (#8989)
@larsoner commented on this pull request.
________________________________
In mne/io/kit/kit.py<#8989 (comment)>:
@@ -720,9 +720,12 @@ def get_kit_info(rawfile, allow_unknown_format, standardize_names=None,
hsp.append(rr)
# nasion, lpa, rpa, HPI in native space
- elp = [dig.pop(key) for key in (
- 'fidnz', 'fidt9', 'fidt10',
- 'hpi_1', 'hpi_2', 'hpi_3', 'hpi_4')]
+ elp = []
+ for key in (
+ 'fidnz', 'fidt9', 'fidt10',
+ 'hpi_1', 'hpi_2', 'hpi_3', 'hpi_4'):
+ if key in dig:
+ elp.append(dig.pop(key))
if 'hpi_5' in dig and dig['hpi_5'].any():
elp.append(dig.pop('hpi_5'))
Yes I think that's what it's doing, but not sure why it was checking specifically for hpi_5 and not the others.
I added this because there was one dataset I think was from @paulsowman<https://github.com/paulsowman> that had the first four only. But I suppose it makes sense that you might be missing any one (or up to two?) of the five.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#8989 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJE5HU5VJVDP2Q74VT6GP5LTB6WSFANCNFSM4YSI5ECA>.
|
|
That's an assert statement I put in to make sure that, if someone changed the behavior, they look at the downstream impact. Let me know if you need help assessing it. But I think checking that at least 3 are available, and maybe indexing of the relevant ones (I might have coded it to assume the last coil was the missing one?) will be necessary |
Thanks for your help @larsoner |
|
One of the tests failed - I can't figure out what it means / how to fix it. Would appreciate any advice! |
mne/io/kit/kit.py
Outdated
| elp = np.array(elp) | ||
| hsp = np.array(hsp, float).reshape(-1, 3) | ||
| assert elp.shape in ((7, 3), (8, 3)) | ||
| assert elp.shape in ((6, 3), (7, 3), (8, 3)) |
There was a problem hiding this comment.
Now that it's possible for a user (as opposed to only a dev making code chainges) to run into a situation where this could be violated, this should become a proper check and raise, e.g.:
| assert elp.shape in ((6, 3), (7, 3), (8, 3)) | |
| if elp.shape not in ((6, 3), (7, 3), (8, 3)): | |
| raise RuntimeError(f | |
| f'Fewer than 3 HPI coils found, got {len(elp) - 3}') |
There was a problem hiding this comment.
Implemented the suggested change.
agramfort
left a comment
There was a problem hiding this comment.
diff LGTM
can you merge again the main branch to see if it fixes the CIs. The +1 for merge when green
|
Still 1 failed test. Any idea what the issue might be? |
|
it does not seem related. Let's wait for us to fix this other issue
and then we'll merge this one. thx
… |
|
Sure 😃 |
|
Thanks @JD-Zhu ! |
|
Thanks @larsoner @agramfort @drammock |
Fixes #8981.
When reading .con files from KIT system, an error occurs if there are missing marker coils. The proposed solution here resolves this problem by checking whether a marker coil exists before retrieving its coordinates.