Back to the main page.
Bug 3154 - Elekta MEG channel selection broken
| Status | REOPENED |
| Reported | 2016-06-26 01:49:00 +0200 |
| Modified | 2016-07-22 12:11:59 +0200 |
| Product: | FieldTrip |
| Component: | fileio |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Linux |
| Importance: | P1 blocker |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Sarang Dalal - 2016-06-26 01:49:04 +0200
Something changed within the past week that breaks channel selection for Elekta data, so that basic calls like the following yield no channels at all: cfg.dataset = 'meg.fif' cfg.channel = {'MEG'}; data = ft_preprocessing(cfg); If no cfg.channel is specified, all channels load as expected. However ft_chantype reports 'unknown' for all channels (with the exception that 'eog' is correctly recognized), so I suppose this is why channel selection fails. Maybe this was introduced by recent changes in ft_datatype_sens?
Sarang Dalal - 2016-06-26 16:00:50 +0200
Also ft_sourceanalysis doesn't work anymore, even when indexing the channels manually by number. It does not produce an error, but a result full of zeros.
Robert Oostenveld - 2016-06-27 08:57:39 +0200
is this for native elekta data, or after ICA cleaning and backprojecting? Can you give a small example dataset (or script on basis of elekta data we have on the ftp)?
Sarang Dalal - 2016-06-27 09:32:53 +0200
This is for native/continuous data (no max filter etc). I don't have a small dataset on hand since I'm at HBM, and the data I see on your FTP is already imported into mat files. But I believe the code I wrote above would fail with any elekta data imported from the raw FIF file. However with the data called 'subjectK.mat': load subjectK ft_chantype(data_left) Returns mostly channel type 'unknown'
Robert Oostenveld - 2016-06-27 09:33:45 +0200
(In reply to Sarang Dalal from comment #3) I will have a look...
Robert Oostenveld - 2016-06-28 08:47:57 +0200
(In reply to Robert Oostenveld from comment #4) I used "git bisect" to identify the commit. It is related to the work of last week. 882dba3426db583f7f4f9ac0cdf4eb3c26aaefc1 is the first bad commit commit 882dba3426db583f7f4f9ac0cdf4eb3c26aaefc1 Author: Robert Oostenveld <r.oostenveld@gmail.com> Date: Wed Jun 22 12:47:47 2016 +0200 ENH - improve combined planar MEG sensor handling, see http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3144 :040000 040000 55dede70567039600fcf39be5c076aea065dd57c 5e53f62a05db15a1caf469083e00506388ea58d3 M fileio :040000 040000 dd359f1b96820d71e7da86c04c4d7f928dd7af4e 369c5f2869fafc378ee789e236ec78b1d43831b9 M forward :100644 100644 d0288875565b1c6246502fe453430db15a08c8aa 723c57a0c2b73bae7899c6342293012fe4012741 M ft_combineplanar.m :040000 040000 76f08c9ae39f63bef191b7518675143f27971dd7 9c38f4f9830f03042c649ff809cb21c662128804 M inverse :040000 040000 969c8fa4126ebe5482de522fa201267149c10f0d b443792f5ef9fac8e779de826b8332380fe8b46d M plotting :040000 040000 c1f2959a8491d097cc093f8face8ac42c112b1b6 85077bcaeb21ed099d7954234b5870e0be314bdf M test :040000 040000 ccf9e21768ef91ee555bb8b3df0ec6452f806b35 0be55c1178b5d0d40d2fcc3a5ba892f0d7f04f91 M utilities
Robert Oostenveld - 2016-06-28 08:52:34 +0200
the error is due to the senstype being detected as neuromag306_combined, whereas it is simply 306 raw channels.
Robert Oostenveld - 2016-06-28 15:46:59 +0200
mac011> git commit -a [bug3154 ab9cc10] FIX - resolved incorrect detection of senstype (neuromag306_combined instead of neuromag306), causing channel selection to fail. See http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3154 8 files changed, 363 insertions(+), 214 deletions(-) create mode 100644 test/test_bug3154.m this resolves it: https://github.com/fieldtrip/fieldtrip/pull/185 In the process, I also made ft_chanunit more consistent with ft_chantype. There is now a test script that goes though the actions that I used to identify and fix all underlying issues.
Robert Oostenveld - 2016-06-29 08:44:57 +0200
*** Bug 3155 has been marked as a duplicate of this bug. ***
Sarang Dalal - 2016-07-15 17:00:48 +0200
Even after this fix, cfg.channel input like 'MEG', 'MEGMAG', or 'MEGGRAD' into ft_sourceanalysis fails because no channels are found. (Again with Elekta, perhaps other systems are affected as well?) I traced this down to line 657 in ft_selectdata.m: selchannel = ft_channelselection(cfg.channel, varargin{k}.label); This will output an empty matrix for Elekta channel labels. Providing the senstype could fix this: selchannel = ft_channelselection(cfg.channel,varargin{k}.label,varargin{k}.grad.type); However, I don't know of a general solution that does not break other datatypes; e.g., EEG data would not have a grad substructure. Any suggestions?
Stephen Whitmarsh - 2016-07-20 13:44:54 +0200
Hi Sarang! I have the same problem. I located the problem in ft_senstype, line 357-364 where input channel labels are compared with hardcoded lists of neuromag channel labels. One is in lowercase, the other in uppercase. I was trying to reproduce and fix it, but I am trapped by persistent variables in ft_senstype and ft_channelselection... arg... and have to run off now. Anyway, I uploaded some test data as well. Best, Stephen
Stephen Whitmarsh - 2016-07-20 13:49:34 +0200
Created attachment 800 small datastruct with neuromag gradiometers
Stephen Whitmarsh - 2016-07-20 15:22:50 +0200
It is getting very strange now: ft_channelselection works on the uploaded data, when using 'MEG', 'MEGGRAD', and 'all'. However, when I tried to test it on combined gradiometers, ft_combineplanar seems to output the wrong names for the combined gradiometers, namely the magnetometer names (which are therefor duplicates in the .label field).
Stephen Whitmarsh - 2016-07-20 16:19:10 +0200
Okay, so the lower-case thing makes sense because ft_senstype calls itself with lower(inputchannels) in the case the sensor type is unknown. The problem therefor lies upstream to that point (not recognizing the sensory type).
Stephen Whitmarsh - 2016-07-20 16:27:27 +0200
The problem is when ft_senstype has to determine the sensor type on the basis of the channel labels (ft_senstype(data_cue.label)), rather than the datastruct (ft_senstype(data_cue)), which works.
Stephen Whitmarsh - 2016-07-20 16:45:48 +0200
Okay - so here is the problem for real: Line 356, etc., in ft_senstype reads: % there are two possibilities for the neuromag channel labels: with and without a space, hence the 0.4 elseif all(mean(ismember(ft_senslabel('neuromag306_combined'), sens.label)) > 0.4) type = 'neuromag306_combined'; elseif all(mean(ismember(ft_senslabel('neuromag306'), sens.label)) > 0.4) type = 'neuromag306'; Now, for Neuromag data ft_senslabel gives 2 (combined) or 3 (original) columns of labels for each channel, e.g. MEG0112, MEG0113, MEG0111 for the original, and MEG0111, MEG0112+MEG0113 for the combined. Now, by using "any" in the above code, it will fail to recognize it as neuromag when you input either only combined, or only gradiometers, which is often the case. I suggest the following solution: 1) make the case neuromagXXX_combined depend only on the combined labels from ft_senslabel, i.e. the second column. Only these are unique. 2*) use ANY instead of ALL, and keep this order of cases (both the original and the combined condition will be a hit). Actually 2 is the only feasible one, since this would also allow one to input only magnetometers. Cheers, Stephen
Stephen Whitmarsh - 2016-07-20 16:56:12 +0200
See bug 3164 for the new ft_combineplanar bug I mentioned: http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3164