Problem extracting x,y position from montage to use with plot_topomap

💬 Support & Discussions
1

Hi all,

For what I hope to be a new addition to the MNE ecosystem (GitHub - GWeindel/hsmm_mvpy: Repository for the hsmm-mvpy package) I am looking to extract and use x,y position of EEG electrodes and feed them to plot_topomap(). I want users to be able to specify positions without having to read raw data and apply a montage on it (e.g. if someone has channel locations from another source than MNE).
It works nicely with EEGLAB channel output but when I try using only x,y positions from an mne.montage I fail to reproduce the result from plot_topomap() when using the raw.info with the same montage

I guess this is my misunderstanding of the way topomap and montages work and not a bug so I only post an example of how I do it but can provide a minimal working example if needed

raw = mne.io.read_raw_brainvision("MD3-%s.vhdr"%subj_num, preload =False)
raw.set_montage('easycap-M1')#Standard 1020 electrode montage
montage = raw.info.get_montage().get_positions()['ch_pos']
positions = np.array([montage[x][:2] for x in eeg_data['electrodes'].values])#Extract x and y positions of each electrode

When plotting, feeding raw.info to plot_topomap() gives the expected result:

image
image782×97 58.9 KB

but feeding positions does not

image
image782×97 56 KB

What am I missing?

Best,
Gabriel

  • MNE version: 1.0.3
  • operating system: Ubuntu 20.04
2

.get_positions() gives you X, Y, Z in real world coordinates (either digitized directly from the cap on the subject’s head, or idealized spherical-head positions for template montages). These are measured in meters. For plotting topomaps, internally MNE-Python does something more complicated than just discarding the z coordinate. The heavy lifting is done in this private function. Let us know if that’s not enough to get you sorted.

3

Oh thanks that looks indeed like what I need! I will play with the function and keep you posted

4

great! although I must include the standard warning that the API of private functions is not guaranteed to be stable, and using our private functions in your packages / analysis scripts is discouraged. Ideally either you find a way to get what you need through the public API, or if that is impossible, you propose (in a new GitHub issue) why we should make that one public. (be as convincing as you can, as expanding our public API is a maintenance burden so we don’t do it automatically at every request).

2 Likes