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 |
URL: | |
Tags: | |
Depends on: | |
Blocks: | |
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); ...to: 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: https://www.dropbox.com/s/lt6eq1eqoubtfbb/src_percentagechange.png?dl=0). I attach a short piece of code to replicate the problem, and a link to the test data (https://www.dropbox.com/sh/50acdksbm5iuno7/AADH2-0f0q6YSM2Fhp6Gxmhma?dl=0). 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