extracting ROI sources using mne_compute_raw_inverse

✉️ Mailing List Archive (read-only)
1

Hi everyone,

I am trying extract the sources from a series of functional-anatomical rois
for frequency analysis, but am having some trouble getting good quality
data. I'm using mne_compute_raw_inverse to extract the data before loading
it into matlab.

Subjects completed an object recognition task during recording. To check the
quality of the extracted data, I've been averaging the timecourses in an
early visual ROI across all vertices and visualizing the evoked response.
For some of the subjects (e.g., S003-a, attached), the evoked response looks
normal. The evoked response for many subjects, however, looks like senseless
noise (S007-a) or shows an unexpected negative deflection (S010-a).

I don't think these problems are solely due to the labels I've drawn, or to
the intrinsic quality of the raw data. This is because when I average the
raw data for each subject using mne_process_raw, and then view the average
of the vertices inside the same ROIs using mne_analyze, the evoked responses
all look as expected, often very different from the averages produced from
my mne_compute_raw_inverse pipeline (see S007-b and S010-b).

Does anyone have an idea what the problem might be? Are there any special
considerations to take in account when using mne_compute_raw_inverse to
extract sources from ROIs? Why might the label averages using the two
different methods described look so different?

Thanks in advance for any help,

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20111018/660a8eb2/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S003-a.jpg
Type: image/jpeg
Size: 8653 bytes
Desc: not available
Url : http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20111018/660a8eb2/attachment.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S007-a.jpg
Type: image/jpeg
Size: 9967 bytes
Desc: not available
Url : http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20111018/660a8eb2/attachment-0001.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S010-a.jpg
Type: image/jpeg
Size: 8373 bytes
Desc: not available
Url : http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20111018/660a8eb2/attachment-0002.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S003-b.jpg
Type: image/jpeg
Size: 128598 bytes
Desc: not available
Url : http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20111018/660a8eb2/attachment-0003.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S007-b.jpg
Type: image/jpeg
Size: 107637 bytes
Desc: not available
Url : http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20111018/660a8eb2/attachment-0004.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S010-b.jpg
Type: image/jpeg
Size: 103700 bytes
Desc: not available
Url : http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20111018/660a8eb2/attachment-0005.jpg

2

Hi Matt,
   This is just a hunch.. So in viewing using mne_analyze, for the options
you have selected you are averaging the absolute value of the signal
across vertices.. On the other hand when using mne_compute_raw_inverse,
you seem to be doing a signed averaging (Which is the correct thing to
do given you want to do frequency analysis). What happens when you
average the signed signal across vertices is that since the orientation
of the sources is not the same and the MNE spreads, some vertices have
positive polarity deflections and some have negative polarity
deflection and they cancel.. The avoid this cancellation there is a
--align_z option in mne_compute_raw_inverse that you could use which
is described in the manual.

Hope it helps,

Regards,
Hari

3

Hi Hari,

Thanks for your response. I had included the --align_z flag with
mne_compute_raw inverse, so unfortunately I don't think this is the issue.
Do any other possibilities come to mind?

This is a shot in the dark on my part, but the script I inherited for this
analysis also included the --picknormalcomp flag with
mne_compute_raw_inverse. Could this be causing trouble for any reason?

Thanks again,

Matt

4

Hi Matt,
   I'm not sure if the implementation of mne_compute_raw_inverse ignores
the --align_z flag if (1) --picknormalcomp is used and/or if (2) Your
source space contains sources of fixed orientation... So unfortunately,
I don't have a better suggestion than to try leaving out the
picknormalcomp option or if you are using a fixed orientation solution
try loose..

I can share python code (that's not tested much) that works with a fixed
orientation inverse operator if you are interested in playing with it..

Regards,
Hari

5

Hi Hari,

Your hunch about the source orientation was correct. I took a look at the
individual traces at each vertex that were used in calculating the evoked
average for the label; even with the --align_z option the polarity wasn't
consistent across all of the vertices. I baseline corrected the traces to
zero and took their absolute value before averaging, and now the evoked
response looks fine. Thanks for pointing out the problem to me; this had
been a big headache.

Thanks,

Matt

6

Hi Matt,
    Glad that was helpful.. However you'll still need to align the
polarities or do frequency analysis at each vertex (power spectrum for
instance) and then pool across vertices since the absolute value
operation is highly non-linear and the abs valued signal is not
suitable for frequency analyses.

Regards,
Hari