[FieldTrip] channel order changes after ft_channelrepair
f.roux at bcbl.eu
Tue Mar 10 15:37:02 CET 2015
thanks for the quick and very helpful reply.
My goal is indeed to keep the channel order consistent
across different participants.
After MF-preprocessing some of the channels are missing
in certain participants but this is not consistent so
I would like to interpolate the missing channels for
those participants for which the channels were turned off.
I am guessing that the fields that I need to adjust if
I want to manually re-order the info of the channels according
to the template are
Do you see anything else that would need to be adjusted ?
----- Original Message -----
From: "Jörn M. Horschig" <jorn at artinis.com>
To: "FieldTrip discussion list" <fieldtrip at science.ru.nl>
Sent: Tuesday, March 10, 2015 3:16:30 PM
Subject: Re: [FieldTrip] channel order changes after ft_channelrepair
back then when I implemented different options for channel interpolation, we decided that there is no "natural" order of channels in any sense. For MEG systems it might seem like that, because afaik there is a single acquisition software per system, which is always returning channels in the same order. However, this order is arbitrary and can be other rationales equally valid than the one used by the acquisition software.
For your specific case, I imagine that a sensor is broken and thus turned off: it will not be in the list of channels anymore. FieldTrip does not know where the 'natural' position of that channel is, as FT is not maintaining fixed channel lists. But this shouldn't be a problem anyhow, as channel labels can be easily matched. If I recall the latest developments correctly, by now all FieldTrip functions are taking care of the channel order - even when computing leadfields ;)
If you do not like this due to aesthetical reasons or because you want to have the channel order being consistent across subjects, you can simply reorder them manually. As said, FieldTrip does not care about the order. Just be sure that if you are reordering the label-field, you also need to reorder the channel dimension(s) of all data.
If you encounter any problems with this concatenation, feel free send out notification.
PS: if the channel is already in your data and you want to just repair it because it suffers from a lot of artifacts, you could try using cfg.badchannel instead of cfg.missingchannel. If I recall correctly, missing channels are always concatenated, bad channels are kept in order if already present. But it's been a while, so I am not sure and right now, too lazy to check the code ;)
Jörn M. Horschig, Software Engineer
Artinis Medical Systems | +31 481 350 980
> -----Original Message-----
> From: fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-
> bounces at science.ru.nl] On Behalf Of Frédéric Roux
> Sent: Tuesday, March 10, 2015 3:05 PM
> To: FieldTrip discussion list
> Subject: [FieldTrip] channel order changes after ft_channelrepair
> Dear all,
> I just noted that after calling ft_channelrepair the order of channel labels in
> my Neuromag 306 data has changed.
> The code I am using is as follows (fieldtrip-20150115):
> % get the labels from the reference layout cfg = ; cfg.layout =
> [ref_lay] = ft_prepare_layout(cfg);
> % eliminate COMNT and SCALE labels
> ref_lay.label = ref_lay.label(1:204);
> % get the labels of channels present in the data orig_label = meg_data.label;
> % compare labels from reference layout with original data idx =
> zeros(length(ref_lay.label),1); for it = 1:length(ref_lay.label)
> idx(it) = any(strcmp(ref_lay.label(it),orig_label));
> % load the template neighbourhood structure from fieldtrip
> cfg = ;
> cfg.neighbours = neighbours;
> cfg.missingchannel = find(idx==0);
> cfg.method = 'spline';
> [meg_data] = ft_channelrepair(cfg,meg_data);
> When I then look at meg_data.label I can see that the missing channels were
> added at the end of the channel label list instead of being integrated in the
> list at the position where they would be found in the channel list of the
> template layout.
> For instance
> meg_data.label(end) = 'MEG1133';
> ref_lay.label(end) = 'MEG2643';
> Does anyone know why this happens and how this can be avoided or
> compensated? I am guessing that later on in the analysis pipeline this can
> become problematic as the mapping between the new labels and the spatial
> coordinates does not correspond anymore.
> Any help or suggestions would be highly appreciated!
> Frédéric Roux
> Postdoctoral Scientist
> f.roux at bcbl.eu
> Tel: +34 943 309 300 Ext 211
> Fax: +34 943 309 052
> Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer
> fieldtrip mailing list
> fieldtrip at donders.ru.nl
fieldtrip mailing list
fieldtrip at donders.ru.nl
More information about the fieldtrip