Back to the main page.
Bug 1746 - grid.leadfield (and filter) should be accompanied by a label field
| Status | CLOSED FIXED |
| 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 |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 227026393078 |
| See also: |
Johanna - 2012-09-26 17:15:23 +0200
In ft_sourceanalysis, first cfg.channel 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 cfg.channel=99 channels. This currently would be classed as user-error and that they should recompute grid.leadfield/filter to match the data and cfg.channel 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: Forward.cfg.channel, 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 cfg.channel = '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 cfg.channel ~= '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 github.com/schoffelen/fieldtrip 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.