partial artefact rejection

[jan-mathijs schoffelen]

Dear Nina,

I am not sure whether I understand your question exactly, because as
far as I can judge from your concern, there is none ;o).
No doubt you already had a look at the tutorial documentation:
'automatic artifact rejection' on the website. It is indeed the case
that data points identified as artifact are removed from the data. As
a consequence, the cell array that represents your data is changed
(data.trial). Also, the field data.time changes obviously, because
some parts of the data are removed. One of the following scenarios
can occur:
-there is no artifact in the trial -> so this particular trial
survives unchanged
-there is an artifact at one of the edges of the trial. As a
consequence, the trial and time axis are shortened. Importantly, when
the trial is shortened on the left, the offset should also change,
because this value defines the offset of the first sample in this
trial with respect to the user-defined timepoint 0. To ensure a
correct subsequent time-locked analysis (or TFR for that sake), a
trial that loses 100 milliseconds on the left should have its offset
updated with 100 (if the sampling rate is a 1000 Hz). (Tonight's
question is whether this should be an increase or a decrease).
-there is one or more artifacts in the middle of the trial. As a
consequence, the trial is cut into several pieces; correspondingly
the time axes have to be adjusted, and also the offsets. This means
that it could be that your original 100th trial ends up in several
different new 'trials'.
All this should not be a big problem, because each step in the
analysis should output a structure containing the configuration used
in earlier steps of the analysis. If you would want to keep track of
the original trials, you should always be able to match the cfg.trl
in the output of rejectartifact, with the cfg.trl obtained after
definetrial.
With respect to your second question: if you want to pad your trials
with data for the purpose of filtering, you can specify the option
cfg.padding before calling preprocessing. If you for example defined
your trials to last between event-of-interest - 1 second, and event-
of-interest + 1 second, and your cfg.trl is defined accordingly, you
can specify cfg.padding to be for example 3 seconds. This means that
on each side of the trial, 0.5 seconds of extra data is read from the
raw datafile, filtering (or similar things) is applied, and the edges
are cut off again, so that you end up with 2-second segments. If you
want to do artifact rejection prior to the actual reading and
preprocessing of your data, you have to specify cfg.padding prior to
calling rejectartifact, and then the routines will look for artifacts
in the padded data. This makes sense, because filtering of an
artifact (such as a squid-jump) could lead to nasty effects.

I hope this helps,

JM

On Feb 11, 2009, at 3:14 PM, Nina Kahlbrock wrote:

> Dear all,
>
> I have a question concerning partial artefact rejection.
> In my experiment, I have used trials of different lengths. For
> preprocessing, I have extended all of the trials to a certain
> length in
> order to avoid filter artefacts from cutting trials. I have then used
> partial artefact rejection and preprocessed the trials.
> In order to calculate TFRs, I would like to use the actual lengths
> of the
> trials again by cutting the trials to the former lengths.
> Now my questions: How exactly is partial artefact rejection done?
> As I see
> it from my data, the data points contaminated by artefacts are
> removed from
> the structure, right? The offset seems to be adjusted to the cut
> trials, though.
> How do you suggest that I get my actual trial lengths back? It
> seems that I
> cannot know what part of the remaining data still belongs to my old
> trial
> and which part belongs to the part that was only used for
> preprocessing but
> needs to be cut out.
>
> I appreciate your help!
>
> Thanks in advance,
>
> Nina
>
> ----------------------------------
> The aim of this list is to facilitate the discussion between users
> of the FieldTrip  toolbox, to share experiences and to discuss new
> ideas for MEG and EEG analysis. See also http://listserv.surfnet.nl/
> archives/fieldtrip.html and http://www.ru.nl/fcdonders/fieldtrip.

----------------------------------
The aim of this list is to facilitate the discussion between users of the FieldTrip  toolbox, to share experiences and to discuss new ideas for MEG and EEG analysis. See also http://listserv.surfnet.nl/archives/fieldtrip.html and http://www.ru.nl/fcdonders/fieldtrip.