data exchange between .fif (MNE) and SPM

[tierneytim]

Use cases requiring a switch between processing in MNE and SPM for M/EEG need to be investigated for compatibility of data structures.

potential issues are:

1. Does SPM need a simple function to convert data to .fif file?
2. How are balancing matrices handled?

[johmedr]

As a very first step it could nice to enable converting between MNE and SPM at some very specific stages of processing (e.g., getting data out of SPM after applying AMM).

[vlitvak]

I think it would make sense to implement an SPM reader to MNE struct and that could then be exported to fif in MNE.

[vlitvak]

I understand it can read mat files and the dat file is just a binary file that should also be easy to read. I once tried writing that and they then put the code bit in some repository of code bits but it'd probably be easier to write it from scratch than to look for that now. I'd be happy to help with the details of the format. It should be well documented in meeg.m header.

[johmedr]

That makes sense. For now the code allows you to read a meeg object, and necessarily there is a dict representation of the object hidden in the class (in meeg._objdict). That contains all the parameters, including the .inv field of the object. For the file_array containing the data, indexing is working now, so you can get the data by calling D[:,:,:]. Then it should be a matter of putting that correctly in a mne object !

[Y-Bezs]

I will check how it is done with fieldtrip to fiff function

[vlitvak]

As I said on the other thread I think it makes sense to see how to put data from the kind of structures Johan's code generates into MNE structures and vice versa rather than develop fif export for SPM. The key question is whether FT's grad struct can be converted into something MNE can use. The rest should be easy.

[vlitvak]

But if you want to use FT code D.ftraw and D.fttimelock object methods should be helpful

[tierneytim]

The key question is whether FT's grad struct can be converted into something MNE can use.

This is my main worry. The .tra field is crucial to be exported.

[Y-Bezs]

Great, thank you for suggestions. I will look into it.

[vlitvak]

It might be useful to consult Britta Westner https://github.com/britta-wstnr. She has a deep understanding of both FT and MNE.

[georgeoneill]

I don't think MNE has an equivalent to .tra (they use a special case for CTF synthetic gradiometry), but I think its something they will need to support in the long run.

Reading in an SPM MEEG dataset as a raw-fif type file in MNE should be pretty striaightfroward (from my experience adding the FIL OPM data format to MNE) and I think we can store the balancing within it. Getting MNE to utilise it is a different story.

[vlitvak]

Might be a good idea to talk to Britta and other MNE people as they might have their own plans for those things and if they know there is a clear need and use case, they might adapt to us rather than us adapting to what they have available.

[tierneytim]

just adding brittas thoughts here for everyone to be aware of

1. As you have identified in the Github thread, MNE-Python indeed does
   not have a tra structure. There are different ways to deal with
   effects on the sensors in MNE, either via modification in-place (e.g.
   when applying synthetic gradient denoising, see “Returns” here:

2. or via projectors (e.g. when using SSP for cleaning, see here for an
   overview.):
   Things like SSS and tSSS get capture in the info object as well (which
   I believe Eric says is mostly for historical reasons).

We're not sure that option 2. is viable but @Y-Bezs will explore option 1 while working from home over winter break