Back to the main page.

Bug 1658 - ft_sourcedescriptives should have the option cfg.trials

Status CLOSED FIXED
Reported 2012-08-16 14:01:00 +0200
Modified 2017-03-14 12:49:39 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P3 normal
Assigned to: Jan-Mathijs Schoffelen
URL:
Tags:
Depends on:
Blocks:
See also:

Robert Oostenveld - 2012-08-16 14:01:15 +0200

ft_sourcedescriptives is used often for averaging of common-filter beamed data with rawtrials=yes. At this moment the users have to manually split the source reconstruction into separate conditions. It makes sense to allow averaging over trials that belong to a specific condition. e.g. the following is a piece of code from Irina (CC) ======================================================= % project all trials through common spatial filter % cfg=[]; cfg.method = 'dics'; cfg.grid = grid; % previously computed grid cfg.vol = vol; % previously computed volume conduction model cfg.grid.filter = source.avg.filter; % use the common filter computed in the previous step! cfg.frequency = opt.foi; cfg.rawtrial = 'yes'; % project each single trial through the filter cfg.grad = dataC1.grad; % this field has been lost when the data were appended source = ft_sourceanalysis(cfg, freq); % contains the source estimates for all trials/both conditions % average over tapers, keep single trials % %% Calculate average for each condition % C1 = find(design==1); % find trial numbers belonging to condition A C2 = find(design==2); % find trial numbers belonging to condition B sourceC1 = source; sourceC1.trial([C2 C3]) = []; sourceC1.cumtapcnt([C2 C3]) = []; sourceC1.df = length(C1); sourceC1 = ft_sourcedescriptives([], sourceC1); % compute average source reconstruction for condition C1 sourceC2=source; sourceC2.trial([C1 C3]) = []; sourceC2.cumtapcnt([C1 C3]) = []; sourceC2.df = length(C2); sourceC2 = ft_sourcedescriptives([], sourceC2); % compute average source reconstruction for condition C2 sourceC1vsC2 = sourceC1; sourceC1vsC2.avg.pow = (sourceC2.avg.pow-sourceC1.avg.pow)./sourceC1.avg.pow; ======================================================= rather than this, it should be possible to do cfg.trials = find(design==1); sourceC1 = ft_sourcedescriptives(cfg, source); cfg.trials = find(design==2); sourceC2 = ft_sourcedescriptives(cfg, source);


Jörn M. Horschig - 2012-08-21 13:15:00 +0200

this is a bit at odds with what we talked about some months ago, where the consensus was that no function should support cfg.trials, rather everything should be done via ft_selectdata (or similar) before calling any other function.


Diego Lozano Soldevilla - 2013-08-08 10:38:27 +0200

(In reply to comment #1) ft_sourcedescriptives still does not follow the logic of its relatives ft_freqdescriptives and ft_timelockanalysis regarding trial selection and averaging. The proper source trial average is nonintutite as Robert pointed out. I tried to use ft_selectdata_new before averaging but I got this error: K>> cfg=[]; cfg.trials=rptl; x=ft_selectdata_new(cfg,sourcecue) Undefined function or variable "dimord". Error in ft_selectdata_new (line 121) dimtok = tokenize(dimord, '_'); K>> sourcecue sourcecue = dim: [20 25 22] freq: 11.0906 cumtapcnt: [20x1 double] pos: [11000x3 double] inside: [1x5798 double] outside: [1x5202 double] method: 'rawtrial' trial: [1x20 struct] df: 20 trialinfo: [20x11 double] cfg: [1x1 struct] The variable sourecue comes from the common filters approach. Using ft_selectdata_old everything works fine: x=ft_selectdata_old(sourcecue,'rpt',rptl) selection pow along dimension 2 x = dim: [20 25 22] freq: 11.0906 cumtapcnt: [10x1 double] pos: [11000x3 double] inside: [1x5798 double] outside: [1x5202 double] df: 20 trialinfo: [10x11 double] cfg: [1x1 struct] pow: [11000x10 double] powdimord: 'pos_rpt' filter: {11000x1 cell} filterdimord: '{pos}_ori_chan' however the x output cannot be average using ft_sourcedescriptives: x.df=10; ft_sourcedescriptives([],x) the input is source data with 11000 positions on a [20 25 22] grid the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB ans = dim: [20 25 22] freq: 11.0906 cumtapcnt: [10x1 double] pos: [11000x3 double] inside: [1x5798 double] outside: [1x5202 double] df: 10 trialinfo: [10x11 double] cfg: [1x1 struct] pow: [11000x10 double]<-----------the 10 trials are still there powdimord: 'pos_rpt' filter: {11000x1 cell} filterdimord: '{pos}_ori_chan' method: [] As Jorn suggested, should we use ft_selectdata_old inside ft_sourcedescriptives and check why ft_selectdata_old's output cannot be average? Suggestions are welcome!


Jan-Mathijs Schoffelen - 2016-12-23 09:04:48 +0100

This one by now is a pretty stale one. The source level representation has changed (at least at a lot of place in the code, where a call to ft_datatype_source causes the .avg. / .trial. field to be squashed. This means that the proposed solution(s) in this bug don't apply anymore. In other words, we need to revisit whether 1) this is still an issue that exists in the current version of the code 2) if so, come up with a new plan to fix it. anyone?


Jan-Mathijs Schoffelen - 2017-01-17 12:17:42 +0100

Tested and fixed with PR 297. Note that this is still making use of the old-style data representation (with source.trial.pow etc), but a clean fix would require a re-implementation of ft_sourcedescriptives, which is an issue of a different scope altogether.