Possible bug in ft_rejectartifact

[vlitvak]

Hi guys,

I was helping a colleague with his script and we came across an issue that I think is a bug but maybe I misunderstood the code intention. What we wanted to do is review some continuous data in databrowser, mark bad segments by eye and then epoch the data and exclude any trials that overlap with those marked segments.

To do that, we passed the continuos data and the trl in cfg.trl to ft_rejectartifact hoping to get a modified trl back. But around line 204, our trl gets replaces with one from data.sampleinfo. If I remove the sampleinfo field it doesn't help because just before that, line 201 reinstates it. So the way I see this code, lines 207-215 cannot be reached.

Hope all is well otherwise,

Vladimir

[schoffelen]

Hi @vlitlak, I'd be happy to look into this, but in order to do so: could you share a snippet of code + cfg?

[vlitvak]

fs = 1e3;
ttotal = 20;

raw = [];
raw.trial = {randn(10, ttotal*fs)};
raw.time = {linspace(0, ttotal, size(raw.trial{1}, 2))};
raw.label = {};
for i = 1:size(raw.trial{1}, 1)
raw.label{i, 1} = ['Ch' num2str(i)];
end

trl = 1:fs:size(raw.trial{1}, 2);
trl = [trl(1:(end-1))' trl(2:end)' 0*trl(2:end)'];

cfg = [];
cfg.trl = trl;
cfg.artfctdef.reject = 'complete';
cfg.artfctdef.visual.artifact = [5.5 7.7]*fs;
cfg1 = ft_rejectartifact(cfg, raw);

[schoffelen]

hmm, do you have a particular expectation with respect to the function's behavior if you input both a data object AND a cfg.trl (even if the cfg.trl were consistent with the data object)?
I naively thought that a user either does:

cfg = ft_rejectartifact(cfg); % with the cfg containing a trl (+ a cfg.artfctdef.visual.artifact) and the output cfg containing an updated trl-field,

or

data = ft_rejectartifact(cfg, data); % with the cfg NOT containing a trl, but only a cfg.artfctdef.blabla.artifact 

Admittedly it could be that the mutually exclusive scenarios are not well enough documented.

I think that the required behavior would be something like:

cfg = ft_databrowser(somecfg, raw); % for the marking of artifacts.
artfctdef = %some magic code to extract the visually defined artifacts in the previous function call

then:

cfg = [];
cfg.trl = some-matrix; % definition of epochs
raw_epoched = ft_redefinetrial(cfg, raw);

then:

cfg = [];
cfg.artfctdef = artfctdef;
raw_clean = ft_rejectartifact(cfg, raw_epoched);

[vlitvak]

Ah, yes. I suspected I was missing something. Still, I think this behaviour is a bit intransparent, also because FT functions are rarely called with just the cfg. Better documentation or a more meaningful error message would definitely help here.

[schoffelen]

OK, thanks. I built in an error check, and added a small sentence to the docstring