Back to the main page.

Bug 1746 - grid.leadfield (and filter) should be accompanied by a label field

Reported 2012-09-26 17:15:00 +0200
Modified 2016-05-09 09:00:15 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P3 normal
Assigned to: Jan-Mathijs Schoffelen
Depends on:
Blocks: 227026393078
See also:

Johanna - 2012-09-26 17:15:23 +0200

In ft_sourceanalysis, first and sens.label and data.label are matched in prepare_headmodel.m. Then this updated list is compared again with data.label to extract required channels for computing Cf in prepare_freq_matrices. But in the final call to beamformer_XXX, if grid.filter or grid.leadfield was supplied by the user, it is assumed that the order (and size) of filter or leadfield matches the final order (and size) of channels made by the output (Cf) of prepare_freq_matrices. One example of it failing is calling cfg.grid.leadfield=size 100 channels, but then ft_sourceanalsys channels. This currently would be classed as user-error and that they should recompute grid.leadfield/filter to match the data and request.

Jan-Mathijs Schoffelen - 2012-09-27 08:45:41 +0200

This is a recurring discussion. I have argued in favour of this. So far, Robert opposed. Perhaps if we gain a critical mass it will finally change for the better. Perhaps a bug on the same topic already exists somewhere...

Robert Oostenveld - 2014-04-22 15:31:39 +0200

(In reply to Jan-Mathijs Schoffelen from comment #1) with the new source structure I agree that we should add source.label as Nx1 cell-array in case source.leadfield or source.filter is present. The ft_selectdata can make use of it (using getdimord) and make subselections in the channel dimension for the appropriate fields

Jan-Mathijs Schoffelen - 2014-09-04 10:40:46 +0200

OK, let's get this over with. In order to be very explicit about the order of the channels in leadfields and filter, I will build in a label field as output to ft_prepare_leadfield. In the high-level inverse modelling functions: ft_sourceanalysis and ft_dipolefitting, an explicit check then can be performed to match the order of the channels in the leadfield with the order of the channels in the data.

Marc Lalancette - 2014-10-27 20:33:09 +0100

I also ran into this today. Creating a lead field with mostly defaults (from CTF MEG data), keeps reference channels as well as MEG sensors (184): ... cfg.grad = ft_read_sens(Dataset, 'fileformat', 'ctf_ds'); Forward = ft_prepare_leadfield(cfg); Then I prepare the data covariance and average on sensors only (151): ... cfg.covariance = 'yes'; Evoked = ft_timelockanalysis(cfg, data); But then ft_sourceanalysis -> beamformer_lcmv doesn't match channels and tries to use the 184-channel lead field and 151-channel covariance matrix to compute weights resulting in an error. ... cfg.method = 'lcmv'; cfg.grid = Forward; cfg.grad = Forward.cfg.grad; cfg.vol = Forward.cfg.vol; % ... Further tweak vol to avoid errors and unnecessary re-computations. Inverse = ft_sourceanalysis(cfg, Evoked); Has worked started on this? I found channel names for the lead field in the structure:, so I'd be happy to write something to match channels in ft_sourceanalysis, but being new to the code I'm assuming there is a channel matching function somewhere already I should be using?

Jan-Mathijs Schoffelen - 2014-10-27 20:41:27 +0100

Hi Marc, This is still on the to-do list. If you intend not to do any funky stuff that for example involves higher order gradient balancing (either with fixed or adaptive weights), or project-out any spatial topographies (e.g. with ICA, followed by a backprojection of the components with the artifactual components removed), pre-computation of the leadfields can usually be safely done assuming a fixed order in the channels, and by specifying = 'MEG' in the cfg to ft_prepare_leadfield. This should result in a 151x3 leadfield matrix per location in your case, provided none of the gradiometers has been switched off upon acquisition.

Jan-Mathijs Schoffelen - 2014-11-12 20:56:26 +0100

Started working on this. I added (still to be committed) a label to the output of ft_prpare_leadfield and ensured that this information is passed on in ft_prepare_sourcemodel. I have started working on ft_sourceanalysis, but will first make a test script before committing.

Johanna - 2015-02-19 14:49:15 +0100

Hi Jan-Mathijs, I've just run into this issue again. I've noticed my precomputed lf has a .label field. Great! I've noticed however that in line 357 of ft_prepare_sourcemodel a bunch of subfields are kept, but 'label' is not explicitly mentioned. May I add it? (and commit the change?) Just asking as I don't want to interfere with ongoing changes you're making. Cheers, JZ p.s. unfortunately ft_sourceanalysis still doesn't know what to do with the ordering. (comment 10 of bug 2639)

Jan-Mathijs Schoffelen - 2015-02-19 15:23:16 +0100

(In reply to Johanna from comment #7) Yes, please feel free to add it to be kept. @changes in ft_sourceanalysis: indeed there's no functionality in place (in the release version) that does explicit checking. Reason: it proved more complicated than anticipated :-). In particular with respect to where the appropriate checks need to be done and with respect to backward compatibility, and which data has priority (data or leadfields). To lift a tip of the veil, the checks need to accommodate the following scenarios: -precomputed leadfields with nchan > nchan in data -> (will become fishy in EEG, and probably requires explicit re-averagereferencing for leadfields) -precomputed leadfields with nchan < nchan in data -> here it should anticipate the possibility of dics with refchan, where the channels in the leadfields should not determine solely the subsection of channels from the data. -precomputed leadfields, but ~= 'all' and possibly some other exotic combinations...

Johanna - 2015-02-19 15:36:15 +0100

zumerj@psychl-132432-1:~/home/fieldtrip_svn$ svn commit ft_prepare_sourcemodel.m Sending ft_prepare_sourcemodel.m Transmitting file data . Committed revision 10241. Eek, you're right it's complicated. I've made a small fix/hack in my own code. But I suggest an informative error message for now, rather than running through and allowing the user to think they have a good filter computed. (I'll comment more in bug 2639).

Jan-Mathijs Schoffelen - 2016-03-04 11:46:00 +0100

(In reply to Jan-Mathijs Schoffelen from comment #8) I have now included some code in my own branch bug3078 on that outputs a label, and does some checking of channel order/count. I moved the check to a different location in the code (closer to where it's actually passed to the lower-level inverse routine), so I guess that any issues with respect to refchans etc are not an issue anymore. I suppose we just have to deal with possible balancing/reref issues and leave that to the user. Note that before we could also pass balanced/unbalanced leadfields to unbalanced/balanced data

Jan-Mathijs Schoffelen - 2016-05-05 09:59:04 +0200

resolved for now.

Robert Oostenveld - 2016-05-09 09:00:15 +0200

Adding label to the source model may result in the source structure having 'label' and 'time'. This caused ft_datatype to incorrectly detect it as timelock (reported by Giorgos). A few days back I therefore fixed this in Please be advices that other cases like this may happen due to data structures getting more complex.