-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
BUG: set_eeg_reference with single channel behavior #12369
Comments
What is the meaning of custom_ref_applied anyway? What is a "custom" reference? |
At the moment it means "something we can't handle properly in inversion" basically. Things like bipolar refs, different references for different channels, etc. Some of those situations #12366 is meant to handle. Here I'm just concerned with the case that is the standard/current way we can handle things for computing inverses. |
Thanks for the explanation! I like the proposal you made, based on my limited understanding of the issue |
What is stored in the Other than that, +1 for the proposal. |
For EEG channels, the first three elements are the electrode location and the next three are the reference channel location |
so, to clarify, I've added comments in your example script; are these correct? raw_eeg = mne.io.read_raw_brainvision(eeg_fname).load_data()
raw_eeg.rename_channels(eeg_renames) # numbers to standard 1020 names
mne.add_reference_channels(raw_eeg, "FCz", copy=False) # add all-zero channel
raw_eeg.set_montage("standard_1020") # set locations
# ↓↓↓↓ this line is where `ch["loc"][3:6]` for all channels would get set to the
# ↓↓↓↓ location of the reference channel (here FCz)
raw_eeg.set_eeg_reference(["FCz"]) # set the reference information explicitly
# ...and this line ↓↓↓↓↓↓ is where you would set `custom_ref_applied = False`?
raw_eeg.set_eeg_reference(projection=True) # switch to an average reference using projection |
The |
thanks for the clarification. I mistakenly thought that "custom ref applied" would be False only for average reference --- but I guess it is False for "any case that can safely be converted to average reference with no loss of info"? |
Yeah I think that's right. And FWIW there are probably cases (maybe most of them?) where we could convert to an average ref without losing info or doing anything wrong mathematically, but so far there hasn't been a big need for it so we haven't implemented it. So I think |
See also #12407 where this same sort of issue was hit by a non-proj average ref. Concretely I'm thinking we shouldn't set The one place things will be wrong is in the forward modeling step. Right now we subtract the reference electrode forward from each electrode's forward. But I think it's probably okay/safe enough to set Then at some point we could add extra information in the extended channel info block about which channels were references (see also #12283) if needed, and fix the forwards as well. But that would be quite far down the road I think. |
May I ask what you mean by " |
I think there are some places in our code where this happens. Can't remember offhand but I think it does... maybe in channel interpolation or something?
No not this part. If |
Yeah could be useful imo, thanks for the clarification ! |
When processing a recent brainvision recording with FCz as the reference (which means it's not in the recording), I wanted to recover this channel in the data, use an average ref proj, and eventually source localize. So I wanted to do:
and have source loc etc. work. However, doing this we end up with two problems for source loc:
raw_eeg.info["custom_ref_applied"] == 1
raw_eeg.info["chs"][ii]["loc"][3:6]
is all zerosCorrect behavior here I think would be to have each EEG channel's
ch["loc"][3:6]
be FCz'sch["loc"][:3]
, and havecustom_ref_applied
be set to "off", i.e.:So concretely, I propose that in cases where
set_eeg_reference
is called with a single channel name and that channel name has a meaningful position (ch["loc"][:3]"
), we setcustom_ref_applied
to False and setch["loc"][3:6]
for all EEG channels properly.The text was updated successfully, but these errors were encountered: