Pial and inner skull surfaces intersecting

Greetings,
I've noticed that the pial and inner skull surfaces in my data set are
intersecting. I am using FLASH 5 and 30 volumes to create 3-layered BEM
using the sequence of mri_make_bem_surfaces & mne_watershed_bem with the
default arguments after the necessary registration (with T1) and conversion
(brainmask & T1 --> cor) routines. It appears that both inner and outer
skull tables need to be pushed further out toward the outer skin (which is
looking fine). Does any one have any ideas how this can be done e.g., using
a different preflooding argument for mri_watershed or tweaking some other
parameter; and does it have to be done outside the MNE convenience script?

Thanks in advance
Kambiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20141103/645a2a8d/attachment.html

Hi Kambiz,

The pial and inner skull surfaces intersecting is not a problem given
the coarseness of our forward models. In practice these two surfaces
can and do touch one another in the head. Pushing the surfaces out
would only create additional error in your solution. The only
important thing is that you are using a reasonable value for the
mindist option (which relates the white surface: the source space) to
your BEM surfaces.

HTH
D

Hi Kambiz,

The pial and inner skull surfaces intersecting is not a problem given
the coarseness of our forward models.

I don't have a solution for you but I would not be so convinced that it
has low influence. If 2 vertices/triangles are too close then you can numerical
errors with BEM models. I would try to correct for it. Isn't there a way to use
an atlas to avoid this?

otherwise use MEG and a single layer :slight_smile:

Alex

Alex,

Don't you think this is less of a problem, since we don't use the pial
surface as the source space? Plus the mindist requirement throws out
points too close?

There are not any automated available tools to do this.

D

Hi Kambiz, Alex and Dan,

In the occipital regions particularly, FLASH-based BEM's seem to be consistently "tight", and in some cases we've even seen inner skull-WM-intersections (admittedly pathological and rare). Omitting such points using mindist is perhaps an option, but doesn't seem very elegant. Furthermore, the inner skull boundary is guaranteed to be wrong, which is not a good outset for forward modelling.

@Kambiz Our experience indicates that the freesurfer-based brainmask is pretty aggressive in the occipital region, which might have some impact on mne_flash_bem. I can see that the brain.mgz-file is often "better" in that it includes a hint of dura outside the pia, but it's very faint and may not be picked up by mri_make_bem_surfaces. Perhaps the use of the -wsthresh parameter to recon-all would help? Do you also see this occipitally?

May not, could not, whatnot... I'm just guessing, of course, since the inner workings of the bem creation are hidden.

