Back to the main page.

Bug 2822 - implement frequency domain MNE

Reported 2015-02-02 14:32:00 +0100
Modified 2019-08-10 12:31:08 +0200
Product: FieldTrip
Component: inverse
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P5 normal
Assigned to: Luca Ambrogioni
Depends on:
See also:

Robert Oostenveld - 2015-02-02 14:32:23 +0100

This should basically extend the current implementation in (underneath) ft_sourceanalysis with the source estimation approach outlined in Fa-Hsuan Lin, Thomas Witzel, Matti S. Hämäläinen, Anders M. Dale, John W. Belliveau, and Steven M. Stufflebeam. Spectral spatiotemporal imaging of cortical oscillations and interactions in the human brain. Neuroimage. 2004 October ; 23(2): 582–595. doi:10.1016/j.neuroimage.2004.04.027. In first attempt it should remain consistent with the data handling for lcmv and disc and therefore not 1) loop over frequencies 2) loop over time but those can be considered for later extensions. Furthermore, the connectivity part in the paper is not part of ft_sourceanalysis, but follows later in the pipeline with ft_connectivityanalysis. You should check that the output of the frequency domain MNE is suitable as input in ft_connectivityanalysis. If not, that requires another but to be opened.

Luca Ambrogioni - 2015-02-16 15:49:19 +0100

2/16/2015 The current implementation of MNE (actually the ft_sourceanalysis function) can deal with the combination freq data/mne method by calling the function freq2timelock that converts the data structure in a (fake) timelock structure. The all procedure doesn't give errors but the output should be transformed back to a freq structure (through timelock2freq), currently it doesn't and therefore the output of the all analysis doesn't make any sense.

Luca Ambrogioni - 2015-02-16 15:54:30 +0100

From some comments in the documentation of timelock2freq ( "% hmmm... I have no idea whether this is correct", "% reconstruct something that spans the same space as the fft of the data, hmmm...") it seems that the author didn't have a completely clear idea of what he/she was doing :p Anyway I think that we could avoid this hack altogether and write down a more elegant implementation, what do you think Robert?

Robert Oostenveld - 2015-02-16 20:56:19 +0100

(In reply to Luca Ambrogioni from comment #1) freq2timelock should not be used, that is a last resort for converting freq into timelock in cases where it is unexpected. It completely messes up the channel structure, since frequencies are mapped along channels, e.g. { 'Cz@10Hz' 'Cz@11Hz' 'Cz@12Hz' 'Cz@13Hz' 'Cz@14Hz' 'Pz@10Hz' 'Pz@11Hz' 'Pz@12Hz' 'Pz@13Hz' 'Pz@14Hz' ... } The data should be handled properly as freq throughout.

Luca Ambrogioni - 2015-03-09 14:33:03 +0100

bash-4.1$ svn commit test/test_bug*m Adding test/test_bug2822.m Transmitting file data . Committed revision 10271.

Luca Ambrogioni - 2015-04-02 10:09:18 +0200

I finished to update the MNE code for the freq input (I will submit it soon). Now the high level function "ft_sourceanalysis" should be updated accordingly: -the Fourier spectrum input should be fed to "minimumnormestimate" as a channel times trials (or tapers) complex matrix -the cross-spectral density input should be fed as a CSD matrix. The code can automatically detect whether the input is a timeseries (real), fourier coefficients (complex) or a CSD (square, Hermitian and complex). The freq2timelock function should not be called anymore. For now, a single frequency should be selected.

Jan-Mathijs Schoffelen - 2015-04-09 09:19:33 +0200

/home/language/jansch/matlab/fieldtrip [jansch@mentat002 fieldtrip]$ svn commit -m "enhancement - changes in bookkeeping and clean up of code to facilitate frequency domain data input to some methods" ft_sourceanalysis.m Sending ft_sourceanalysis.m Transmitting file data . Committed revision 10330. I have made some updates to ft_sourceanalysis, which hopefully don't break the rest of the functionality. Right now, it should pass on the fourierspctrm to minimumnormestimate. I did not change minimumnormestimate because Luca has a version of his lined up to be committed. Could you pass that to me for a quick quality check so that we can commit, and continue working on it? Note: the other methods 'rv' and 'music' need to be addressed as well.

Luca Ambrogioni - 2015-04-09 11:06:15 +0200

I just sent you the cose

Luca Ambrogioni - 2015-07-20 11:50:44 +0200

Now all the source reconstruction methods (except for music) are implemented for frequency domain data.Right now they need a single frequency as input, therefore do not output the ful soure-level spectrum. I think that this "bug" is ready to be closed.

Robert Oostenveld - 2015-08-19 15:33:23 +0200

(In reply to Luca Ambrogioni from comment #8) Could you update the test script to demonstrate that the time-domain and the frequency domain reconstructions are identical (up to a scaling constant) in case you generate time-series data that consists of a sine-wave modulated scalp topography?

Luca Ambrogioni - 2015-11-16 11:17:03 +0100

The methods have been implemented

Robert Oostenveld - 2019-08-10 12:31:08 +0200

This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue on