Back to the main page.

Bug 199 - ft_sourceanalysis with lcmv and precomputed filters and single trial input does not output a pow-field

Status CLOSED WONTFIX
Reported 2010-11-01 15:19:00 +0100
Modified 2011-07-13 14:46:51 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P1 normal
Assigned to: Jan-Mathijs Schoffelen
URL:
Tags:
Depends on:
Blocks:
See also:

Jan-Mathijs Schoffelen - 2010-11-01 15:19:23 +0100

this is explicitly removed in line 809. efficient computation is not easy in this context (because it requires single voxel/single trial sandwiching as opposed to leftmultyplying the reshaped tlck.trial) and may be confusing/wrong, because the cov (from which originally the pow was derived) can be defined in a different time-window as the mom.


Jan-Mathijs Schoffelen - 2010-11-02 09:32:22 +0100

Created attachment 10 matlab script to test recovered functionalitye


Jan-Mathijs Schoffelen - 2010-11-02 09:34:05 +0100

Created attachment 11 patched version of ft_sourceanalysis Kaoru could you please test this version of sourceanalysis? If it works OK for you then I could add it to the release version of FieldTrip. It would be useful to compare the results from the old implementation you used before, and this version. Could you let me know your findings? Thanks


Jan-Mathijs Schoffelen - 2010-11-02 09:35:03 +0100

The first attachment to this bug just contains a script to test the functionality. You can also use your own data for this. On the other hand, the test data is rather small, so computations are fast.


Johanna - 2010-12-24 13:45:53 +0100

I was going to create a new bug on this, but then Jan-Mathijs drew my attention to this bug. I have created 'hack work-arounds' to these questions already in my own copy. I don't know how/if this might affect code outside of ft_sourceanalysis, ft_timelockanalysis, and beamformer_lcmv. 1) If 'filter' is precomputed and included as grid.filter, should any assumptions be made on data format, cfg options, or desired output? Currently, the output tmpdip from beamformer_lcmv has a 'pow' subfield (computed from filt*Cy*filt') which is always removed within ft_sourceanalysis if 'filter' included. (I had hacked this in my own copy by creating a cfg.keeppow to prevent this). In response to this bug 199, Jan-Mathijs added that dip.pow is now computed again (outside of beamformer_lcmv) from tmpdip.mom*tmpdip.mom' (with the assumption that tmpdip.mom is from multi-trial data). However, if data input is not multi-trial, then dip.pow will be based on the 'covariance of the average', not the 'average of the covariances', leading to a very different result for dip.pow (than what is initially computed in beamformer_lcmv). There also is an interaction with cfg.rawtrials. If cfg.rawtrials=yes, then Nrepetitions=Ntrials and Jan-Mathijs's addition saves computation by not looping over Nreps to compute time-series pow in calling beamformer_lcmv, but rather permutes/reshapes afterwards. However, if cfg.rawtrials=no then Nrepetitions=1, and at best this is duplicating computation (with multitrials included) and at worst creating a different output (with only avg included). For clarity, dip.pow should probably only be computed in one place. It might be useful to allow the option to input (only?) a data.cov that is the average of covariances of single trials, with 'keeptrials=no' from ft_timelockanalysis (partly to save memory), in combination with having the option of cfg.lcmv.keepmom=yes or no. (Perhaps ft_timelockanalysis could include a cfg.keepavg='no', which then when that data is passed to ft_sourceanalysis, beamformer_lcmv could handle an empty or missing 'dat' input, as long as Cy is input.) 2) Jan-Mathijs wondered more generally: should beamformer_* (and other inverse methods) be used solely for computing the filter, and then the application of this filter to the data occur within ft_sourceanalysis only? 3) Jan-Mathijs asked me specifically: if all I want is dip.pow, why not just use inv(lf*InvCy*lf) outside of calling ft_sourceanalysis? I'll create a new bug for this, regardling baseline input.


Jan-Mathijs Schoffelen - 2011-06-21 08:25:20 +0200

I will wait until we settled on the new definition of source structures before fixing any source related bug


Robert Oostenveld - 2011-07-13 14:46:51 +0200

changed the status for a whole bunch of resolved bugs to CLOSED