Back to the main page.
Bug 2979 - sLORETA
| Status | ASSIGNED |
| Reported | 2015-10-05 23:09:00 +0200 |
| Modified | 2016-10-20 17:20:49 +0200 |
| Product: | FieldTrip |
| Component: | inverse |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Linux |
| Importance: | P5 normal |
| Assigned to: | Sarang Dalal |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
John Richards - 2015-10-05 23:09:54 +0200
I suggest adding sLORETA, dSPM, and swLORETA as routines to FT. I note that in the SPM/DAiSS nutmeg modules they have low level calls for this. Perhaps this could be added as an external system to FT and integrated into the ft_sourceanalysis module; or a specific sLORETA/swLORETA/dSPM could be made. I include my recent question to the discussion and replies by Jan-Mathijs and Vladimir Litvak. Message: 1 Date: Sun, 4 Oct 2015 20:55:35 +0100 From: Vladimir Litvak <litvak.vladimir@gmail.com> To: FieldTrip discussion list <fieldtrip@science.ru.nl> Cc: FieldTrip discussion list <fieldtrip@science.ru.nl> Subject: Re: [FieldTrip] sLORETA Message-ID: <97E4469F-24B5-4C9C-9936-8E7253C41285@gmail.com> Content-Type: text/plain; charset="cp1251" Dear all, There are self contained low level functions for sLORETA and dSPM in NutMEG. I recently used them to add this functionality to my DAiSS toolbox (https://github.com/SPM/DAiSS, look in /private). Best, Vladimir On 4 Oct 2015, at 09:29, "Schoffelen, J.M. (Jan Mathijs)" <jan.schoffelen@donders.ru.nl> wrote: Hi John, I have found several sLORETA inquires on the FT discussion list, including one of my own. http://mailman.science.ru.nl/pipermail/fieldtrip/2015-January/008794.html I am using MNE and eLORETA in the source analysis routines, but wanted to see if I could get a sLORETA type algorithm. My understanding is that the sLORETA is the STD of the MNE estimate times the MNE estimate (e.g., J * STD-inverse * J in http://www.uzh.ch/keyinst/NewLORETA/sLORETA/sLORETA.htm). I have used the EMSE and CURRY sLORETA algorithms with the same data in am using in FT, and like some of those results vis-a-vis MNE and eLORETA from FT. Would there be some straightfoward way to calculate the STD of the MNE estimate, then use this with the MNE estimate in FT to get the sLORETA solution? The answer to both of these subquestions would be ?yes? :o). Is there anyone interested in working with me on this? I understand the concepts in http://www.uzh.ch/keyinst/NewLORETA/sLORETA/sLORETA.htm, but don?t know how these would be implemented in FT. I have a lot of data set up in FT format that could be used to test this. That sounds like a great plan. I?d suggest to file this as a feature request on bugzilla.fieldtriptoolbox.org, so that we can take it from there. From our end, we can then incorporate your suggested adjustments to the code. One thing you could look into, is the way in which sLORETA (and while you?re at it :o) dSPM) is computed in Brainstorm, which is also open source and matlab-based. Best, Jan-Mathijs Thanks, John *********************************************** John E. Richards Carolina Distinguished Professor Department of Psychology University of South Carolina Columbia, SC 29208 Dept Phone: 803 777 2079 Fax: 803 777 9558 Email: richards-john@sc.edu HTTP: jerlab.psych.sc.edu *********************************************** _______________________________________________
Jan-Mathijs Schoffelen - 2015-10-06 07:43:47 +0200
It has always been my understanding that sLORETA and dSPM are just post-processed MNE-maps. My suggestion therefore would be (if my 'always' understanding is correct) to incorporate this functionality in FieldTrip's minimumnormestimate function.
John Richards - 2015-10-06 10:38:57 +0200
Following Vladimir's suggestion, I used the NUTMEG nut_sLORETA, nut_swLORETA, and nut_dSPM. I have pretty simple inverse source models (e.g., not beam former..., but grand avg ERP). I used something like the following. 1--Convert the FT LF to NM Lp. I used the NUTMEG nut_ftgrid2nutsLpvox, but i had to modify it. The FT LF has lf{sources} and each struct is [nchannels 3]. The NM Lp is a matrix of [nchannels 3 sources] 2--I did the call to one of the subroutines e.g., cfg=[]; cfg.gamma=1e-5; nmfilter=nut_sLORETA(Lp,data_cov,cfg) 3--the output is a [nchannel 3 sources] matrix. I used this, and the data.avg, to create the FT source output (e.g., each source.avg.mom{sources} = inverse[nchannels p]' * data.avg; I added the source.avg.pow, and outsource.time=[1:size(outsource.avg.pow,2)]; outsource.inside=grid.inside; outsource.avg.inside=grid.inside; outsource.pos=grid.pos; outsource.avg.pos=grid.pos; outsource.method='average'; %dim is no of unique values in pos outsource.dim=[size(unique(grid.pos(:,1)),1) size(unique(grid.pos(:,2)),1) size(unique(grid.pos(:,3)),1)]; So i think this is solved for myself with the NUTMEG primitive calls. However, it would be nice if this could be included as an option in the ft_sourceanalysis call. John
Sarang Dalal - 2015-10-06 16:38:19 +0200
Hi everyone, I'm flattered that people are finding the Nutmeg implementations useful. :-) Just a word of caution on nut_swLORETA -- I was never able to get satisfactory results from it. Some years ago, I discussed with the 1st author of the paper whether there might be an error in one of the published formulas, and he seemed to agree, but never followed up with a correction. Apart from that, note that eLORETA is implemented as a native fieldtrip function. Finally, the standard Nutmeg/Fieldtrip workflow instead defines a grid over the whole brain space. However, the groups that primarily use these techniques these days prefer to restrict the solution space to the cortical layer, which substantially improves the reconstruction quality of any minimum-norm-based technique. (This would not improve the quality of beamformer reconstructions.) @Jan-Mathijs, has any progress been made towards making a more "plug-in" type of functionality for new source reconstruction algorithms? That would really ease integration of any desired source reconstruction technique into standard FieldTrip workflows. Cheers, Sarang
Sarang Dalal - 2016-03-25 15:42:33 +0100
An update: I've developed a new sLORETA function that follows the structure of FieldTrip's beamformer_lcmv.m One tangible improvement over my previous implementation in Nutmeg is that the optimal source orientation can be chosen, rather than having vector output. This effectively increases the performance (SNR) of the source reconstruction. For the moment, I haven't contributed it to the git repository since perhaps we should agree on some file naming first. I hesitate to simply call it sloreta.m since I can imagine conflicts with other toolboxes, and would rather call it ft_sloreta.m . But then this wouldn't be consistent with the naming of the other methods implemented in fieldtrip.
Robert Oostenveld - 2016-03-26 18:31:56 +0100
(In reply to Sarang Dalal from comment #4) Hi Sarang, we have internally been discussing name changes and refactoring of the functions fieldtrip/inverse directory. See e.g. bug #208. So prefixing with FT is fine. We actually want to make more changes (move the lead field computation from inside to outside the function, i.e. such that you would pass a cell array of lead fields and that the verse function loops over them), but that involves changes in the low-level and the ft_sourceanalysis function that we have not managed to find time for. Now that we have git, it would be easier to make a branch and to implement the changes (which take some time and should be tested/reviewed before committing to master). The whole bookkeeping of ft_sourceanalysis needs to be revised (it is one of the first functions in the toolbox and a lot has changed since). Also for combined eeg+meg and meg planar+grads it needs to be revised (see bug #3089). So perhaps now is a good time to start working on this and to share a branch.
Sarang Dalal - 2016-10-20 11:33:35 +0200
critical bug: the Gram matrix in this initial version was improperly computed voxel-by-voxel. I am submitting a pull request with the fix.
Sarang Dalal - 2016-10-20 12:25:27 +0200
(In reply to Sarang Dalal from comment #6) before submitting the pull request, I am doing some additional testing to make sure the orientation selection still makes sense. stay tuned. :-)