mne-tools / mne-connectivity

Connectivity algorithms that leverage the MNE-Python API.
https://mne.tools/mne-connectivity/dev/index.html
BSD 3-Clause "New" or "Revised" License
66 stars 34 forks source link

Adding cross frequency coupling connectivity measure #75

Open Div12345 opened 2 years ago

Div12345 commented 2 years ago

Describe the problem

Adding cross-frequency coupling as a connectivity measure. Between channels for single epoch type.

Describe your solution

Found this while searching for existing implementations - https://github.com/mne-tools/mne-sandbox/blob/master/examples/connectivity/plot_pac.py

agramfort commented 2 years ago

have a look at https://pactools.github.io

Message ID: @.***>

adam2392 commented 2 years ago

@Div12345 this looks good to me because it's a time-resolved measure. Pactools looks like it hasn't been updated since 2020.

I think PAC implementation and an accompanying example would be an awesome feature to add.

Div12345 commented 2 years ago

@adam2392 So by PAC implementation you mean adapting it to this codebase format and integrating it here or as a dependency?

adam2392 commented 2 years ago

I would lean towards integrating it here instead of as a dependency since pac tools isn't maintained.

agramfort commented 2 years ago

ping @TomDLT who might be interested in giving a hand here

TomDLT commented 2 years ago

Pactools is not actively maintained because I don't work on these topics anymore, but everything should still work fine. Feel free to take part of it to MNE and credit pactools. I won't have time to do the integration myself, but I can help on the discussion.

Implementing a simple PAC metric as in [Penny et al 2008] or [Tort et al 2010] should be straightforward. However, most PAC metrics suffer from the same issue, which is that one cannot validate the metric on a separate test set. This issue makes most PAC metrics arbitrary/overfitting, because parameters cannot be cross-validated. One of the few metrics that can be cross-validated is the one described in [Dupre la Tour et al 2017] (disclaimer: I am the first author). This metric is also more robust, and allows to disentangle phase shifts from time differences. However, this metric relies on DAR models which would be less straightforward to integrate into MNE. (Another metric with similar properties is described in [Soulat et al 2019], which has a unique potential to model non-sinusoidal oscillations (!), but I don't know if there is an open-source implementation.) One option could be to integrate some simple PAC metrics (maybe [Penny et al 2008] and [Tort et al 2010]), and have an optional dependency to pactools for other metrics.

adam2392 commented 2 years ago

Implementing a simple PAC metric as in [Penny et al 2008] or [Tort et al 2010] should be straightforward. However, most PAC metrics suffer from the same issue, which is that one cannot validate the metric on a separate test set. This issue makes most PAC metrics arbitrary/overfitting, because parameters cannot be cross-validated. One of the few metrics that can be cross-validated is the one described in [Dupre la Tour et al 2017] (disclaimer: I am the first author). This metric is also more robust, and allows to disentangle phase shifts from time differences. However, this metric relies on DAR models which would be less straightforward to integrate into MNE. (Another metric with similar properties is described in [Soulat et al 2019], which has a unique potential to model non-sinusoidal oscillations (!), but I don't know if there is an open-source implementation.) One option could be to integrate some simple PAC metrics (maybe [Penny & al 2008] and [Tort & al 2010]), and have an optional dependency to pactools for other metrics.

@Div12345 seems like we could approach this in two steps: 1) integrate two simple PAC algorithms referenced here and then 2) add the third algorithm that simply wraps PACtools as a soft dependency for now.