Back to the main page.

Bug 3067 - beamformer_sam with precomputed leadfields and filters

Status NEW
Reported 2016-02-08 13:07:00 +0100
Modified 2016-03-01 17:57:25 +0100
Product: FieldTrip
Component: inverse
Version: unspecified
Hardware: Other
Operating System: Linux
Importance: P5 normal
Assigned to: Lorenzo Magazzini
Depends on:
See also:

Lorenzo Magazzini - 2016-02-08 13:07:30 +0100

Created attachment 774 test script to load variables and replicate result Dear Fieldtrip Developers, I have recently been using the 'sam' beamformer in fieldtrip (20160116), and I am a bit puzzled by the results. I wonder if you could please help me figure out if I'm doing something wrong, or if there's a problem with the current implementation of SAM. Firstly, I should say that sam used to throw an error when using precomputed leadfields. My colleague Philipp Ruhnau helped looked into this for me, and he quickly identified the problem in line 90 of beamformer_sam. So this first bug would seem to be fixable by changing line 90, ...from: dip.leadfield = dip.leadfield(dip.inside); dip.leadfield = dip.leadfield(originside); Secondly, this made me wonder if the same indexing problem wouldn't apply to the precomputed filters, line 94, i.e. dip.filter = dip.filter(originside). However, I am unable to identify the part of the code that makes use of the precomputed filters. I may well miss something here, but it would appear to me that the dip.filter variable is unused, and that the weights are always re-calculated for the optimal source orientation (lines 230-232). I wonder if this could explain the odd results I got when running sam on a number of subjects from a visual gamma paradigm. I would almost always observe the expected blob in the occipital lobe, but only after re-scaling, as the source power values would often be dominated by a few voxels in random locations, most frequently at the centre of the head (see this figure for an example: I attach a short piece of code to replicate the problem, and a link to the test data ( Apologies if this is simply due to a mistake on my side. Best wishes, Lorenzo Magazzini

Lorenzo Magazzini - 2016-02-17 13:39:36 +0100

Dear developers, Is there any chance that you could spare some time to look into this? Please let me know if I should provide more information/scripts/data to facilitate the process. Many thanks, Lorenzo

Jan-Mathijs Schoffelen - 2016-03-01 17:57:25 +0100

guys, sorry for our unresponsiveness of late, but we are extremely short-handed. if you want to push this forward at short notice, I suggest that you make the code changes yourself in a local branch of your own git-fork. See: After sufficient testing on your end, you can submit a pull request, we will evaluate the suggested changes to the code, and approve it if applicable.