Additional support for MFF
See original GitHub issueOn behalf of Brain Electrophysiology Laboratory, we would like to add support for all different flavors of MFF. The mne.io.egi
module can be used to read in raw MFF files, but we would like to be able to read MFF segmented files (analogous to Epochs
class) and MFF averaged files (analogous to Evoked
class). We would also like to be able to convert BaseRaw
, Epochs
, or Evoked
objects to continuous, segmented, and averaged MFF files respectively and write these as output files. Finally, we would like to be able to read and store a wider range of event track information from MFF files. MFF event track XML files contain several attributes for each event, such as label, duration, and response, that are not currently captured when reading in raw MFF files.
In order to address these requests, we propose using mffpy, a Python MFF reader/writer created by BEL for handling MFF inputs and outputs. This Python package is capable of reading and writing each of the different flavors of MFF as well as parsing individual XML files within an MFF directory. Our general proposal would be to make mffpy a dependency of MNE and then restructure the mne.io.egi
module to read in MFF files with mffpy and then convert them to the appropriate object (Raw, Epochs, or Evoked). We also want to add a module that takes Raw, Epochs, and Evoked objects and converts them to an mffpy Writer
object so that they can be output as MFF files. As far as event tracks, we are able to fully parse event track XML files with mffpy. We may need to create a new type of MFF events class to store this information, as it appears that event info is currently stored in a simple array with relative start time and event type.
We have developers at BEL that would be happy to implement these features. We are also happy to answer any questions about mffpy and how it could increase the functionality of MNE.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:3
- Comments:39 (39 by maintainers)
Top GitHub Comments
no objection on my side is we match the same performance for reading files and we support the preload option.
maybe start with evoked and epochs as there is not code for this at the moment
Sounds good. If you need to avoid a circular import problem you can nest the import