Back to the main page.
Bug 2081 - ft_combineplanar with combinemethod='svd' should be improved for raw/timelock
| Status | CLOSED WONTFIX |
| Reported | 2013-03-26 17:49:00 +0100 |
| Modified | 2014-01-29 13:28:45 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | Eelke Spaak |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Eelke Spaak - 2013-03-26 17:49:17 +0100
I have been playing around with using svd to combine planar gradients. I found that ft_combineplanar with combinemethod='svd' does not give very satisfying results, at least on timelock or raw data (have not tried the freq case). Attached are plots of three timelock topographies + timecourses: axial gradient, planar gradient combined with a custom piece of code, and planar gradient with combinemethod=svd. The latter looks very similar to combinemethod=sum, actually. This is the code I wrote: ------ % get the horizontally and vertically oriented channels horz = ft_channelselection({'*_dH'}, tl_plan.label); vert = ft_channelselection({'*_dV'}, tl_plan.label); if numel(horz) ~= numel(vert) error('unequal number of horizontal and vertical channels'); end % ensure that they are sorted identically indsH = strfind(horz, '_dH'); indsV = strfind(vert, '_dV'); for k = 1:numel(horz) if ~strcmp(horz{k}(1:indsH{k}-1), vert{k}(1:indsV{k}-1)) error('not all channel labels match up for horizontal and vertical'); end end % get channel indices horzChans = match_str(tl_plan.label, horz); vertChans = match_str(tl_plan.label, vert); % pre-initialize planar data datplan = zeros(numel(horzChans), numel(tl_plan.time)); % loop over channels and pick strongest orientation for k = 1:numel(horzChans) % create 2xN matrix of orientation X time dat = [tl_plan.avg(horzChans(k),:); tl_plan.avg(vertChans(k),:)]; u = svd(dat); datplan(k,:) = u(:,1)' * dat; end ------ Some questions (mainly @JM, since I think he implemented the svd combinemethod?). 1. Is my method any good? 2. Why does it look so different from the current implementation? 3. Why would the power be so strongly reduced (order of 10^-25 compared to 10^-14 for axial or other combine method)? and: should I go ahead and add this method to ft_combineplanar, replacing the existing piece of code that's now there (lines 215-238)?
Eelke Spaak - 2013-03-26 17:51:21 +0100
Created attachment 444 the mentioned plot
Eelke Spaak - 2013-03-27 13:24:50 +0100
conclusion at ft meeting: the svd results could be flipped. Given this, the solution is non-trivial, therefore keep this snippet in custom code and do not commit.