EOG/ECG SSP over several runs?

Discussions
1

Dear BST masters,

I have followed the procedure (http://neuroimage.usc.edu/brainstorm/Tutorials/TutRawSsp) for computing EOG and ECG SSPs for one (continuous raw) run of my data (Neuromag, 8 runs per subject), and despite there are more than 20 blinks, SSP components are not neat and cleaning is not at all optimal.

Would it be possible to compute the SSPs simultaneously on the 8 runs? Can I do it by putting all of them in the Process1 and detect blinks and compute the SSP? I am trying but I am not sure that itā€™s computing the same SSP for all or not. BTW head movement has been corrected with Neuromag tools before importing the data to BST.

Any other tip on how to improve SSP computation?

Thanks,

Marco

1 Like
2

Hi Marco,

You canā€™t run directly the SSP computation on multiple RAW files, it would run it individually for each run.

However, you can do it using a more flexible pathway:

  1. Create a new subject using the ā€œYes, use one channel file per subjectā€
  2. Link your 8 runs to the database (Review raw file)
  3. Detect the blinks in all the runs
  4. Import the blinks for each run: right-click on the link to raw file > Import in database > Select event ā€œblinkā€, epoch time [-200, +200] ms.
  5. Drag and drop the imported epochs in the folder ā€œblinkā€ (contains all the blinks for the 8 runs)
  6. Run the process ā€œCompute SSP: Eye blinksā€, and in the end of the process say ā€œYes apply to other files in the databaseā€. This will also add the same projector to each ā€œlink to raw fileā€.
  7. Double-click on one Link to raw file: in the the SSP tab, select the menu ā€œSelect active projectorsā€ to review the SSP that was calculated.

Cheers,
Francois

1 Like
3

And also Marco:

Are these all blinks? Does the detection lock on saccades as well? Are there multiple categories of blinks detected by the algorithm?
Also, did you try to include more SSP components than just one?
Please post a few screenshots when you get a chance.

Grazzie,

4

Hi Francois & Sylvain,

here I am again with the SSP analysis. I now have carefully preprocessed the (Neuromag) data for one subject (8 runs): data are now maxfiltered (i.e. no more bad channels, and co-registration of all runs) and bad segments are marked using the Brainstorm Review Raw option. I think this step is crucial for good identification of ECG and blink triggers because bad segments can give very bad examples of blinks and ECG artifacts.

I have tried to follow the steps that you indicated (quoted below), but I ended up with doing something simpler, and I would like to know if there is anything wrong with that.

  1. I linked my just preprocessed 8 runs to the database (Review raw file)
  2. I detected the blinks in all the runs
  3. I imported the blinks for each run: right-click on the link to raw file > Import in database > Select event ā€œblinkā€, epoch time [-200, +200] ms. All blinks from all runs automatically added up in the ā€˜blinkā€™ file of the ā€˜blinkā€™ folder of my subject.
  4. I dragged the ā€˜blinkā€™ file into the Process 1 window and ran the process ā€œCompute SSP: Eye blinksā€. Nothing like ā€œYes apply to other files in the databaseā€ appeared in the end of the process.
  5. By double-clicking on one Link to raw file: in the the SSP tab, I went to the ā€˜blinkā€™ folder to select the menu ā€œSelect active projectorsā€ to apply the projector and review the SSP that was calculated.

I have done this for magnetometers only and for two runs only, and before proceeding I would like to know if itā€™s ok.

Next I will be happy to show you the result on running SSP on one vs multiple runs.

Thanks for your help,

Best,

Marco

[QUOTE=Francois;4810]Hi Marco,

You canā€™t run directly the SSP computation on multiple RAW files, it would run it individually for each run.

However, you can do it using a more flexible pathway:

  1. Create a new subject using the ā€œYes, use one channel file per subjectā€
  2. Link your 8 runs to the database (Review raw file)
  3. Detect the blinks in all the runs
  4. Import the blinks for each run: right-click on the link to raw file > Import in database > Select event ā€œblinkā€, epoch time [-200, +200] ms.
  5. Drag and drop the imported epochs in the folder ā€œblinkā€ (contains all the blinks for the 8 runs)
  6. Run the process ā€œCompute SSP: Eye blinksā€, and in the end of the process say ā€œYes apply to other files in the databaseā€. This will also add the same projector to each ā€œlink to raw fileā€.
  7. Double-click on one Link to raw file: in the the SSP tab, select the menu ā€œSelect active projectorsā€ to review the SSP that was calculated.

Cheers,
Francois[/QUOTE]

5

Hi Marco,

I think there is no difference between what you are describing and what I suggested, except for this question ā€œapply to other filesā€ that I removed in the meantime (the processes are not supposed to have any interactive questions).
So I guess you can keep on proceeding this way.

Cheers,
Francois

6

Sounds reasonable, Marco:

However, if the subject has moved substantially between runs, the SSP projectors are non-optimal for each run because the topography of the eye artifact will change from one run to the next. I understand though that you developed this strategy because the single-run SSP blink correction did not work well on this subject in the first place; so I guess this is fine if youā€™re happier with the end result.

Cheers,

7

Dear Sylvain,

For movements between runs, I rely on the Neuromag movement correction algorithm applied with Maxfilter, but it is true that I do not have a systematic test of its efficiency.

What would you advice otherwise, for runs that have 10-15 blinks and for which the SSP projection is not very clean? Is it safer to give up the SSP and just reject those trials?

Thanks,

Marco

[QUOTE=Sylvain;4872]Sounds reasonable, Marco:

However, if the subject has moved substantially between runs, the SSP projectors are non-optimal for each run because the topography of the eye artifact will change from one run to the next. I understand though that you developed this strategy because the single-run SSP blink correction did not work well on this subject in the first place; so I guess this is fine if youā€™re happier with the end result.

Cheers,[/QUOTE]

8

Hi Marco:

If the blink contamination is strong and visible in the MEG traces and overlaps with the frequency bands you will be looking at, itā€™s indeed advisable to try to attenuate it. The MaxMove approach can help register traces in-between runs: I did not have much success applying it myself as it had a tendency to create oscillatory artifacts over the vertex sensors. If youā€™re happy with it, your approach sounds fine indeed. I understand the detection of the blinks works well, but the SSP projections are not very efficient with your data: could you please post a snapshot of say the first 2 SSP components and of a typical MEG topography at the peak of a blink before and after SSP correction? thanks!

9

Hi Sylvain,

first of all, I have realized that part of the problem was that in a first analysis, I had not discarded some bad segments, which affected both the detection process and the computation of SSP.

Now, with cleaner data, I see that the default parameters of blink detection work very well. But even with 40 blinks detected, for one run it seems to me that the blink SSP captures more than the blink, while if I use the SSP computed over two runs (this one and another one, so with around 85 blinks detected), there is some improvement.

Attached,

  • the first 2 SSPs computed from run 3 and from run 3 + run 2. The second projector seems almost irrelevant, so SSP is then computed with the first projector only. Percent variance: 14% first projector, 9% second projector.
  • One representative blink example (time course and topography) of run 3 without correction
  • Blink topography after correction of SSP from the same run, and of SSP from both runs.

I hope this is clear.

Thanks for your feedback,

Marco

[QUOTE=Sylvain;4874]Hi Marco:

If the blink contamination is strong and visible in the MEG traces and overlaps with the frequency bands you will be looking at, itā€™s indeed advisable to try to attenuate it. The MaxMove approach can help register traces in-between runs: I did not have much success applying it myself as it had a tendency to create oscillatory artifacts over the vertex sensors. If youā€™re happy with it, your approach sounds fine indeed. I understand the detection of the blinks works well, but the SSP projections are not very efficient with your data: could you please post a snapshot of say the first 2 SSP components and of a typical MEG topography at the peak of a blink before and after SSP correction? thanks![/QUOTE]

10

Thank you very much, Marco:

40 blinks is a pretty good-sized sample: so I understand that with 40 events, the SSPs are capturing more than just blinks, right? Looking at the topographies and the time series you sent, I would agree with that and it seems to me the SSPs are also capturing some of the cardiac artifacts (strong and smeared left/right central topography). I would encourage you to remove the cardiac artifacts in the first place and then proceed to correcting for eye blinks: maybe thatā€™s what you did already. If you do not have an ECG channel available, you can use any MEG channel showing the strongest ECG-like patterns.

Cheers,

11

Dear Sylvain,

I have computed the EOG SSP AFTER application of the ECG SSP as you suggested and unfortunately it looks worse (see attachments). I guess the EOG SSP is capturing something elseā€¦ I donā€™t want to bother you further with my specific data, but this makes me wonder whether the SSP method is the best for artifact removal.

I extensively use ICA for the same purpose with EEG data and I find it very efficient in discriminating artefacted components of different nature, and I wonder whether it could help in situations like this where the EOG SSP might capture more than one effect. I know that this is not implemented in Brainstorm, but I have thought of exporting the data into Fieldtrip, compute ICA, remove ā€˜badā€™ components and import it back to Brainstorm. So hereā€™s a bunch of questions about that:

  • Do you see or have experience of any drawback of using ICA on MEG data for this purpose?
  • Are there any conversion dangers in exporting to matlab and reimporting back?
  • How is it possible to account for the ICA components removed when doing source reconstruction?

Apologies if this has already been dealt withā€¦

Thanks,

Best,

Marco

[QUOTE=Sylvain;4882]Thank you very much, Marco:

40 blinks is a pretty good-sized sample: so I understand that with 40 events, the SSPs are capturing more than just blinks, right? Looking at the topographies and the time series you sent, I would agree with that and it seems to me the SSPs are also capturing some of the cardiac artifacts (strong and smeared left/right central topography). I would encourage you to remove the cardiac artifacts in the first place and then proceed to correcting for eye blinks: maybe thatā€™s what you did already. If you do not have an ECG channel available, you can use any MEG channel showing the strongest ECG-like patterns.

Cheers,[/QUOTE]

12

Hi Marco:

Iā€™d love to have a look at your file, if possible: can you use dropbox? Itā€™s important we understand why this is not working for you and what kind of other issue there might be in the data, because it might also affect ICA.
Speaking of which, ICA is a powerful technique indeed. We just donā€™t push for it because we prefer to have an informed rather than blind (in the blind-source separation sense) approach to artifact detection and correction. SSP works really well in general, hence I am suspecting another source of artifact in this dataset.

No conversion issue though with exporting and importing back from and to Brainstorm, as long as the file structure is preserved. No need either to alter the forward and inverse source model after ICA, because ICA artifact correction operates a subtraction from the data, not a projection.

Let me know if itā€™d be possible to have a look at your data, please.

1 Like
13

Hi Sylvain,

I am very happy to let you have a look! Should I give you the original (maxfiltered) file or the one in Brainstorm (that includes bad segments, eog and ecg triggers etc.)? And in the second case, should I export as a matlab file?

Thanks for your assistance,

Marco

[QUOTE=Sylvain;4928]Hi Marco:

Iā€™d love to have a look at your file, if possible: can you use dropbox? Itā€™s important we understand why this is not working for you and what kind of other issue there might be in the data, because it might also affect ICA.
Speaking of which, ICA is a powerful technique indeed. We just donā€™t push for it because we prefer to have an informed rather than blind (in the blind-source separation sense) approach to artifact detection and correction. SSP works really well in general, hence I am suspecting another source of artifact in this dataset.

No conversion issue though with exporting and importing back from and to Brainstorm, as long as the file structure is preserved. No need either to alter the forward and inverse source model after ICA, because ICA artifact correction operates a subtraction from the data, not a projection.

Let me know if itā€™d be possible to have a look at your data, please.[/QUOTE]

14

Both would be great if possible; otherwise, just the Brainstorm version. To export from Brainstorm, go to the File menu and > Export Protocol: this will create a zip archive of all files in the selected protocol.

Thanks!

15

It takes a long time to export the protocol since it has more than one subject. Is it ok if I export the subject only (subjectname > right click > File > Export subject)?

Thanks,

Marco

[QUOTE=Sylvain;4932]Both would be great if possible; otherwise, just the Brainstorm version. To export from Brainstorm, go to the File menu and > Export Protocol: this will create a zip archive of all files in the selected protocol.

Thanks![/QUOTE]

16

Sure: the subject causing trouble will suffice. Please make sure you export from the Data panel, to actually export the MEG data, not just the anatomy.

Thank you!

17

Thank you for sharing the data, Marco.

I looked it up and I was quite satisfied with the outcome of the SSP correction for eye blinks. I used the automatic detection from EOG61, with clustering: it found 44 events of one clear type of blinks, which I selected for SSP computations. The first SSP component had a more central and posteriori topography, which might be from the intermittent, high-frequency artifact bursts present in the data. The second SSP component had a clear eye-blink topography. I am attaching 2 screenshots: one before and one after the projection away from that SSP-blink component. Let me know what you think.

Cheers,

18

Thanks Sylvain for looking into this. I totally agree with your analysis of the gradiometers. However, magnetometers are the ones that show more clearly the mixed SSP for blinks I was mentioning in this thread. The first SSP component for blinks shows both frontal typical blink topography and some parietal activity (negative on the left, positive on the right) (Figure MEGnoSSP, right-hand topography). The second SSP (not shown here but I think in previous posts) does not even have a frontal component. Figures show the effect of removing the first SSP component in frontal and parietal sensors (sensor position in Figure MEG_channelselection), same blink that you showed in your post. While the effect of blink is mostly removed, parietal signals are also modified and even change sign (Figure MEGSSP).

What is the cause of the parietal component of the SSP? I was not able to detect the high-frequency artifact you were mentioning (filtering the data below 40 Hz did not change the results). BTW where/how do you see it? By inspecting the data blink by blink, I see two factors: 1) the effect of blinks on sensors is relatively small, 2) one component of high variability is given by alpha oscillations. So I computed the blink SSP by restricting the frequency band to 1-6 Hz and extending the time window to [-300 300] ms. The resulting SSP has a much smaller parietal component, and there is a lower effect on parietal sensors (Figure MAGSSP2).

