[FieldTrip] Different cfg.poststim values in ft_preprocessing alters signal

Schoffelen, J.M. (Jan Mathijs) jan.schoffelen at donders.ru.nl
Thu Feb 4 11:47:35 CET 2021


Hi Benjy,

You are probably looking at a downsampling artifact. I don’t understand why this happens, because the FT-code should be dealing with this ‘under the hood’.

Could you - after the call to ft_redefinetrial - explicitly demean the epochs, prior to resampling, and see whether your problem disappears? i.e. you should do something like: cfg = [];
cfg.demean = ‘yes’; data = ft_preprocessing(cfg, data); (as mentioned on the data structure after re-epoching, but before resampling)

I hope this helps.

Best wishes,
Jan-Mathijs



On 4 Feb 2021, at 10:57, Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>> wrote:

Hi Benjy,

Strange indeed. Does this still occur if you don't resample at all?

If so, I don't know what else it could be.

Unless someone else has an idea, perhaps you can create a small dataset and script with which we can reproduce the problem (on the latest FieldTrip version), then upload it to dropbox/google drive or similar,

Cheers,
Stephen








Op do 4 feb. 2021 om 10:42 schreef Barnett, Benjy <benjy.barnett.20 at ucl.ac.uk<mailto:benjy.barnett.20 at ucl.ac.uk>>:
Hey Stephen,

I believe I am plotting just single channels here, averaging over all the trials. After I call ft_timelockanalysis my dimord field is ‘rpt_chan_time’ and the dimensions of my  trial field as 228 x 204 x 169, which makes sense as I am looking only at the gradiometers, of which there are 204 in the neuromas set up.

Then when I plot the signal I am using this command:

plot(data_TL.time,squeeze(mean(data_TL.trial(:,39,:),1)))

Looking at, in this example, channel 39 on its own. As there are just 204 channels in the dimord field I don’t believe there are any reference channels added, and this jump occurs on ~20 different channels, and these vary across subjects. Like I say, I don’t think the issue is with my data since the plot of all the data in one long trial looks quite normal. Indeed, when I call ft_rejectvisual, you get an idea of the scope of the problem as multiple different trials have these large spikes (image attached).

All the best,
Benjy

<sub02.png>

On Feb 3, 2021, at 6:05 PM, Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>> wrote:

Hi Benjy,

Just a though - but am I right that you are plotting an average over channels? Can you look at the channels individually and see on which channels the jumps occur? Might you accidentally be adding a reference/external/trigger channel to the average?

Cheers,
Stephen

Op wo 3 feb. 2021 om 18:42 schreef Barnett, Benjy <benjy.barnett.20 at ucl.ac.uk<mailto:benjy.barnett.20 at ucl.ac.uk>>:
Hey Stephen,

Thanks for your help! Whilst this certainly answers my question about the slight difference between different trial lengths, the huge spikes at the beginning of trials remains regardless of whether I filter the data as a whole first, or if I segment into trials and then filter. Here’s my code for doing the filtering first (my code for the alternative way is in my initial post):

cfg = [];
cfg.dataset = full_path;
cfg.continuous = 'yes';
 %cfg.demean = 'yes';
%cfg.baselinewindow = baselinewindow;
cfg.lpfilter = 'no';
cfg.hpfilter = 'no';
cfg.dftfilter = 'yes';

data = ft_preprocessing(cfg);

cfg=[];
cfg.dataset=full_path;
cfg.trialdef.prestim=0.175;
cfg.trialdef.poststim=0.600;
cfg.trialdef.eventvalue=[6 7];
cfg.trialdef.eventtype='STI101';
cfg = ft_definetrial(cfg);
trl = cfg.trl(:,1:3);

cfg = [];
cfg.trl = trl;
data_segmented = ft_redefinetrial(cfg,data);

cfg = [];
cfg.resamplefs = 250;
data_ds = ft_resampledata(cfg, data_segmented);

cfg = [];
cfg.channel = 'MEGGRAD';
cfg.keeptrials = 'yes';
data_TL = ft_timelockanalysis(cfg,data_ds);

plot(data_TL.time,squeeze(mean(data_TL.trial(:,39,:),1))) %17, 23 and 39 are examples of spikes in channels
<PastedGraphic-1.png><PastedGraphic-2.png>


I’m still seeing spikes as in the images attached. Something else strange: when I change the poststim parameter to 0.075 instead of 0.175 (keeping everything else equal), the direction of the spike completely switches (see third image attached). This happens regardless or ft_definetrial/preprocessing order. Moreover, when I look at the signal across the single trial encapsulating all the data (i.e. before segmentation), there are none of these huge spikes where every event would be, only a few spikes that I assume are SQUID jumps.
<Screenshot 2021-02-03 at 11.29.20 AM.png><long_trial_single_channel.png>
This makes me think the issue is coming at the ft_definetrial() step. But since this does not read in the actual MEG data, I can’t work out what is causing this effect, it certainly doesn’t seem to be an issue with my data. I’ve added a couple of lines to the ft_trialfun_general function, so to be sure I’ve removed them and am just using the default version yet the problem is persisting.

Any assistance is of course greatly appreciated. Thanks!

Benjy
On Feb 2, 2021, at 4:14 PM, Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>> wrote:

Hey Benjy,

