[FieldTrip] Ordering of channels index in ft_read_data with egi_mff_v1

[Christian O'Reilly]

Hi,

I've been trying for a while to find the source of an apparent swapping of
channels in my data, and I suspect that the source of this issue comes from
the ft_read_data function when it is used with egi_mff_v1. This code does
not handle very well list of channel indexes that are not ordered. I am
using:

chanindx  = [36, 224, 37, 18, 21, 109, 153, 101];
data = ft_read_data([path fileNames(iFile).name], 'headerformat', ...
                        'egi_mff_v1', 'dataformat', 'egi_mff_v1', ...
                        'header', header, ...
                        ... #'begsample', begsample, 'endsample',
endsample, ...
                        'chanindx', chanindx);

... and I have a strong suspicion that the 8 columns of the data matrix are
ordered as if chanindx == [18, 21, 36, 37, 101, 109 153, 224]

I think it has to do with ft_read_data code:

    for iSig = 1:length(hdr.orig.signal)
      % adjust chanindx to match with current signal
      [dum1, dum2, chanind_sig] = intersect(chanindx,
find(chan2sig_ind==iSig));
      if isempty(chanind_sig)
        % no channels requested from current signal
      else
        blockhdr = hdr.orig.signal(iSig).blockhdr;
        signalname = binfiles(iSig).name;

        %%%%%%%%%%%% ... skipping lines of codes ... %%%%%%%%%%

        dat{end} = dat{end}(:,begsel:endsel);
      end
    end
    % concat signals
    dat = cat(1,dat{:});

In any case, as long as this is not corrected, people using fieldtrip to
read EGI MFF files should keep this in mind and order their channel indexes!

Best,

Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20170502/e5884c55/attachment-0001.html>