BEM coregistration

✉️ Mailing List Archive (read-only)
1

External Email - Use Caution

Hi,

I am using the mne.viz.plot_bem function and I get some co-registration
issues between the volume and the surfaces:
[image: image.png]

I am working with Lilla Z?llei pipeline, which do not produce the T1.mgz
file that is expected by the mne.viz.plot_bem function (as a side note, it
might be nice to have an optional mri arguments to mne.viz.plot_bem to
explicitly pass the location of the MRI file to use), so I generated it
from the original mprage.nii.gz volume expected as input by
infant_recon_all:

mri_convert $SUBJECT_DIR/mprage.nii.gz $SUBJECT_DIR/mri/T1.mgz

The different surfaces co-register well in freeview:

freeview -v $SUBJECT_DIR/brainmask.nii.gz \
                  $SUBJECT_DIR/mri/T1.mgz \
               -f $SUBJECT_DIR/surf/lh.pial:edgecolor=red \
                  $SUBJECT_DIR/surf/rh.pial:edgecolor=red \
                  $SUBJECT_DIR/surf/lh.white:edgecolor=blue \
                  $SUBJECT_DIR/surf/rh.white:edgecolor=blue \
                  $SUBJECT_DIR/bem/outer_skin.surf:edgecolor=yellow \
                  $SUBJECT_DIR/bem/outer_skull.surf:edgecolor=yellow \
                  $SUBJECT_DIR/bem/inner_skull.surf:edgecolor=yellow

produces

[image: Screenshot from 2020-01-15 12-41-39.png]
I am trying to pinpoint the source of this missmatch in mne.viz.plot_bem. I
am not that worry about mne.viz.plot_bem per se, but I am worry that it
might be indicative of how volumes and surfaces will be (wrongly)
co-registered when I will compute the source model.

Thanks for any advice on how to troubleshoot this. Best wishes,

Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20200115/441c87b4/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 311375 bytes
Desc: not available
Url : http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20200115/441c87b4/attachment-0002.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2020-01-15 12-41-39.png
Type: image/png
Size: 169012 bytes
Desc: not available
Url : http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20200115/441c87b4/attachment-0003.png

2

External Email - Use Caution

I am using the mne.viz.plot_bem function and I get some co-registration
issues between the volume and the surfaces:

This sort of problem has occurred before, and I think it had to do with
handling volume information / orientation properly.

which do not produce the T1.mgz file that is expected by the

mne.viz.plot_bem function (as a side note, it might be nice to have an
optional mri arguments to mne.viz.plot_bem to explicitly pass the location
of the MRI file to use), so I generated it from the original mprage.nii.gz
volume expected as input by infant_recon_all:

mri_convert $SUBJECT_DIR/mprage.nii.gz $SUBJECT_DIR/mri/T1.mgz

We might assume that the T1.mgz is in some standard orientation. Can you
see if adding `--conform` fixes things? I think plot_bem assumes a specific
slice orientation.

The different surfaces co-register well in freeview:

Internally freeview probably does this conforming, we probably do not. I
guess we could in theory use nibabel's resampling to get it in the correct
orientation.

I agree it would also make sense to:

1. Be able to specify the MRI image to use
2. Ensure the MRI is conformed to the correct orientation / reslice it if
necessary

Can you open an issue on GitHub and we can go from there?

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

3

External Email - Use Caution

Hmm... it looks like I was not running MNE will all the last commits. The
image I shown is probably what you would get on a pip install of the last
official release. On the current master, the co-registration IS good

[image: image.png]

The BEM surfaces were generated with the original MRI, so checking them
against a volume converted with --conform shows that they are not in
co-registration anymore (which is accurate) :

[image: image.png]

So, part of the issue was already kinda solved... I say kinda, because in
the current version, the displayed co-registration is faithful to the
underlying data. However, the orientation is good only for volume in the
"conform" space (i.e., these are supposed to be in coronal view... which is
not the case for the first (not conform) figure).

Sure, I'll create an issue on GitHub for that. Thanks for the feedback. For
now, I'll re-rerun with --conform and adjust my BEM surfaces accordingly.

Best,

Christian

Le mer. 15 janv. 2020 ? 14:31, Eric Larson <larson.eric.d at gmail.com> a
?crit :

        External Email - Use Caution

I am using the mne.viz.plot_bem function and I get some co-registration

issues between the volume and the surfaces:

This sort of problem has occurred before, and I think it had to do with
handling volume information / orientation properly.

which do not produce the T1.mgz file that is expected by the

mne.viz.plot_bem function (as a side note, it might be nice to have an
optional mri arguments to mne.viz.plot_bem to explicitly pass the location
of the MRI file to use), so I generated it from the original mprage.nii.gz
volume expected as input by infant_recon_all:

mri_convert $SUBJECT_DIR/mprage.nii.gz $SUBJECT_DIR/mri/T1.mgz

We might assume that the T1.mgz is in some standard orientation. Can you
see if adding `--conform` fixes things? I think plot_bem assumes a specific
slice orientation.

The different surfaces co-register well in freeview:

Internally freeview probably does this conforming, we probably do not. I
guess we could in theory use nibabel's resampling to get it in the correct
orientation.

I agree it would also make sense to:

1. Be able to specify the MRI image to use
2. Ensure the MRI is conformed to the correct orientation / reslice it if
necessary

Can you open an issue on GitHub and we can go from there?

Eric

_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
Mne_analysis Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20200115/799bde07/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 298415 bytes
Desc: not available
Url : http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20200115/799bde07/attachment-0002.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 165539 bytes
Desc: not available
Url : http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20200115/799bde07/attachment-0003.png