mne-tools / mne-python

MNE: Magnetoencephalography (MEG) and Electroencephalography (EEG) in Python
https://mne.tools
BSD 3-Clause "New" or "Revised" License
2.63k stars 1.31k forks source link

ENH: Visualizing colocated MEG signal vectors #11579

Open larsoner opened 1 year ago

larsoner commented 1 year ago

In OPMs (or if you work with fluxgates!) it's common to have two or three measurements at the same physical location, i.e., a vector-valued channel amplitude. This makes things like plot_topomap not work without some channel picking, and then you end up with incomplete information. (For VectorView/TRIUX it works because we pick mags -- but if that system had 3 mags instead of 1 mag 2 grad at each location it would have the same problem.) It would be really nice to visualize these automatically and nicely. Ideas, which I think I'd probably use all of at different times/use cases:

  1. Project activity to a spherical source space then back out to point mags at each location oriented outward. This is what xfit does with Neuromag data IIRC and something we probably want anyway / independent of this colocation issue.

    • API: source_proj='auto' or something that projects to source space then back out to outward-oriented point mags when MEG sensors are physically colocated, and can be set to True e.g. for Neuromag data to get data from all 306 sensors at least used at once.
  2. Instead of plotting 1 head+sensor array, plot 3 head+sensor arrays (like at the vertices of an equilateral triangle?) in the same set of axes so you can visualize all three directions at once.

    • API: colocated='xyz' (default) | 'x' | 'y' | 'z' or something might work to say which of the doublets/triplets to use.
  3. Allow reorientation of the MEG sensors to the device frame. By default for most systems AFAIK, Z is local to the sensor and points outward. For these vector-valued measures we could rotate so that X/Y/Z is RAS in the MEG device frame.

    • API: sensor_frame='local' (default) | 'meg' could work for this, and would work nicely with the "colocated" plots to make sure x/y/z are actually interpretable.

@georgeoneill @jasmainak (and anyone else working with OPMs!) do you have other ideas? What do you think of the above?

jasmainak commented 1 year ago

We don't have x/y/z measurements with the OPMs yet ... not sure if it's even possible with the Fieldline system we have. I haven't started to think about how such an analysis might proceed. However, both 1. and 2. sound reasonable approaches to me and 3. sounds a little convoluted.

Perhaps 1. could lead to potential issues, if the helmet surface is non-spherical. In fact, that is one issue I have been observing with individualized helmets that is common in OPM research. The topomaps can be misleading or distorted because the surface is not spherical and the projection assumes a spherical surface. My immediate thought was to visualize the topography directly on a 3D helmet surface in the same spirit as make_field_maps to avoid this issue, but I haven't gotten around to it yet.