Closed EtienneCmb closed 1 year ago
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
andRaw
objects). While some of the spectral connectivity functionality can work witharray_like
objects, users of other data modalities such as non-human electrophysiology data may findmne-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, theexpectation_type
parameter of theConnectivity
class allows the user to average over trials, tapers, or both, allowing the same module to yield single-trial or summarized estimates.
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".
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.
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
Regarding the comparison with MNE-Python, you wrote :
I understand your point, it's true that MNE strongly relies on its
Epoch
orRaw
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 :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)