ecog functionality?

[choldgraf]

hey folks - not sure if this is the right space to post this, so I apologize if it's not, but I wonder how you all feel about including electrocorticography analysis under the scope of this project. It's quite similar to EEG / MEG, so I imagine that it could mostly entail adding extra functions that do things ECoG people may care more about.

Nothing concrete in mind yet, just want to know how you all feel about this, as I think this project looks great and would love to help out however I can.

[larsoner]

@choldgraf I have actually used mne-python to process ECoG data before. The raw-data processing pipeline involving filtering/de-noising, epoching, etc. I found very useful, but I'm used to using it :) The stats functions were also general enough to be applied as needed.

I'd be +1 in general for adding functions to accommodate ECoG data. Do you have a sense of what's missing from the package for your use case? If it's mostly just data I/O for certain formats, for example, that can be fairly easily fixed. Eventually we could think of the "inverse" for ECoG data as being a very simple, maybe smoothed matrix since there is no ambiguity regarding source localization. I think I wrote something simple that mapped the ECoG electrode locations to locations in source space for the purposes of plotting, but that was pretty rudimentary. But it would depend on what you want to do with the data.

[choldgraf]

My plan right now is to start trying to incorporate mne more into my own pipeline, so that I can get a better feel for how it works in the context of ECoG. Right now it just looks promising to me so I thought I'd reach out :)

I'm currently using EEGLab as a first step in my data cleaning step, and then trying to move the data over to python as soon as possible in the pipeline. That said, I'm largely using EEGlab for the "browsing through data and marking bad timepoints / electrodes" part of the process, and it sounds like maybe MNE can accomplish this just as well?

As for data formats, my experience is that there are a LOT of different formats out there because labs don't necessarily have standardized recording equipment / software. That said, our lab has a lot of scripts to interface with formats that we've encountered before (though they're written in matlab), so perhaps an early project could be trying to port those over to python.

[agramfort]

Hi Chris,

i'd love to see EcOG features in MNE. And personally I'd be curious to
do proper inverse modeling of such data using forward models from
OpenMEEG :)

when you can be more specific about your needs please share so we can
see how to join forces.

@Eric89GXL you process EcOG data with MNE in secret :)

is there a chance to make some good EcOG data public? is there already any?

[choldgraf]

Maybe there is - I'll look into our data sets and see how my PI feels about making some available for development purposes. Main concern is subject identity protection, but if it's only electrode numbers, time series, and MNI coordinates, then perhaps that won't be a problem?

Either way, I'm having a hard time figuring out how to import my data into MNE in the first place. Lots of functions for importing from particular data formats, I've literally just got an array loaded into python...

[larsoner]

We don't currently have support for loading arbitrary data from an array to be treated as a raw object. There are many relevant fields of Raw that must be populated in order for it to integrate properly downstream (Epochs, time-freq, plotting, etc.). Back when I forced in some data, I just hacked a solution to get it done. I think that was actually at the evoked stage, but the principles are similar. If you want, I could try to whip up something simple you could build off of for your particular use case.

@agramfort this might actually be a good time to think about moving toward having a BaseRaw class that all the other raw classes can subclass.

@choldgraf, in terms of getting permission to share data, the data you provide can be very basic and still be quite helpful. The MNE sample dataset for example contains responses during a very simple task, which is very convenient for validation. So if you have any datasets that contain a simple task (like motor movement maybe?) that might be ideal. If you can get them, the data would ideally also include brain surfaces (e.g., what Freesurfer gives you in reconstruction) as well. That would allow for easy visualization and integration with related tools, like PySurfer. If those aren't available, though, it's not critical.

[agramfort]

Maybe there is - I'll look into our data sets and see how my PI feels
about making some available for development purposes. Main concern is
subject identity protection, but if it's only electrode numbers, time
series, and MNI coordinates, then perhaps that won't be a problem?

I guess it would be fine.

[agramfort]

@agramfort https://github.com/agramfort this might actually be a good
time to think about moving toward having a BaseRaw class that all the
other raw classes can subclass.

https://github.com/choldgraf

+100

@choldgraf https://github.com/choldgraf, in terms of getting permission
to share data, the data you provide can be very basic and still be quite
helpful. The MNE sample dataset for example contains responses during a
very simple task, which is very convenient for validation. So if you have
any datasets that contain a simple task (like motor movement maybe?) that
might be ideal. If you can get them, the data would ideally also include
brain surfaces (e.g., what Freesurfer gives you in reconstruction) as well.
That would allow for easy visualization and integration with related tools,
like PySurfer. If those aren't available, though, it's not critical.

