[JOSS] Comparison with MNE

[EtienneCmb]

Regarding the comparison with MNE-Python, you wrote :

mne-python is a much larger package designed as a full-featured analysis library for EEG and MEG data, and using the spectral analysis functions requires representing data using its ecosystem.

I understand your point, it's true that MNE strongly relies on its Epoch or Raw container that have not been designed to handle non-human electrophysiological data. But to be fair on the comparison, MNE also have functions that can be applied to non-human LFP using standard NumPy array inputs. For example, in line with this package :

• mne.time_frequency.psd_array_multitaper and mne.time_frequency.tfr_array_multitaper : PSD and time-frequency maps using multi-tapers
• mne_connectivity.spectral_connectivity_time and mne_connectivity.spectral_connectivity_epochs : both functions implement connectivity metrics, using multi-tapers and support on NumPy array

In my opinion, the strength of this package lies in the parameter expectation_type. It's a smart and flexible design because it allows having single-trial and possibly dynamic estimations of functional connectivity using a single implementation, while in MNE they had to use two different functions.

xref : JOSS (https://github.com/openjournals/joss-reviews/issues/4840)

[emilyps14]

True, although it looks like mne_connectivity.spectral_connectivity_time does require an Epochs object, as it accesses data.ch_names etc.

How about I soften the language in that sentence, to say something like:

mne-python is a much larger package designed as a full-featured analysis library for EEG and MEG data, and works best when the data is represented using its ecosystem (i.e. Epochs and Raw objects). While some of the spectral connectivity functionality can work with array_like objects, users of other data modalities such as non-human electrophysiology data may find mne-python too cumbersome for their application.

Then we can highlight the expectation_type functionality in a footnote:

...spectral_connectivity is designed to handle multiple time series flexibly[^1] and can exploit GPUs for faster and more efficient computation. ... [^1]: for example, the expectation_type parameter of the Connectivity class allows the user to average over trials, tapers, or both, allowing the same module to yield single-trial or summarized estimates.

[EtienneCmb]

Hi @emilyps14,

True, although it looks like mne_connectivity.spectral_connectivity_time does require an Epochs object, as it accesses data.ch_names etc.

You're right, this function is still WIP. When this PR will be merged, array_like inputs are going to be supported as well (see here, it's already implemented). The PR is under review, it's a matter of a few weeks before being merged.

"[...] users of other data modalities such as non-human electrophysiology data may find mne-python too cumbersome for their application."

array_like inputs can be converted to Epoch in a very few lines of code :

from mne import EpochsArray, create_info

info = create_info(ch_names, sfreq)
epoch = EpochsArray(data, info, tmin=times[0])

I agree with you that it's not as direct as your package but I would not qualify it as "cumbersome".

[emilyps14]

It's cumbersome also because of the size of the package, and having to install the whole package (which is nontrivial) just to use a small set of functions which don't leverage the primary strengths of MNE-python. E.g. the installers recommend having a conda environment just for MNE-python, which doesn't make sense for folks who only want to use it for spectral connectivity functions.

[EtienneCmb]

Personal experience, but all the students here are using MNE, none ever had any issue installing MNE on a broad range of systems. Regarding the conda environment, it's convenient for non-programmers as everything (data analysis, visualisation etc.) can be installed via a single command and avoid any conflicts between versions. But if folks are just interested in spectral connectivity functions, MNE can be installed through pip and the list of minimum requirements is light.

IMO, you could consider different points of comparison with MNE : 1) The architecture of your code is more flexible (cf. expectation_type) 2) You included connectivity metrics they don't have (e.g. the coherence that can combine several channels. This feature is indeed interesting for sparse recordings like ECoG, iEEG, LFP etc.) 3) Maybe your implementation is faster or more accurate, in that case, you could provide a comparison

[EtienneCmb]

Hi @emilyps14,

Regarding the comparison with other software, in our team, we also made a software called Frites (see JOSS paper) that includes single-trial estimates of FC, however, we are more on the information-theory side (see here the API). Also, it's not as flexible as in your design.