# Pial and inner skull surfaces intersecting **URL:** \ **Category:** Mailing List Archive (read-only)\ **Tags:** list-archive\ **Created:** [November 3, 2014, 7:47pm UTC](https://mne.discourse.group/t/pial-and-inner-skull-surfaces-intersecting/872 "2014-11-03T19:47:14Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/mne/original/1X/85cc6bd2b69cb698a166dc6d880fb550510d0144.jpeg) [@system](https://mne.discourse.group/u/system)\ **Post date:** [November 3, 2014, 7:47pm UTC](https://mne.discourse.group/t/pial-and-inner-skull-surfaces-intersecting/872/1 "2014-11-03T19:47:14Z")
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](http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20141103/645a2a8d/attachment.html) ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/mne/original/1X/85cc6bd2b69cb698a166dc6d880fb550510d0144.jpeg) [@system](https://mne.discourse.group/u/system)\ **Post date:** [November 3, 2014, 8:18pm UTC](https://mne.discourse.group/t/pial-and-inner-skull-surfaces-intersecting/872/2 "2014-11-03T20:18:27Z")
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 ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/mne/original/1X/85cc6bd2b69cb698a166dc6d880fb550510d0144.jpeg) [@system](https://mne.discourse.group/u/system)\ **Post date:** [November 3, 2014, 10:15pm UTC](https://mne.discourse.group/t/pial-and-inner-skull-surfaces-intersecting/872/3 "2014-11-03T22:15:00Z")
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 🙂 Alex ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/mne/original/1X/85cc6bd2b69cb698a166dc6d880fb550510d0144.jpeg) [@system](https://mne.discourse.group/u/system)\ **Post date:** [November 4, 2014, 12:24am UTC](https://mne.discourse.group/t/pial-and-inner-skull-surfaces-intersecting/872/4 "2014-11-04T00:24:16Z")
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 ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/mne/original/1X/85cc6bd2b69cb698a166dc6d880fb550510d0144.jpeg) [@system](https://mne.discourse.group/u/system)\ **Post date:** [November 4, 2014, 9:50am UTC](https://mne.discourse.group/t/pial-and-inner-skull-surfaces-intersecting/872/5 "2014-11-04T09:50:58Z")
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](http://freesurfer.net/fswiki/mri_make_bem_surfaces)), we are relying on closed-source code written 15 years ago... Any takers? 😉 @Alex Could you write a few words on how the --atlas option might help here? /Chris ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/mne/original/1X/85cc6bd2b69cb698a166dc6d880fb550510d0144.jpeg) [@system](https://mne.discourse.group/u/system)\ **Post date:** [November 4, 2014, 9:55am UTC](https://mne.discourse.group/t/pial-and-inner-skull-surfaces-intersecting/872/6 "2014-11-04T09:55:50Z")
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 ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/mne/original/1X/85cc6bd2b69cb698a166dc6d880fb550510d0144.jpeg) [@system](https://mne.discourse.group/u/system)\ **Post date:** [November 4, 2014, 6:53pm UTC](https://mne.discourse.group/t/pial-and-inner-skull-surfaces-intersecting/872/7 "2014-11-04T18:53:22Z")
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](http://freesurfer.net/fswiki/mri_make_bem_surfaces)), we are relying on > closed-source code written 15 years ago... Any takers? 😉 I nominate you 😉 HTH, D ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/mne/original/1X/85cc6bd2b69cb698a166dc6d880fb550510d0144.jpeg) [@system](https://mne.discourse.group/u/system)\ **Post date:** [November 5, 2014, 11:15am UTC](https://mne.discourse.group/t/pial-and-inner-skull-surfaces-intersecting/872/8 "2014-11-05T11:15:06Z")
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" 😉 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] ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/mne/original/1X/85cc6bd2b69cb698a166dc6d880fb550510d0144.jpeg) [@system](https://mne.discourse.group/u/system)\ **Post date:** [November 5, 2014, 2:27pm UTC](https://mne.discourse.group/t/pial-and-inner-skull-surfaces-intersecting/872/9 "2014-11-05T14:27:46Z")
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" 😉 > > 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](http://freesurfer.net/fswiki/mri_make_bem_surfaces)), we are relying on > closed-source code written 15 years ago... Any takers? 😉 > > I nominate you 😉 > > 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 🙂 > > Alex > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > Mne\_analysis mailing list > Mne\_analysis at nmr.mgh.harvard.edu > [https://mail.nmr.mgh.harvard.edu/mailman/listinfo/mne\_analysis](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](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](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](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](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](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](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](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](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](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](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](http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20141105/2049f375/attachment-0002.jpg)