I feel this is a suitable opportunity to advocate for some clever person out there to implement a new (and tweakable) BEM surface creation tool. According to the FS website (http://freesurfer.net/fswiki/mri_make_bem_surfaces), we are relying on closed-source code written 15 years ago... Any takers? :wink:

@Alex Could you write a few words on how the --atlas option might help here?

/Chris

hi,

Don't you think this is less of a problem, since we don't use the pial
surface as the source space? Plus the mindist requirement throws out
points too close?

my bad I though there was some intersection is the bem surfaces (inner
and outer skull).

regarding --atlas command I know that sheraz has used it.

Alex

Hi Chris,

Hi Kambiz, Alex and Dan,

In the occipital regions particularly, FLASH-based BEM's seem to be
consistently "tight", and in some cases we've even seen inner
skull-WM-intersections (admittedly pathological and rare). Omitting such
points using mindist is perhaps an option, but doesn't seem very elegant.
Furthermore, the inner skull boundary is guaranteed to be wrong, which is
not a good outset for forward modelling.

This is very surprising. Usually, the inner_skull surface generated by
mri_make_bem_surfaces does an excellent job hugging the flash 5. Can
you send an image showing the surface on the flash 5? I have seen some
small clipping of the pial surface due to the sharpness at the brain
at the tip of the occipital lobe, but I have never seen it cross the
white matter.

It is also important to note that MPRAGE type sequence are virtually
useless for determining the skull boundary, as they don't provide any
contrast between cortical bone and CSF.

With regards to the inner skull boundary being wrong, in practice this
is a visualization issue, because the underlying math with which the
BEM is calculated is not sensitive to these minor changes. We would
need a new BEM solver (first, and then fix the mesh issues) to make
these small surface changes have an effect on our solutions.

@Kambiz Our experience indicates that the freesurfer-based brainmask is
pretty aggressive in the occipital region, which might have some impact on
mne_flash_bem. I can see that the brain.mgz-file is often "better" in that
it includes a hint of dura outside the pia, but it's very faint and may not
be picked up by mri_make_bem_surfaces. Perhaps the use of the -wsthresh
parameter to recon-all would help? Do you also see this occipitally?

May not, could not, whatnot... I'm just guessing, of course, since the inner
workings of the bem creation are hidden.

I feel this is a suitable opportunity to advocate for some clever person out
there to implement a new (and tweakable) BEM surface creation tool.
According to the FS website
(mri_make_bem_surfaces - Free Surfer Wiki), we are relying on
closed-source code written 15 years ago... Any takers? :wink:

I nominate you :wink:

HTH,
D

Hi Dan,

Here are images of the inner skull intersecting WM in occipital regions, on the T1 and "flash5_reg.mgz". For comparison, a frontal view is also attached. NB: we only ran the 5 deg FLASH sequence on this subject. It's clear that something's gone wrong, and that the performance is worst in the occipital region.

This isn't something I see a lot, but it would be nice to do something about it (and /please/ don't say "Seglab" ;). I do understand that the T1 isn't any help, but is the brain extraction not used by mri_make_bem_surfaces for anything, then? Like a starting point for shrink-wrapping the inner skull on the ("synthetic" or "average") flash5? If the brain extraction is not used, then it's at least pointless to spend time tweaking recon-all.

I accept your point about the error made in less-than-perfect inner skull delineation being something we can usually live with when dealing with real data (and real sources of error). And thanks for the nomination, but note that I did say "clever" :wink:

Best,

Chris
[cid:B139A113-53AE-49B7-986C-EFBF2DD97137 at pet.auh.dk][cid:BEDC57AC-3753-4023-B0D0-2560D0C4AF52 at pet.auh.dk][cid:40128766-D9D8-41F3-A76F-1F7B54DF2082 at pet.auh.dk]

Hi Chris,

I'm sorry, but at the moment there are no better options. I have some long
term goals in the pipeline, but the big barrier for me is the BEM code.
Until we get a better BEM solver there isn't much incentive to solve this
problem (will not be publishable to say we get prettier images). If I get
some time over the holidays, I may take a look and see what i can do.

Dan

Hi Dan,

Here are images of the inner skull intersecting WM in occipital regions,
on the T1 and "flash5_reg.mgz". For comparison, a frontal view is also
attached. NB: we only ran the 5 deg FLASH sequence on this subject. It's
clear that something's gone wrong, and that the performance is worst in the
occipital region.