I would suspect this has to do with your (dft) filtering, which depends on the amount of data, and perhaps some small numerical differences due to resampling. Strange jumps at onset/offset of data segments also often indicate something to do with filtering.

To avoid this, and to create a fair comparison between your different trial duration segmentation, I would do the following:

- preprocess all your data as one long 'trial'. I.e. without segmentation. Do all your filtering at this step, i.e. at one go over all your data. This gives you the maximum frequency resolution & ability to filter low frequencies.
- segment your filtered data into trials using ft_redefinetrial.
- do your resampling
- check the different triallengths.

If anything stays slightly different, I would imagine it has to do with the resampling, because samples will end up slightly different on your axis, creating numerical differences. You could resample before segmenting, which would be more efficient, but then you'll have to deal with changing timing of your markers which would still be in the original samplerate. Dealing with time-axis and samples is a pain so personally I therefore always let FT deal with the resampling after trial segmentation.

Have fun,
Stephen

Op di 2 feb. 2021 om 16:36 schreef Barnett, Benjy <benjy.barnett.20 at ucl.ac.uk<mailto:benjy.barnett.20 at ucl.ac.uk>>:
Hey. When I am preprocessing my MEG neuromag data, I’m noticing that the signal of my channels are altered depending on how long after the stimulus I include in the trial, even in the portion of the trial that is overlapping between the two cases. For instance, if I use cfg.poststim = 2.5 in one run and cfg.poststim = 0.6 in a second, the two signals are not identical up until 0.6 seconds. Please see my code and attached plots of a Grad sensor in these two cases up to 0.6 seconds.

 % define trials
        cfg = [];
        cfg.dataset = full_path;
        cfg.trialdef.prestim = 0.175;
        cfg.trialdef.poststim = 0.6; % compare with 2.5 seconds
        cfg.trialdef.eventvalue = [6 7 9];

        cfg.trialdef.eventtype = 'STI101';
        cfg = ft_definetrial(cfg);

        % preprocess

        cfg.demean = 'yes';
        cfg.baselinewindow = [-0.175 0.025];
        cfg.lpfilter = 'no';
        cfg.hpfilter = 'no';
        cfg.dftfilter = 'yes';
split_files{1} = ft_preprocessing(cfg); %preprocess


%%%%%%%%%%%Downsampling%%%%%%%%%
  cfg = [];
    cfg.resamplefs = 250;
    data = ft_resampledata(cfg, split_files{1});


%%Visualisation
cfg = [];
        cfg.channel = 'MEGGRAD';
        cfg.keeptrials = 'yes';
        data = ft_timelockanalysis(cfg,data);
Xlim([-0.2 0.6])
        plot(data.time,squeeze(mean(data.trial(:,39,:),1)))

As you can see from the plots attached, these signals are not identical when they should be (shouldn’t they?). The first plot is when I Use 2.5 seconds post stim and the second is using 0.6. I’ve altered the xlim to show only up to 600ms on both. Also, can anyone explain these huge spikes at the beginning of trials, that’s my next problem to solve.

Thanks
<2_5_ch39_full.png><600_ch39_full.png>
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.science.ru.nl%2Fmailman%2Flistinfo%2Ffieldtrip&data=04%7C01%7C%7Cc7f847a07fbc4c4cac8708d8c871cefd%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637479738424978722%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=f9NDDrBOATwNX19%2FdZNeXNBPHjSkt7CE1Rsz8rrlCrM%3D&reserved=0>
https://doi.org/10.1371/journal.pcbi.1002202<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1371%2Fjournal.pcbi.1002202&data=04%7C01%7C%7Cc7f847a07fbc4c4cac8708d8c871cefd%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637479738424988676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uWIDbjcGuIXzM4tENQLekDQ75Yf%2BIT4ZG4GFZdvyGMM%3D&reserved=0>
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.science.ru.nl%2Fmailman%2Flistinfo%2Ffieldtrip&data=04%7C01%7C%7Cc7f847a07fbc4c4cac8708d8c871cefd%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637479738424988676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jBUiDPv75eewbj4G%2F24pREHEs6Ar46KDcMESfPL4e1Q%3D&reserved=0>
https://doi.org/10.1371/journal.pcbi.1002202<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1371%2Fjournal.pcbi.1002202&data=04%7C01%7C%7Cc7f847a07fbc4c4cac8708d8c871cefd%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637479738424998635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DvncDCqD72iDnHhI1O0EFOzH23f3JiiKA66s4Wyh3TU%3D&reserved=0>

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.science.ru.nl%2Fmailman%2Flistinfo%2Ffieldtrip&data=04%7C01%7C%7Cc7f847a07fbc4c4cac8708d8c871cefd%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637479738424998635%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XKUnfM0BGASBqhKqGZRI%2B%2BVh8mr7ZgNArynG4ADXizE%3D&reserved=0>
https://doi.org/10.1371/journal.pcbi.1002202<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1371%2Fjournal.pcbi.1002202&data=04%7C01%7C%7Cc7f847a07fbc4c4cac8708d8c871cefd%7C1faf88fea9984c5b93c9210a11d9a5c2%7C0%7C0%7C637479738425008590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TFsjFefENHfO1nunglkK9TUDG9PpxPnFel6iGtueHi8%3D&reserved=0>
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20210204/9df92e26/attachment.htm>


More information about the fieldtrip mailing list