search

mne-tools / mne-python

MNE: Magnetoencephalography (MEG) and Electroencephalography (EEG) in Python
https://mne.tools
BSD 3-Clause "New" or "Revised" License
2.76k stars 1.33k forks source link

Q: Issue with source reconstruction on my BEM but not sample's #3283

Closed kingjr closed 8 years ago

kingjr commented 8 years ago

I am struggling to reconstruct the source of a presumably simple dataset.

The evoked topo (here at 180ms) looks dipolar, and should come from the back of the brain (response to visual stim).

4_mag

When I reconstruct the source on with the sample BEM, i get something relatively expected (to the extent that it's in the back of the brain.

dipole_orig_bem

However, when I try to reconstruct on my subject's actual bem, I get very unlikely reconstructions: Here MNE at 180ms reconstruct a frontal activity (similar with dSPM and sLORETA, in mne-python or mne-c): 8_mne 10_dipole

I checked that the source space and trans alignment make sense (here dipole fit at 180 ms):

2_source 0_trans

I'm using the same evoked and covariance in both cases.

I encounter this issue with all of my subjects.

Any idea in what direction I search?

[I can share the data in private, I haven't defaced the MRI]

EDIT: this was actually incorrect, I wasn't using the same covariance across cases.

agramfort commented 8 years ago

Check the sensitivity maps of your forward

On Sat, Jun 4, 2016 at 2:22 PM -0700, "Jean-Rémi KING" notifications@github.com wrote:

I am struggling to reconstruct the source of a presumably simple dataset.

The evoked topo (here at 180ms) looks dipolar, and should come from the back of the brain (response to visual stim).

When I reconstruct the source on with the sample BEM, i get something relatively expected (to the extent that it's in the back of the brain.

However, when I try to reconstruct on my subject's actual bem, I get very unlikely reconstructions: Here MNE at 180ms reconstruct a frontal activity (similar with dSPM and sLORETA, in mne-python or mne-c):

I checked that the source space and trans alignment make sense (here dipole fit at 180 ms):

I'm using the same evoked and covariance in both cases.

I encounter this issue with all of my subjects.

Any idea in what direction I search?

[I can share the data in private, I haven't defaced the MRI]

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

kingjr commented 8 years ago

The error was coming from the covariance estimation.

I believe this is because I am computing the covariance across all epochs, although they are concatenated from different runs, (and therefore were maxfiltered separately, but supposedly head realigned).

Here is the covariance ranks computed on 168 epochs from a single run: cov1

and the sources found: source1

Here is the covariance ranks computed from 168 epochs from one run and 2 trials from another run. cov3

and the corresponding sources source3

The issue is independent of the covariance's method.

Thanks hips to @Eric89GXL for his help! (Turned out that it work with your data because I had cropped it to make it lighter)

I think we should add a warning on the compute_covariance when we detect that the epochs are not from the same run (if it's even possible?).

larsoner commented 8 years ago

We should at least emit a warning, yeah. The info['dev_head_t'] at the very least should be checked for consistency, that presumably would have caught your problem.

Presumably using the Maxwell filter head translation to the same coordinate frame would also solve this problem.

kingjr commented 8 years ago

Presumably using the Maxwell filter head translation to the same coordinate frame would also solve this problem.

I thought that was already applied on my data. I don't have access to the raw and didn't do this step myself. Is there a way to check it out and reprocess it?

larsoner commented 8 years ago

Reprocessing would probably be a pain, but you could try it. You can check by seeing if info['dev_head_t'] match across all files.

kingjr commented 8 years ago

You can check by seeing if info['dev_head_t'] match across all files.

They don't :(

Reprocessing would probably be a pain, but you could try it.

By 'pain' you mean that it would be long, or would it cause processing issues? Would it be fine to do this with MNE on sssed data?

larsoner commented 8 years ago

I mean that I'm not sure how good the data will be if you just use maxwell_filter to do only a head position change. You can certainly try it. Use the same internal order, external order, and probably no regularization (or maybe the same regularization, which would have been "in" if it had been turned on) and you can probably do it with maxwell_filter. You might end up in some trouble because our calculations are not 100% identical with those of MaxFilter, but you could try it. So it might actually be better if you call MaxFilter with -force to do it for you.

agramfort commented 8 years ago

calling evoked.plot_white would have helped too :)

kingjr commented 8 years ago

@agramfort mmmh, I don't think so.

This is the whitened evoked with the cov computed from a single run good_white

This is the whitened evoked with the cov computed from multiple runs bad_white

agramfort commented 8 years ago

hum overfit the baseline and your noise cov is not regularized at all... can you try with the shrunk method? for me own personal interest and certainly @dengemann :)

larsoner commented 8 years ago

I suspect it won't help too much because the eigenvalue spectrum's falloff is no longer that steep due to the different head positions. But maybe it's robust enough to do it.

agramfort commented 8 years ago

worth trying but I agree not the proper fix. I am just curious

On Mon, Jun 6, 2016 at 9:55 PM, Eric Larson notifications@github.com wrote:

I suspect it won't help too much because the eigenvalue spectrum's falloff is no longer that steep due to the different head positions. But maybe it's robust enough to do it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mne-tools/mne-python/issues/3283#issuecomment-224069311, or mute the thread https://github.com/notifications/unsubscribe/AAJ1HI9lT-8t7H0dKjQCGSWtWfnq6rzlks5qJHs1gaJpZM4IuONV .

kingjr commented 8 years ago

For this subject, shrunk works nicely if I give all the trials (n=900); however it seems that if I only give a few trials from an extra block, I retrieve weird frontal activity again; So I guess it is indeed SNR issue.

I had originally used the shrunk method in my pipeline, and several subjects had crazy activations as described here, this is why I started to dig the issue.

Also, FYI the whitened evoked with shrunk with 900 trials gets values outside the plot limit (we actually don't see anything in the default plot, including in the baseline).

kingjr commented 8 years ago

Any chance I can realign the heads directly on epochs data? Just to check whether it's worth it...

dgwakeman commented 8 years ago

You could source analyze the runs separately, and then average the source reconstructed data. But with as much motion as there must be to have this much of an issue, I would trash the data. There are some data collection issues, that just arent recoverable IMO

kingjr commented 8 years ago

@dgwakeman ok this seems indeed suboptimal. If I have time I'll try to get the raw and realign from the beginning.