Back to the main page.
Bug 2468 - ft_sourcedescriptives can not handle output from beamformer_pcc with keeptrials='yes'
| Status | CLOSED FIXED |
| Reported | 2014-02-10 15:38:00 +0100 |
| Modified | 2014-03-06 15:36:18 +0100 |
| Product: | FieldTrip |
| Component: | inverse |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Linux |
| Importance: | P5 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | 2004 |
| Blocks: | |
| See also: |
Alexander Backus - 2014-02-10 15:38:06 +0100
Source data output from ft_sourceanalysis with method='pcc' and keeptrials='yes' is in format unsuitable for subsequent processing by ft_sourcedescriptives. The problem is that the single trial data for each source is represented inside the data.avg.mom field (nSources-by-1 cell array) where each cell has the dimensions nOrientations-by-nTrials. My suggestion would be to revise beamformer_pcc so that it does not output the data.avg field but rather a data.trial field as is done in the rawtrial='yes' case (however the latter results in unnecessary looping over trials and redundancy). data.method should also not be 'average' in this case. Attached sdata.mat was created with the following script: ----------------------------------------------------------------- % sourceanalysis with precomputed leadfield and spatial filters cfg = []; cfg.frequency = fdata.freq; cfg.grid = leadfieldModel; cfg.grid.filter = spatialFilters.avg.filter; cfg.vol = sourceVol; cfg.rawtrial = 'no'; % IMPORTANT TO PREVENT REDUNDANCY cfg.keeptrials = 'yes'; cfg.keepleadfield = 'no'; cfg.method = 'pcc'; cfg.(cfg.method).projectnoise = 'no'; cfg.(cfg.method).keepfilter = 'no'; cfg.(cfg.method).keepcsd = 'no'; cfg.(cfg.method).keepmom = 'yes'; sdata = ft_sourceanalysis(cfg, fdata); % sourcedescriptives to project along strongest orientation cfg = []; cfg.projectmom = 'yes'; cfg.keeptrials = 'yes'; cfg.fixedori = 'over_trials'; data = ft_sourcedescriptives(cfg,sdata); ----------------------------------------------------------------- Thanks for the effort. Best, Alexander Backus
Jan-Mathijs Schoffelen - 2014-02-10 15:40:09 +0100
Will look into it.
Alexander Backus - 2014-02-10 15:43:21 +0100
Created attachment 589 source data 'sdata'
Jan-Mathijs Schoffelen - 2014-02-11 11:14:14 +0100
Hi Alex, For this to be fixed in a generic way, I'd like to recompute the sdata variables. Could you also upload the variables fdata, leadfieldModel, spatialFilters and sourceVol? Thanks.
Alexander Backus - 2014-02-11 15:47:05 +0100
(In reply to Jan-Mathijs Schoffelen from comment #3) I've uploaded the requested files to /home/common/temporary/jansch/bug_2468 (fdata filesize is too big for bugzilla) If need be, spatialFilters can be recreated with the following code: ------------------------------------ cfdata = ft_checkdata(fdata,'cmbrepresentation','fullfast'); cfdata = ft_checkdata(cfdata,'cmbrepresentation','sparse'); cfdata = ft_checkdata(cfdata,'cmbrepresentation','sparsewithpow'); cfg = []; cfg.frequency = fdata.freq; cfg.vol = sourceVol; cfg.grid = leadfieldModel; cfg.keeptrials = 'no'; cfg.method = 'dics'; cfg.(cfg.method).keepfilter = 'yes'; cfg.(cfg.method).lambda = '5%'; cfg.(cfg.method).fixedori = 'no'; spatialFilters = ft_sourceanalysis(cfg, cfdata);
Jan-Mathijs Schoffelen - 2014-02-11 17:35:45 +0100
Hi Alex, It should work now, but you have to recompute the 'pcc' step. The output of ft_sourceanalysis is now such that each of the 'dipoles' gets its own csdlabel, which can vary in the number of components. bash-4.1$ svn commit test/test_bug2468.m ft_sourcedescriptives.m inverse/beamformer_pcc.m private/statistics_wrapper.m Sending ft_sourcedescriptives.m Sending inverse/beamformer_pcc.m Sending private/statistics_wrapper.m Adding test/test_bug2468.m Transmitting file data .... Committed revision 9193. Please verify if it now works and let me know.
Alexander Backus - 2014-02-12 10:03:20 +0100
(In reply to Jan-Mathijs Schoffelen from comment #5) Hi JM, ft_sourcedescriptives can indeed handle the pcc singe trial output now. However, the resulting format after calling sourcedescr with: -------------------------------------------------------------- cfg = []; cfg.projectmom = 'yes'; cfg.keeptrials = 'yes'; cfg.fixedori = 'over_trials'; data = ft_sourcedescriptives(cfg,sdata); -------------------------------------------------------------- ...is not suited for a function like ft_connectivityanalysis. Problem is related to: ------------------------------------- ft_datatype('data') ans = unknown ------------------------------------- Should I explore this further? I guess what we want is that ft_sourcedescriptives always outputs the same format, for everything that is input (e.g. different beamformers). For now, I circumvent this problem but forging a datatype 'freq' structure where I then put my source data in, but I guess this is not the optimal way of data handling... Best, Alex
Jan-Mathijs Schoffelen - 2014-02-12 10:35:41 +0100
Sorry, fooling around with dependencies between bugs, thought I knew the numbers by heart... Indeed I think it is part of this bug to correctly detect it to be a source structure in ft_datatype; question is whether this would solve the downstream problems. I'll look into it. For now good to hack it into a 'sensor'-based structure?
Jan-Mathijs Schoffelen - 2014-02-13 11:13:00 +0100
hmmm, if I do ft_datatype(data) I get 'source'. Are you sure you are using an up-to-date FT-version?