Skip to content

FIX: Handling bad marker coils when reading KIT data #8981#8989

Merged
larsoner merged 15 commits intomne-tools:mainfrom
Macquarie-MEG-Research:master
Mar 9, 2021
Merged

FIX: Handling bad marker coils when reading KIT data #8981#8989
larsoner merged 15 commits intomne-tools:mainfrom
Macquarie-MEG-Research:master

Conversation

@JD-Zhu
Copy link
Copy Markdown
Contributor

@JD-Zhu JD-Zhu commented Mar 4, 2021

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.

@JD-Zhu
Copy link
Copy Markdown
Contributor Author

JD-Zhu commented Mar 4, 2021

@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.

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'))
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed and implemented. Doesn't seem to break anything.

@drammock
Copy link
Copy Markdown
Member

drammock commented Mar 4, 2021

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.

Hooray for your first contribution!! FYI, it's not crucial to put tags like sty or doc in every commit message if the messages are descriptive (like yours are). When we merge PRs we squash all commits into one anyway. Your commit messages are better than many of mine, which often just say "missed one" or "try again" 😆

@agramfort
Copy link
Copy Markdown
Member

agramfort commented Mar 4, 2021 via email

@JD-Zhu
Copy link
Copy Markdown
Contributor Author

JD-Zhu commented Mar 4, 2021 via email

@larsoner
Copy link
Copy Markdown
Member

larsoner commented Mar 4, 2021

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

@JD-Zhu
Copy link
Copy Markdown
Contributor Author

JD-Zhu commented Mar 5, 2021

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
I changed the assert to allow a minimum of 3 marker coils (+ 3 fiducials), and did the same for a similar check in mne\io\kit\coreg.py (line 151). This seems to work fine without further issues.
For the indexing of relevant marker coils, I think this is already provided by their names (hpi_1, hpi_2, etc)?

@JD-Zhu
Copy link
Copy Markdown
Contributor Author

JD-Zhu commented Mar 5, 2021

One of the tests failed - I can't figure out what it means / how to fix it. Would appreciate any advice!

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))
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.:

Suggested change
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}')

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implemented the suggested change.

Copy link
Copy Markdown
Member

@agramfort agramfort left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

diff LGTM

can you merge again the main branch to see if it fixes the CIs. The +1 for merge when green

@JD-Zhu
Copy link
Copy Markdown
Contributor Author

JD-Zhu commented Mar 8, 2021

Still 1 failed test. Any idea what the issue might be?

@agramfort
Copy link
Copy Markdown
Member

agramfort commented Mar 8, 2021 via email

@JD-Zhu
Copy link
Copy Markdown
Contributor Author

JD-Zhu commented Mar 8, 2021

Sure 😃

@larsoner larsoner merged commit 31d1d0c into mne-tools:main Mar 9, 2021
@larsoner
Copy link
Copy Markdown
Member

larsoner commented Mar 9, 2021

Thanks @JD-Zhu !

@JD-Zhu
Copy link
Copy Markdown
Contributor Author

JD-Zhu commented Mar 10, 2021

Thanks @larsoner @agramfort @drammock
Happy to contribute!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Handling bad marker coils when reading KIT data

4 participants