Back to the main page.
Bug 2016 - Choosing lambda in lcmv
| Status | CLOSED DUPLICATE |
| Reported | 2013-02-27 20:17:00 +0100 |
| Modified | 2019-08-10 12:28:13 +0200 |
| Product: | FieldTrip |
| Component: | inverse |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Linux |
| Importance: | P3 enhancement |
| Assigned to: | Diego Lozano Soldevilla |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=2717 |
Hamid - 2013-02-27 20:17:41 +0100
Choosing lambda in the lcmv beamformer is an important issue and can dramatically change the results. To show this, I used a simple auditory paradigm in which a trains of beeps were presented to the left ear of a participant. The system is neuromag306 and the data has been maxfiltered which reduces the rank of the data from 306 to 64. Please see the attached images for the results: Image lamPst5_lamPre5.jpg is for when the lambda for both pre and post-stimulus has been set to cfg.lambda = '5%'. The results are clearly wrong. Image lamPst5_lamPre1000.jpg is for when the lambda for pre- and post-stimulus has been set to '5%' and '1000%', respectively. The result shows some genuine activity. This means assuming noise is white Gaussian gives better results. Image lamPst5_lamPre1000.jpg is for when the lambda for pre- and post-stimulus has been set to '1000%' and '1000%', respectively. The result is the best in this situation. Based on this example and my experiment, I have some suggestions: -- It should be clearly stated in the documentation that the value of regularisation has big impact on the results. -- Instead of estimating the noise covariance from the pre-stim segment, it is better to assume that the noise is white Gaussian. Of course this does not always give the best results, but it surely gives more robust results. Therefore, this should be the default implementation of the code and general user should select this. -- last and least, there is no need to: sourceDiff.avg.pow = (sourcePost_con.avg.pow - sourcePre_con.avg.pow) ./ sourcePre_con.avg.pow; since it is equivalent to sourceDiff.avg.pow = sourcePost_con.avg.pow ./ sourcePre_con.avg.pow - 1; which is a biased version of the neural activity index.
Jan-Mathijs Schoffelen - 2013-02-28 07:43:05 +0100
-- Instead of estimating the noise covariance from the pre-stim segment, it is better to assume that the noise is white Gaussian. Of course this does not always give the best results, but it surely gives more robust results. Therefore, this should be the default implementation of the code and general user should select this. We disagree with this statement. Have a look at the beamforming tutorial. In general, it's up to the user to normalize either with spatially filtered white noise, or to 'normalize' with another condition, such as a pre stimulus baseline. -- last and least, there is no need to: sourceDiff.avg.pow = (sourcePost_con.avg.pow - sourcePre_con.avg.pow) ./ sourcePre_con.avg.pow; since it is equivalent to sourceDiff.avg.pow = sourcePost_con.avg.pow ./ sourcePre_con.avg.pow - 1; which is a biased version of the neural activity index. We are aware of this of course, but what is the problem?
Robert Oostenveld - 2013-02-28 12:36:04 +0100
-- It should be clearly stated in the documentation that the value of regularisation has big impact on the results. I searched on the wiki for regularization There is now http://fieldtrip.fcdonders.nl/tutorial/beamformer?s[]=regularization#exercise_6regularization it could be extended, e.g. with a faq "what is the effect of regularization?" that would explain how you can specify it (as string in percent, or as absolute number). It might also explain how to come up with the absolute nomber (although I suspect most people to use the percent version). And it could show a sequence of figures going from no (i.e. too little) to too much regularization. @Hamid, would you be willing to contribute such a faq page to the wiki? You can use your own figures in the demonstration.
Hamid - 2013-02-28 14:10:22 +0100
I general the code is very well written, but my point is we should make clear that regularisation and normalisation are important issues in source localisation, and the general user should be aware of these problems. Otherwise, if someone try to localise a big auditory ERF and don't see the results (e.g. with lambda = 1% and 5%), s/he may get disappointed. I would be happy to write a FAQ with results from different lambda.
Robert Oostenveld - 2013-02-28 17:26:43 +0100
(In reply to comment #3) Thanks for the input. We try to organize documentation at various levels: 1) there are comments in the code (not really accessible for most people) 2) there is help at the function start, this is the reference documentation. Should be complete and correct, does not allow for elaborating too much. 3) there is the wiki with a) the FAQs, can be short or long, pertain to one topic b) the example scripts, should be more substantial, should demonstrate c) the tutorials, should allow users to try it out themselves The tutorials are used for teaching (~6-8 workshops this year). The format should allow for a 2-hour hands-on session with exercises. So they cannot get too elaborate and cannot include "reference" details. They should point to further reading, elsewhere on the wiki and in papers. In this case it would fit well in the format of a faq, or the format of an example script. With the appropriate tags, they can be found. Some tutorials include auto-generated lists of related material, some have hand-crafted lists. In this case it would make sense to link to the new page that details regularization in the http://fieldtrip.fcdonders.nl/tutorial/beamformer#summary section. Keeping it in the exercise 6 means that people also discover it themselves (by trying out).
Jan-Mathijs Schoffelen - 2013-10-10 10:44:45 +0200
What's the status of the development of the FAQ mentioned?
Hamid - 2013-12-09 09:24:25 +0100
Hi, I am very sorry that I have changed my job and am not able to contribute any more. Best regards
Robert Oostenveld - 2014-10-02 19:22:51 +0200
let's continue this on the new bug 2717 *** This bug has been marked as a duplicate of bug 2717 ***