This isn't something I see a lot, but it would be nice to do something
about it (and /please/ don't say "Seglab" ;). I do understand that the T1
isn't any help, but is the brain extraction not used by
mri_make_bem_surfaces for anything, then? Like a starting point for
shrink-wrapping the inner skull on the ("synthetic" or "average") flash5?
If the brain extraction is not used, then it's at least pointless to spend
time tweaking recon-all.

I accept your point about the error made in less-than-perfect inner
skull delineation being something we can usually live with when dealing
with real data (and real sources of error). And thanks for the nomination,
but note that I did say "clever" :wink:

Best,

Chris

Hi Chris,

Hi Kambiz, Alex and Dan,

In the occipital regions particularly, FLASH-based BEM's seem to be
consistently "tight", and in some cases we've even seen inner
skull-WM-intersections (admittedly pathological and rare). Omitting such
points using mindist is perhaps an option, but doesn't seem very elegant.
Furthermore, the inner skull boundary is guaranteed to be wrong, which is
not a good outset for forward modelling.

This is very surprising. Usually, the inner_skull surface generated by
mri_make_bem_surfaces does an excellent job hugging the flash 5. Can
you send an image showing the surface on the flash 5? I have seen some
small clipping of the pial surface due to the sharpness at the brain
at the tip of the occipital lobe, but I have never seen it cross the
white matter.

It is also important to note that MPRAGE type sequence are virtually
useless for determining the skull boundary, as they don't provide any
contrast between cortical bone and CSF.

With regards to the inner skull boundary being wrong, in practice this
is a visualization issue, because the underlying math with which the
BEM is calculated is not sensitive to these minor changes. We would
need a new BEM solver (first, and then fix the mesh issues) to make
these small surface changes have an effect on our solutions.

@Kambiz Our experience indicates that the freesurfer-based brainmask is
pretty aggressive in the occipital region, which might have some impact on
mne_flash_bem. I can see that the brain.mgz-file is often "better" in that
it includes a hint of dura outside the pia, but it's very faint and may not
be picked up by mri_make_bem_surfaces. Perhaps the use of the -wsthresh
parameter to recon-all would help? Do you also see this occipitally?

May not, could not, whatnot... I'm just guessing, of course, since the
inner
workings of the bem creation are hidden.

I feel this is a suitable opportunity to advocate for some clever person
out
there to implement a new (and tweakable) BEM surface creation tool.
According to the FS website
(http://freesurfer.net/fswiki/mri_make_bem_surfaces), we are relying on
closed-source code written 15 years ago... Any takers? :wink:

I nominate you :wink:

HTH,
D

@Alex Could you write a few words on how the --atlas option might help
here?

/Chris
--
Christopher Bailey, MSc
MEG Engineer, MINDLab Core Experimental Facility
Center of Functionally Integrative Neuroscience (CFIN)
Aarhus University, Denmark

tel. cell: +45-2674-9927
tel. office: +45-7846-9942

Alex,

Don't you think this is less of a problem, since we don't use the pial
surface as the source space? Plus the mindist requirement throws out
points too close?

There are not any automated available tools to do this.

D

Hi Kambiz,

The pial and inner skull surfaces intersecting is not a problem given
the coarseness of our forward models.

I don't have a solution for you but I would not be so convinced that it
has low influence. If 2 vertices/triangles are too close then you can
numerical
errors with BEM models. I would try to correct for it. Isn't there a way to
use
an atlas to avoid this?

otherwise use MEG and a single layer :slight_smile:

Alex
_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/mne_analysis

The information in this e-mail is intended only for the person to whom it
is
addressed. If you believe this e-mail was sent to you in error and the
e-mail
contains patient information, please contact the Partners Compliance
HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in
error
but does not contain patient information, please contact the sender and
properly
dispose of the e-mail.

_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/mne_analysis

_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/mne_analysis

The information in this e-mail is intended only for the person to whom it
is
addressed. If you believe this e-mail was sent to you in error and the
e-mail
contains patient information, please contact the Partners Compliance
HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in
error
but does not contain patient information, please contact the sender and
properly
dispose of the e-mail.

_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/mne_analysis

_______________________________________________
Mne_analysis mailing list
Mne_analysis at nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/mne_analysis

The information in this e-mail is intended only for the person to whom it
is
addressed. If you believe this e-mail was sent to you in error and the
e-mail
contains patient information, please contact the Partners Compliance
HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in
error
but does not contain patient information, please contact the sender and
properly
dispose of the e-mail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20141105/2049f375/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ISandWM_on_flash5reg.jpg
Type: image/jpg
Size: 65846 bytes
Desc: not available
Url : http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20141105/2049f375/attachment.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ISandWM_on_T1.jpeg
Type: image/jpg
Size: 65580 bytes
Desc: not available
Url : http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20141105/2049f375/attachment-0001.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ISandWM_on_flash5reg_frontal.jpeg
Type: image/jpg
Size: 60887 bytes
Desc: not available
Url : http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20141105/2049f375/attachment-0002.jpg