MNE source estimate analysis with multiple conditions

Dear MNE users,

I am analysing surface-based source estimates computed from evoked MEG data. I would like to extract peak amplitude times from source estimates of the difference between two experimental conditions (exp. and control), and as far as I can tell there are two approaches to this. One is to calculate the difference prior to computing source estimates (i.e: exp. evoked - control evoked) and then compute source estimates (.stc) based on the returned array. Another is to generate source estimates for each condition, and then subtract the returned stc files (exp.stc - control.stc) Unfortunately, these two approaches yield slightly different results (I suspect this is due to noise generated by the .stc subtraction) - so which would be most prudent? Alternatively, is there a different (more robust) approach that I could use?

Thanks in advance for any help!

Regards,

Lyam

Dear Lyam,

the reason why you see a difference between MNE(cond1) - MNE(cond2) and
MNE(cond1 - cond2) is because of the dipole orientations. The source
estimate only retains the magnitude of the dipoles. See here for some
more information about what is going on:

https://4006-1301584-gh.circle-artifacts.com/0/home/ubuntu/mne-python/doc/_build/html/auto_tutorials/plot_dipole_orientations.html

When using fixed orientations, there should not be any difference. When
using loose orientations (the default), MNE(cond1 - cond2) is in my
opinion the correct way.

regards,
Marijn.

Hi Lyam

I think it's great that you are making so much progress on your own! That
said, I'd like to chat with you before you put too much more time into this
project, just so we're on the same page. I (re)gained some insights into
beamforming in the final days before the conference and I'd like to chat
about all that. Maybe we could chat right after N&B on Monday?

Dear Marijin,

Thanks for your help! I think I see what you're saying, but just to clarify, does MNE(cond1-cond2) refer to source estimates generated from (evoked cond1 - evoked cond2)?

Regards

Lyam

Hi Liam,

yes, exactly!

Marijn.

But this way you will have a hard time interpreting your effect. Using dSPM
on each condition and then forming a contrast is also legitimate, as long
as you have a meaningful baseline. This would be dSPM(a) - dSPM(b).

Denis

This would be dSPM(a) - dSPM(b).

tiny detail: this will only be true if the two conditions have the
same number of epochs averaged in each condition.

Alex

Hi Alex,

Thanks for the tip! I'm glad you mentioned this because as it happens, I don't have the same number of epochs for each condition. Can you suggest a work around?

Regards

Lyam

Does your experimental logic allow you to equalize the number of epochs per
conditions or do you have some rare events by design?

Denis

I suppose we could equalise the number of epochs per condition, in theory (although I'm not familiar with the best way to do this). Basically the unequal epoch numbers arose due to problems during data collection, whereby a few random trials were lost in almost every subject.

Regards

Lyam

Hi Lyam,

See here:

http://martinos.org/mne/dev/generated/mne.epochs.equalize_epoch_counts.html

HTH,

Andy

Thanks Andy!

Hi everyone,

I have a followup question regarding the group level contrast: Do I need to
apply mne.label_sign_flip before averaging the activaitons across all
subjects?

I used "fixed=False, loose=0.2" to get the inverse solution, then I defined
"pick_ori="normal"" when applying the inverse solution to the evoked
difference (evoked1 - evoked2) for each subject.

I'm wondering if I should flip the signs when averaging the activations
across subjects.

Thanks for the help!

Lin

hi Lin,

the label_sign_flip is used to average time courses within a label
in order to avoid signal cancellations.

Alex

Hi Alex,

Thanks for the clarification.

As far as I understand, the sign flip can be used to avoid signal
cancellation when averaging signed values. This cancellation could come
from averaging within ROIs or across trials/subjects.
In the tutorial (
https://martinos.org/mne/stable/auto_examples/inverse/plot_compute_mne_inverse_epochs_in_label.html?highlight=make%20inverse),
you demonstrated how flipping signs affects the trial-average results.

Then do we need to worry about the signs when averaging across subjects? Or
do I misunderstand something?

One further questions is whether we need to flip the sign during the
cluster-based statistical analysis and during ANOVA within ROI.

Thanks for your help!

Lin

hi,

in this example the sign flip is not applied to epochs but
to vertices in the labels. What this figure:

https://martinos.org/mne/stable/_images/sphx_glr_plot_compute_mne_inverse_epochs_in_label_002.png

shows you is that you can equivalently apply the sign flip on evoked or on
epochs and then average.

In all examples the sign flip is not data dependent.

Alex

In all examples the sign flip is not data dependent.

Then do we need to worry about the signs when averaging across subjects?
Or do I misunderstand something?

Just want to add that, although the flip does not depend on the MEG data,
it does depend on the MRI data. Because the flip sign is arbitrary and
subject cortical geometries vary, the effective direction and sign can
change on a subject-by-subject basis. So one option is to morph all
subjects to the same space (e.g., to fsaverage ico-5) and do the sign
flipping on an identical source space. You lose some of the geometrical
accuracy of the sign flipping, but the alignment direction and sign
flipping should then be identical across subjects.

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20170531/6969dc0d/attachment.html

Hi Eric and Alex,

Now I think understand why the sign flip affects the source-level results
within a ROI.

Thanks again, Eric! That's exactly what I want to know. So I'll morph all
subjects to the same space first, and then conduct any ROI-based
statistical analysis on the sign flipped values?

Thanks!
Lin