Back to the main page.
Bug 1501 - ft_spiketriggeredspectrum
| Status | CLOSED FIXED |
| Reported | 2012-06-02 10:14:00 +0200 |
| Modified | 2019-08-10 12:03:07 +0200 |
| Product: | FieldTrip |
| Component: | spike |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | Martin Vinck |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Martin Vinck - 2012-06-02 10:14:45 +0200
There are two complementary versions now. These need to be merged. I would do a similar style as in ft_freqanalysis, with two methods basically, one based on convolution of the whole trace with different time windows, and one based on the fft. In addition both raw and raw + spike inputs can be allowed for both functions.
Martin Vinck - 2012-06-03 18:53:12 +0200
I've renamed both functions and one is now called spiketriggeredspectrum_fft (since it is based on the fft around every spike) and the other _convol (as it is based on convolution of the entire LFP trace). the ft_spiketriggeredspectrum.m function now calls one or the other depending on cfg.method, all in analogy to ft_freqanalysis. Per default _fft is called such that users using the old ft_spiketriggeredspectrum.m function have no problem. I removed the ft_spike_triggeredspectrum.m functions and updated it and renamed it ft_spiketriggeredspectrum_convol.m. Especially the treatment of the frequencies has been improved -> the ft_specest_mtmconvol that was previously called does not nicely handle the frequency axis (because it adjusts it to the length of the trial, while it should depend only on the sampling rate and the number of samples in the window with which we convolve). Here convolution is used directly such that the DFT is computed using the right frequencies. The subfunction phase_est is called per frequency separately, which is an advantage in terms of memory for long LFP traces. Implementing both in a single function like was done in ft_freqanalysis is possible but I think the code is cleaner this way - besides I think the overlap is too minimal to make this useful. I have updated the test function for both (/contrib/spike/test/test_spiketriggeredspectrum.m). Both give identical results (aside from some rounding error). There are several features in the convol implementation which are lacking in the fft implementation, which should go in the fft option as well. 1) It takes both data and spike inputs. This has the advantage that we can correct for the sampling that introduces small phase shifts. This is apparent in the last figure in the test script. 2) First order polynomial fit is also removed from the LFP trace - useful for removing slow cable swings which are often present in animal physiology. 3) If the LFP saturates its voltage range, spike phases based on that LFP segment will get a NaN. 4) Spikes at the border of the window are still assigned a phase, by using the first phase that can be computed given a certain window length.
Martin Vinck - 2012-06-03 18:53:53 +0200
Robert: ft_spiketriggeredspectrum_convol.m and ft_spiketriggeredspectrum_fft.m probably don't belong to the /trunk. Where should they be?
Martin Vinck - 2012-06-03 18:54:55 +0200
included Roemer as the issues around estimating the instantaneous phase may interest him as well
Roemer van der Meij - 2012-06-04 05:35:06 +0200
Thanks for including me, I'm looking forward to looking at the code! (in China atm) In the mean time, on organization, is it maybe an idea to make a toolbox/subdir for all spike functions?
Robert Oostenveld - 2012-06-04 09:32:41 +0200
(In reply to comment #1 and #2) The new organization of the functionality appears logical to me. Also the way of dealing with the changes for the end-user seems fine. (In reply to comment #4) > is it maybe an idea to make a toolbox/subdir > for all spike functions? Yes, that will happen. The functions will move to fieldtrip/contrib/spike
Martin Vinck - 2013-03-04 22:30:44 +0100
bug closing time