Handle sEEG data sensibly

[maedoc]

Some discussion of how to handle sEEG data and forming bipolar montages started in #1003. I've opened a new issue because this is not really about file i/o.

At least with our data, the sEEG electrodes are plugged into the EEG inputs on the amplifier thus on import, they are marked as a EEG channel type. By hand or regex'ing the channel names, we separate into EEG and sEEG channels, and when forming bipolar montage, we've done it by hand and the software treats the channels simply as EEG channels.

It would be helpful however to explicitly represent sEEG if it doesn't present too many problems.

[agramfort]

I am thinking of a set_ch_type function in future BaseRaw and I see regularly issues with setups where I need to manually edit the channels types. eg. the EOG and ECG are set to EEG and it creates mess for rejection.

[agramfort]

in addition to the pick_types support for seeg and a new fiff constant for SEEG channels.

[dengemann]

set_ch_type

yes, and we should provide dummy channel dicts for arbitrary misc data such that it would be trivial to setup a Raw object from data about which we don't know anything specific besides that they are continuous and and have a certain sample frequency.

[maedoc]

Raw object from data about which we don't know anything specific besides that they are continuous and and have a certain sample frequency.

How hard is this currently? We've an in-house data visualizer for which I'd like to write mne-py based plugins, and it would require creating raws from existing data. Same is true for TVB for which I'd like to lean on mne-py for the analysis.

[dengemann]

@mmwoodman it's not hard but fidgety + you need to know what you do. Have a look at the internals of read_raw_bti or the other functions for non-Neuromag data to get an idea about the way it works ... The only real challenge is to assemble an info attribute that is compliant with mne-python and includes as much information on e.g. channel positions, coil types and units as is available. New types then have to be "registered" in mne.fiff.constants.py -- don't hesitate to ask if you have specific questions.

So there are two different integration models 1) add a raw class for addiitonal systems (what I just described) 2) add functions that make it easier to create custom raw objects, add custom channels + register their types + assemble corresponding info entries. Future integration attempts of class 1) of course could strongly benefit form 2). But we need to discuss this + put it into practice. Also see #870 and #542

[maedoc]

Since RawArray, I've gotten quite far, but at least for sEEG, I've written up code handling contacts, electrode, implantations and the montages, as well as parsers for electrode names. Handling positions of the electrodes is also useful for both forward modeling and visualization (3D).

Where would this fit in? Under io? Can we add an sEEG specific channel type, FIFFV_SEEG_CH, or another name consistent with OpenMEEG.

[larsoner]

Great! I'll let @agramfort think about the channel type. One potential issue is that if we add the channel type in mne-python, mne-C won't automatically know how to handle it... and users might (rightly) expect to be able to view raw files written out by mne-python to be viewable e.g. in mne_browse_raw. @mshamalainen would it be possible to add a type to the C code to match?

@maedoc when you say you've written code to handle electrode montages and locations -- the question is how specific these tools are to your lab's setup, and the extent to which they can be generalized for community use.

For example, let's say your routines parse an excel file created by the hospital containing electrode locations, and then populate an info dict for use with RawArray. It probably wouldn't be useful for mne-python to contain the excel-parsing utility (unless the file format were format common across many labs/recording setups), but it might be useful to have a helper function that populates or creates an info struct given an ndarray of electrode positions. This would help other labs that do ECoG more easily use mne-python. Does that make sense?

[maedoc]

Yep, I was thinking the same thing but had a more practical question : in which module would an MNE user most likely expect to find said functions? (I'm still not very familiar with the layout of mne-python)

[agramfort]

let's talk on hangout tomorrow during the sprint.