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
Adding a reference does not work after a montage has been set #5619
Comments
indeed. Do you have time to fix this?
|
The fix isn't obvious based on how applying montages currently works. One option is to add all montage entries to I'd probably just wait to tackle this once digitization/montages are properly refactored. |
I didn't know that |
It's not needed for reference calculation. I assumed the problem you mention had to do with the location in space not being set. The error message might be misleading on this point, but I suspect it's the underlying problem. Also I realized dig does not say which channel each point is associated with so the fix I proposed won't work. I can't think of a clean solution. We could hack something like storing the unused channel names and locations in case you add one later, but this is ugly and will not survive IO roundtrip. I'm in inclined to say the solution is in the user side. Either use the other order with no warning, or live with the warning and reapply the montage afterward to get the location added. In other words, the rule is that applying a montage will only set locations of channels that exist at the time it is applied. And thus the fix here is just a documentation update to say that. And nobody is actively working on the digitization refactoring yet. I hope to get to it for 0.18. |
I agree that updating the documentation is the way to go here. I think a clear warning message would mention that you cannot add a new channel because a montage has already been set, and therefore the montage needs to be re-applied. Alternatively, what about this hack: if the user adds a channel after a montage has been set, we could automatically re-apply the montage if we knew the montage name - is this stored anywhere? We could then only issue the warning if a channel that is not part of the montage was added (then of course we need to set its location to zero). |
I prefer the clear doc + warning approach than the more magical one.
|
I don't mind teaming up with someone to approach this after we release. It would bring me light to a part of the io that is still shady to me. |
FWIW, #6369 didn't solve this issue (maybe it wasn't supposed to, I didn't really follow this topic closely). |
sure. #6369 aims to simplify the future changes by putting everything in one place. No real API change has been done yet. |
I guess I should make an issue with the notes of the plan we discussed with @larsoner so that is easier to follow the status for everyone. Right now I only have messy notes. |
The order in which you perform assigning a montage and adding a reference matters, which probably shouldn't be the case.
Consider the following example using the testing data from
mne/io/brainvision/tests/data/test.*
(the first two lines could be combined by supplying themontage
argument in the call tomne.io.read_raw_brainvision
):This assigns the montage first and then adds a new reference channel which wasn't part of the data. This produces a
RuntimeWarning: The locations of multiple reference channels are ignored (set to zero).
, which results in an incorrect location of the newly added channel T3.If instead you first add the reference channel and then set the montage, everything works as expected:
The text was updated successfully, but these errors were encountered: