Repository navigation
Axial to planar gradiometer transformation #9609
Description
Activity
Hello! 👋 Thanks for opening your first issue here! ❤️ We will try to get back to you soon. 🚴🏽♂️
Thanks @piuskern.
I agree, some methods for this would be useful. During the office hours, we also briefly touched upon how to solve this computationally. As discussed, I will check in detail what FieldTrip does and report back, then we can discuss how we want to proceed.FieldTrip supports different methods on how to compute planar from axial grads:
sourceprojectusing a minimum current estimate,fitplaneusing the neighborhood structure, andsincosusing the neighborhood structure as well, but more flexibly than thefitplaneoption.sincosis default here.For the combination of the vertical and horizontal parts, using an SVD is one option,
sum(sqrt(horizontal ** 2 + vertical ** 2)) andcomplexare others.I would start with just the
sourceprojectmethod since we have it implemented already and I think @agramfort suggested it should be the best in principle. We can assume YAGNI on the others until we see otherwise (especially if the values aren't that different, or they do differ but the sourceproject is better for example in round-trip test to a different system/sensor type and back).Reacted by Alexandre GramfortFWIW, there is some rather old opinion by Robert, referring to simulations, saying the
sincosmethod outperforms the others. See here: https://mailman.science.ru.nl/pipermail/fieldtrip/2005-August/026154.htmlBut I agree, if it's there, let's start with it and then we can always add this (and compare again, if we are feeling adventurous 😉 )
Reacted by Konstantinos Tsilimparis@larsoner What would be a good API for this / where should this live?
We have
inst.interpolate_badsas a mixin for raw/epochs/evoked, I think it should be part of that same mixin as a new method:def interpolate_to(self, sensors=None, dev_head_t=None):where
sensorscan be (to start) onlyNone,'ctf planar grad','ctf', and'neuromag'? Ifsensors is Nonethen it's useful just for transforming to a newdev_head_t.I suggest just these three string options to start because in this issue
'ctf planar grad'is desired, and I could see people wanting to know what their data would look like if they had been acquired on these other systems. Havingctfandneuromagis also nice because we can round-trip from actual Neuromag data to CTF and back to Neuromag and check the agreement, same with CTF to Neuromag to CTF.Under the hood this should use the same underlying machinery as
interpolate_bads-- it's actually quite simple hopefully as we "just" need to setinfo_toproperly by replacing someinfo_from['chs']with the known canonical ones for the given system.I like
sensorsas the name because in theory we could eventually support remapping other channel types (e.g., EEG) someday. But for now the function should operate only on MEG data.@britta-wstnr I'm bumping the milestone as 0.24 is going to be released in just a week or so, but it could still make 0.24 if you have time for it
9 remaining items
No it has not been implemented yet, still needs a volunteer to give it a shot
Hi all, after a discussion with @britta-wstnr I would like to take over this issue.
We have
inst.interpolate_badsas a mixin for raw/epochs/evoked, I think it should be part of that same mixin as a new method:def interpolate_to(self, sensors=None, dev_head_t=None):@larsoner do you still think this is still a good API?
Additionally, I see that you decided on
sourceprojectmethod. Shall we still proceed with this method?Yeah @contsili that would be great! We can always add other projection methods via a new keyword argument later. I think in principle the PR should be fairly straightforward 🤞
One issue is that we'll need to store the canonical CTF and Neuromag sensor definitions somewhere (positions, orientations, and coil def number). I don't think we currently do that anywhere as we rely on this info to be stored in a given file being read with
read_raw_fifor similar. So you'll probably need to add two new files tomne/channels/data/montages/to store this info, one for Neuromag and one for CTF. It's a bit of a misnomer to call these "montages" but it's the closest thing we have at the moment I think. And at some point we might want to use the montage mechanics to be able to store / set OPM channel info. I would save this info just as a simple human-readable CSV probably with colsname,coil,x,y,z,ex,ey,ez(I think that's all we need?), I don't think it will end up being too large.I would start with just the
sourceprojectmethod since we have it implemented already and I think @agramfort suggested it should be the best in principle. We can assume YAGNI on the others until we see otherwise (especially if the values aren't that different, or they do differ but the sourceproject is better for example in round-trip test to a different system/sensor type and back).@larsoner, could you point me to where the
sourceprojectmethod is implemented in the mne repo?I think it is implicitly what we use already in
mne-python/mne/channels/interpolation.py
Line 208 in b38385e
which wraps to
But really I don't think you need to worry about the mapping method for now. The critical part is that we already have a function that allows mapping from one sensor type (given a suitable
info) to another (given its suitableinfo). What method is used under the hood is a second-level detail/consideration, and we can worry/think about it once we do the work of getting the API right as above.Reacted by Konstantinos TsilimparisHi @contsili! 👋 Are you still interested in tackling this? 🙂
Hi @britta-wstnr . Yes I am still interested. I started working and I have less time but I will do it!
I think a good plan is to wait for this PR #13044 to be merged and then I can extend the functionality of
interpolate_toto MEG.Hi @contsili! Great to hear 🙌
Don't hesitate to open a PR with snippets already, it's better to have early discussions on implementations (less work for you and the code reviewers! 🙂 ). You can open a PR in DRAFT mode to signal that this is not a fully-working implementation yet. Looking forward to it!
For axial gradiometer data, e.g. from CTF 275 systems, a transformation to virtual planar gradiometers would be helpful. This is a standard procedure in many data analysis pipelines for axial systems. It would facilitate plotting and subsequent interpretation.
The issue has been briefly discussed during the office hour on 2021-07-23.
@britta-wstnr