Back to the main page.
Bug 1368 - leadfield normalization fails for openmeeg forward solution
Status | CLOSED FIXED |
Reported | 2012-03-13 10:12:00 +0100 |
Modified | 2012-06-12 13:00:18 +0200 |
Product: | FieldTrip |
Component: | forward |
Version: | unspecified |
Hardware: | PC |
Operating System: | Mac OS |
Importance: | P3 minor |
Assigned to: | Cristiano Micheli |
URL: | |
Tags: | |
Depends on: | |
Blocks: | |
See also: |
Robert Oostenveld - 2012-03-13 10:12:40 +0100
In case of openmeeg the high-level ft_prepare_leadfield will try to compute all leadfields with one call to the low-level ft_compute_leadfield function. The problem is that ft_compute_leadfield then does not know how to separate the leadfields of the individual dipole positions and will scale the concatenated leadfield matrix by a single number.
Robert Oostenveld - 2012-03-13 10:15:25 +0100
I have added the following to ft_prepare_leadfield to prevent people from getting incorrect leadfields at the moment. + if ~strcmp(cfg.normalize, 'no') + % See http://bugzilla.fcdonders.nl/show_bug.cgi?id=1368 + % + % The problem is that ft_compute_leadfield does not know how to + % separate the leadfields of the individual dipole positions and will + % scale the concatenated leadfield matrix by a single number. + error('leadfield normalization is currently not supported in combination with the openmeeg forward solution'); + end manzana> svn commit ft_prepare_leadfield.m Sending ft_prepare_leadfield.m Transmitting file data . Committed revision 5445.
Cristiano Micheli - 2012-03-21 14:50:45 +0100
(In reply to comment #1) Now the ft_compute_leadfield is able to manage the normalization of both single dipole leadfields and batch ones. A test script has been added to check for this functionality both qualitatively (the routine does not crash) and quantitatively, i.e. the Frobenius norm is 1. ( see FT/test/test_bug1368.m) The check is run both on vectorial lf normalization and column-wise normalization (resp. cfg.normalize='yes' and cfg.normalize = 'column')