Restricting the blink SSP computation to the alpha-band (8-12 Hz), I recover the parietal topography of the original SSP (MAGSSPalpha). And in fact, looking at the blink-related fields on the sensors selected above in the alpha band, it is clear that the blink elicits an alpha ERD on the parietal sensors. This might be the reason why the blink SSP has this component.

Summarizing, I see two possibilities here:

  1. The blink SSP looks weird, but the blink artifact is small, letā€™s ignore it;
  2. I restrict the computation of the SSP blink to the lowest frequencies and I remove that one.

What is your advice on this?

Apologies for this long post as this might not be a very general case, but I think itā€™s instructive to understand doubtful cases.

Best,

Marco

19

Thank you for the detailed report. I agree there seem to be an alpha ERS/ERD related to the blink, hence the parietal SSP component, which is #1 is the list from the automatic SSP pipeline. Hence thatā€™s why I suggested you select only the second SSP projector in the list, which is typical of frontal contamination by blinks. You may want to remove the first alpha component only if you suspect the blinks are event-related and that subsequent data analysis will concern event-related variations for alpha power, for instance. In that case, you may want to opt for option #2 you suggest (changing the filter parameters for SSP computation). Otherwise, I would stick to the blink artifact only.
The high-frequency bursts are relatively rare, but I am attaching an instance I found in the data.

Cheers,

20

Dear Sylvain,

in fact the second SSP projector for GRAD (the ones for which you computed the SSP) is typical of frontal contamination, but the second SSP projector for MAGs is not, as it also contains a parietal component (attached the first and the second one for MAGs). Thatā€™s why I hesitate on removing it or not.

Related to the high-frequency bursts, I had classified them as frowning or similar as they show variable frontal dipole topography (even if not only that) and are correlated with high-frequency noise in both horizontal and vertical EOG (see figure), and excluded them before computing the SSP.

Cheers,

Marco

[QUOTE=Sylvain;4962]Thank you for the detailed report. I agree there seem to be an alpha ERS/ERD related to the blink, hence the parietal SSP component, which is #1 is the list from the automatic SSP pipeline. Hence thatā€™s why I suggested you select only the second SSP projector in the list, which is typical of frontal contamination by blinks. You may want to remove the first alpha component only if you suspect the blinks are event-related and that subsequent data analysis will concern event-related variations for alpha power, for instance. In that case, you may want to opt for option #2 you suggest (changing the filter parameters for SSP computation). Otherwise, I would stick to the blink artifact only.
The high-frequency bursts are relatively rare, but I am attaching an instance I found in the data.

Cheers,[/QUOTE]