G-Node / nixworks

Python package with nix-helpers
BSD 3-Clause "New" or "Revised" License
0 stars 5 forks source link

Neo & MNE compatibility with Nix #22

Open JuliaSprenger opened 4 years ago

JuliaSprenger commented 4 years ago

With nixworks EEG data can be represented in Nix via the MNE package. This includes Brainvision (vhdr) as well as EDR files. Both of these formats are also supported to some extend by the Neo library (BrainvisionIO and potentially AxonIO or WinEDRIO), which also has an interface to the Nix format via the NixIO. For me there are two interesting aspects here:

  1. For the implemented formats, are the Nix files generated via MNE and Neo compatible, ie. can they be read by the respective other program?
  2. Is there a general guideline on how data in nix should be organised such that the Nix format could be in general used as an intermediate between MNE and Neo?
achilleas-k commented 4 years ago
  1. For the implemented formats, are the Nix files generated via MNE and Neo compatible, ie. can they be read by the respective other program?

I haven't tried but I doubt it. The Neo-NIXIO reader assumes a few things when reading objects, not least of which is that things like DataArrays specify their Neo type in the type attribute (neo.analogsignal or neo.irregularlysampledsignal). Similarly for MultiTags and Events, Epochs, and SpikeTrains. The objects created by the mne2nix converter would be ignored by the reader.

The topic has come up to make the Neo-NIXIO reader try to "guess" what a NIX object should map to in Neo based on things like dimensions, but I never tried to formalise this in any way and I expect it would cause more issues than it would solve.

  1. Is there a general guideline on how data in nix should be organised such that the Nix format could be in general used as an intermediate between MNE and Neo?

I guess one way to do it would be to write the NIX files in a way that's compatible with the Neo-NIXIO mapping, which is documented here: https://github.com/G-Node/python-neo/wiki/Mapping. That would essentially make the mne2nix converter create Neo-NIX files, that is NIX files that are readable in Neo. I wouldn't be against that. It would increase the utility of the converter. Perhaps it could be an optional switch.

You say Neo can read the EEG data formats "to an extent". Are there parts it can and can't read? The mne2nix converter is similar. We based the initial implementation on a specific set of example files we had from a collaborator, so if there are any data or metadata attributes in the files that these files didn't use, it's possible we don't write them out.

JuliaSprenger commented 4 years ago

The topic has come up to make the Neo-NIXIO reader try to "guess" what a NIX object should map to in Neo based on things like dimensions, but I never tried to formalise this in any way and I expect it would cause more issues than it would solve.

Yes, I agree. This kind of flexibility would probably lead to a number of issues in the long run.

You say Neo can read the EEG data formats "to an extent". Are there parts it can and can't read? The mne2nix converter is similar. We based the initial implementation on a specific set of example files we had from a collaborator, so if there are any data or metadata attributes in the files that these files didn't use, it's possible we don't write them out.

For the vhdr format, Neo provides the BrainvisionIO, capable of extracting basic header information as well as AnalogSignals, however, I don't konw if there are additional information contained, that can be accessed via EEG specific software. For the EDR format, it is unclear to me if there is only a single EDR format specified or if the supported versions by Neo (see linked IOs in https://github.com/G-Node/nixworks/issues/22#issue-611986099 ) differ from the one covered by nixworks.

However, in general I have the impression that a representation of EEG and ephys data in a fashion that's compatible with Neo and requirements posed by EEG data is possible and of advantage in the long run.