+1

[dengemann]

@Eric89GXL @agramfort yes, we need a BaseRaw. I'll soon need to hack stuff to merge data from EGI EEG with Neuromag data. So this is really timely.

[larsoner]

Denis do you have to time to work on it? If not I can take a stab at it.

[agramfort]

I think Denis is drawning :-/

[adykstra]

I was thinking that adding some support for ECoG would be something I'd be interested on working on at the sprint. I certainly need to elevate my belt level to tackle something that big, but the sprint would be a great opportunity with all the Pythonistas there. @agramfort, does the OPENMEEG stuff support 4-shell BEMs?

[dengemann]

Eric, to work on what? The Ecog or the from_data generalization? The latter is bookmarked, I'll add that over the next weeks. Ecog no time :-(

[dengemann]

... realized the discussion was quite dated. @adykstra would be great to have you working in that --- and yes you won't be alone :-)

[adykstra]

Just came across issue #381 when doing a search for OpenMEEG in the repository. @agramfort the OpenMEEG code is accesible from Python, no? Also, I read on the Brainstorm site that OpenMEEG supports the calculation of lead fields for intracranial electrodes (image below). Based on these two facts, how much effort would it take to support source localization for ECoG/sEEG recordings? Also, a specific question about the forward calculations in OpenMEEG - do they take the silastic sheet into account?

[agramfort]

I was thinking that adding some support for ECoG would be something I'd be
interested on working on at the sprint. I certainly need to elevate my belt
level to tackle something that big, but the sprint would be a great
opportunity with all the Pythonistas there. @agramforthttps://github.com/agramfort,
does the OPENMEEG stuff support 4-shell BEMs?

OPENMEEG does support 4-Layers BEM with EcOG but clearn integration into
MNE is not trivial. Although it has Python bindings.

That's ambitious for 3 days. do you have data for it?

[agramfort]

Just came across issue #381 when doing a search for OpenMEEG in the repository. @agramfort the OpenMEEG code is accesible from Python, no? Also, I read on the Brainstorm site that it supports the calculation of lead fields for intracranial electrodes (image below). Based on these two facts, how much effort would it take to support source localization for ECoG/sEEG recordings?

a PhD? just kidding... but I honestly think it's really ambitious for
5 days. To be worth it you would need to have a strong personal
interest to complete the project and use it yourself.

Also, a specific question about the forward calculations in OpenMEEG - do they take the silastic sheet into account?

no we don't.

[adykstra]

I guess I wasn't thinking we'd finish it in such a short time, but rather start it to the point where I (and others? maybe a masters student?) could continue working afterwards.

It is something I'd use and would like to see implemented, and I imagine there are many ECoG/sEEG folks who would use such a tool if it were readily available. Brainstorm now does this I guess, but something having been implemented in MATLAB hasn't seemed to stop the folks here from implementing it also.

I have intracranial data from my PhD we could likely use - would have to get the necessary approval from powers that be.

I guess a first step would be to work on getting OpenMEEG integrated with MNE-Python?

[agramfort]

I guess I wasn't thinking we'd finish it in such a short time, but rather start it to the point where I (and others? maybe a masters student?) could continue working afterwards.

what you propose is what i have in mind for a student project next year:

https://github.com/mne-tools/mne-python/wiki/Paris-Saclay-Software-Project

we can discuss the challenges during the sprint and make a more detailed
plan certainly.

It is something I'd use and would like to see implemented, and I imagine there are many ECoG/sEEG folks who would use such a tool if it were readily available. Brainstorm now does this I guess, but something having been implemented in MATLAB hasn't seemed to stop the folks here from implementing it also.

:)

[choldgraf]

Jumping back in this discussion - FWIW I'd also take advantage of an ECoG set of functionality, though in general I think the first step towards doing this would be implementing the aforementioned "general data import" methods.

Most ECoG that I've dealt with has come in a wide variety of formats, naming conventions, numbering conventions, etc. It also has high variance in terms of the quality (or existence) of supplementary information like MRI, CT scans, and stimulus information. Most ECoG labs I work with have their data saved in something like a matlab structure with accompanying parameter fields, or in my case an HDF5 file with a set of pickled parameters.

