Back to the main page.
Bug 3469 - unclear use of ft_spiketriggeredspectrum_stat
| Status |
NEW |
| Reported |
2019-01-14 16:23:00 +0100 |
| Modified |
2019-01-14 16:23:45 +0100 |
| Product: |
FieldTrip |
| Component: |
core |
| Version: |
unspecified |
| Hardware: |
PC |
| Operating System: |
Windows |
| Importance: |
P5 normal |
| Assigned to: |
|
| URL: |
|
| Tags: |
|
| Depends on: |
|
| Blocks: |
|
| See also: |
|
Stephen Whitmarsh - 2019-01-14 16:23:45 +0100
Hi there,
I am just putting down my thoughts here, in the hope of improving/clarifying the spike analysis in FT together.
I have been following the tutorial on spikeanalysis, and have now done calculated the spiketriggeredspectrum, according to the tutorial:
cfg = [];
cfg.method = 'mtmconvol';
cfg.foi = 20:10:100;
cfg.t_ftimwin = 5./cfg.foi; % 5 cycles per frequency
cfg.taper = 'hanning';
stsConvol = ft_spiketriggeredspectrum(cfg, data_all);
I get an out as described in the tutorial (here from the tutorial, as I can't copy-past from the server here):
stsConvol =
lfplabel: {4x1 cell}
freq: [20 30.1205 40.3226 50 60.9756 71.4286 80.6452 89.2857 100]
label: {'sig002a_wf' 'sig003a_wf'}
fourierspctrm: {[83616x4x9 double] [61526x4x9 double]}
time: {[83616x1 double] [61526x1 double]}
trial: {[83616x1 double] [61526x1 double]}
dimord: '{chan}_spike_lfpchan_freq'
trialtime: [600x2 double]
cfg: [1x1 struct]
Now I run into several inconsistencies/confusions:
1) ft_spiketriggeredspectrum with cfg.method 'mtmconvol' outputs fourier, which is different from what you would expect with ft_frequencyanalysis. I would expect a cfg.method = 'fourier' to output fourier, and 'mtmconvol' to output power.
2) I was expecting an output that I could plot - with averaging in the plotting according to cfg. However, as is done in the tutorial, this requires the use of ft_spiketriggeredspectrum_stat first.
More consistent would be a (default) behavious where ft_spiketriggeredspectrum outputs a spectrum that is averaged over spikes, with an option cfg.keepspikes = true, to keep trials for later statistics when needed. Does that make sense?
3) ft_spiketriggeredspectrum_stat is only able to do ppc's. I'm not complaining. It would be more consistent if it would also be able to output just the mean power over spikes, thereby also dealing somewhat with point 2.
4) IMHO, function names could be more consistently named with the rest of the functions. E.g.:
ft_spiketriggeredspectrum --> ft_spikefreq (or ft_spiketriggeredfreq)
ft_spiketriggeredspectrum_stat --> ft_spikefreqstatistics (or ft_spiketriggeredfreqstatistics)