All this is to say that I think ECoG functionality in MNE would require more flexibility in the kinds of data that it can import.

[choldgraf]

Also, FWIW, I'll be visiting Harvard in mid-June for a few days for a conference (I'm at Berkeley currently). It seems that some folks with MNE are in Boston, no? If any of you are around and want to grab a coffee to talk about contributions that I could make, I'd be happy to chat.

[agramfort]

All this is to say that I think ECoG functionality in MNE would require
more flexibility in the kinds of data that it can import.

again +1

did we agree on the API?

info = ... # function to generate info easily
mne.io.raw_from_data(data, info, firstsamp=None)

does not sound good?

[agramfort]

yes @mluessi @mshamalainen @dgwakeman @SherazKhan @haribharadwaj are there... hope I did not forget somebody...

[larsoner]

@agramfort I think that's the plan, yes. @dengemann did you start on it, I can't remember? If not, I can probably do it Monday since it seems to be in high demand, and also holding up contributions / people from potentially using the software.

[adykstra]

@choldgraf I'm not in Boston, but I have experience with intracranial data as well and I'll be in the bay area in early August. I'd be happy to meet/chat with you, especially if it's at Blue Bottle, Philz, Ritual, or the like. :)

[choldgraf]

@agramfort I think that's a good start for general import, I'm using something like this in my own code.

Another thought would be to have some sort of to_ / from_csv function that could import required parameters. You could even create a "gen_blank_csv" that had fields for any required information that the person could fill out manually.

@adykstra happy to chat about MNE if you're in town!

[agramfort]

Another thought would be to have some sort of to_ / from_csv function that
could import required parameters. You could even create a "gen_blank_csv"
that had fields for any required information that the person could fill out
manually.

that's from the ... about reading / generating valid info dict.

lets continue discussing to get an API as simple and commonly useful for
the majority.

[dengemann]

does not sound good?

exactly what I had envisioned over the last days @agramfort

did you start on it, I can't remember?

Nope. Please feel free to take the first steps. I'll mingle in. Raw from data has a very high priority @Eric89GXL .

[haribharadwaj]

@choldgraf, I don't have any experience with ECOG data but happy to chat when you come to Boston..

[choldgraf]

hey all - it seems like this issue has been discussed in a few threads now, but I'll bring it up here since it's the most focused on ECoG.

I've been playing around with MNE now that there's functionality for turning arbitrary arrays into Raw objects. One thing that we've found useful in, e.g., EEGLab, is the ability to have a quick, flexible way to scan through the data for the purposes of marking bad electrodes and bad timepoints (e.g., epileptic activity).

plot_raw gets very close to this (and is much snappier than matlab version), though it would be useful to have some more keyboard functionality than is currently there. As a starter, here are some things that would be most useful:

1. Two buttons that increment the scaling parameter up/down
2. An option to re-plot with certain electrodes available
3. Ability to mark timepoints in the plot. E.g., "Shift+left click" marks the beginning of a marker, and "Shift+right click" marks the end of a marker. This is important for marking seizure points to remove in analyses.

So I suppose a more general question is: how open are you all to expanding the keyboard functionality of plot_raw? Would this be relatively straightforward to do with the backend that you all are using? I am happy to teach myself a bit of interactive plotting and try to throw something together...

[dengemann]

@choldgraf thanks for the feedback. I would love to see the functionality you desire in 'plot_raw'. the scaling would be a bit tricky (increment global scalinig? specific sensor? which sensor?). Also I'm not sure what the re-plot woild do. but in general there is no obstacle, it' absolutely doable to add more interactive functionality to raw plot. only a question of development time available. If you feel inclined you are more than welcome to work on it ;-)

[agramfort]

+1 for making the raw data browser more user friendly.

[larsoner]

I'm going to close this for now, @choldgraf I trust you will make issues and PRs now for the specific things of interest :)

[choldgraf]

Good idea - I still like all of these ideas and will work on them as the
semi-random process of my mind finds use :)

Chris

On Mon, Apr 20, 2015 at 10:38 AM, Eric Larson notifications@github.com
wrote:

I'm going to close this for now, @choldgraf https://github.com/choldgraf
I trust you will make issues and PRs now for the specific things of
interest :)

—
Reply to this email directly or view it on GitHub
#1206 (comment)
.