Hello,
I am getting a bug in head model estimation computed by OpenMEEG toolbox:
An outlier apears in all the rows of the leadfield matrix:
Do you know why it happens and how to avoid it???
Thanks in advance.
All the best,
Eduardo
Hi Eduardo,
Welcome to the Brainstorm forum!
My best guess is that that point might be inside the skull layer (i.e. outside the inner-skull surface) and should be corrected. You can check that by visualizing the cortex and inner skull surface. Pick a visible color for the cortex and put no transparency on the inner-skull surface. If any cortex points are outside the inner-skull, they would be visible. If that's the case, I'm not sure what's the easiest way to correct it, but you could for example export the cortex surface to Matlab, edit it and import it back into Brainstorm.
Cheers,
Marc
@Alexandre @papadop There is nothing in OpenMEEG that checks whether the sources are inside one of the layers?
Hi Marc,
Thanks for your quick reply.
I checked the point and you are right, the point is outside of inner-skull surface, therefore I edited it and I set it inside the inner-skull:
Now the estimation of the head model is coming out without outliers:
Then, the problem could be releated to the process of reducing size of cortex surface, I need to go deeper into this point.
Thanks again for your useful comment!!!
All the Best,
Eduardo.
Hi Francois,
At least from Brainstorm GUI there are not many options for OpenMEEG performance:
Maybe an option to check whether all cortical vertices are inside the inner-skull surface could be added in the future version of Brainstorm GUI.
All the Best,
Eduardo
therefore I edited it and I set it inside the inner-skull:
How did you modify the coordinates of this point?
Is this with the default surfaces of the MNI ICBM152 template?
If so, we should fix the surface in the Brainstorm distribution, maybe using the surface you modified.
Hi Francois,
I was using the MNI ICBM152 template, which comes with one vertice outside the inner-skull surface, in fact, also the ICBM152_2016c template comes with same bug:
I just fix the vertice coordinates by hand, pushing it inside the inner-skull surface. Nevertheless, I think that better than fixing this template, which is also important, a control function could be added before to estimate the head model for a good leadfield estimation and time saving.
Thanks for your time and support.
All the Best,
Eduardo.
Trying to fix this in OpenMEEG
it's still work in progress...
I don't know if brainstorm has tools to check and avoid this.
Alex
I fixed the issues reported here with the three commits below:
https://github.com/brainstorm-tools/brainstorm3/commit/f72eb52d97869877900168d68d215955f85d121f
The new menu "Force inside skull" highlights the vertices that are outside of the inner skull and creates a new fixed surface.
To fix the existing (Default anatomy) folders in the Brainstorm database, you can right-click on the (Default anatomy) folder > Use template > ICBM152 (after updating Brainstorm)
I added a new template ICBM152_2019 with the full version of this fixed template.
@egmoreira80 Thanks for spotting this issue!
Can you update Brainstorm and make sure these fixes do the job?
Hi Francois,
I updated my Brainstorm and now it is fixed:
and the results for leadfield estimation are consistent with initial values:
Thanks for your great job!!!
All the Best,
Eduardo.
Hi Alexandre,
Thanks for your reply, your group is also doing an amazing job!.
We met during last OHBM at that time I was Pedro Valdes Sosa postdoctoral fellow.
As you know, obtaining a good estimate of the head model is essential for the good performance of all inverse solution methods.
All the Best,
Eduardo.
Hi François,
Force inside skull centers the surfaces to the best fitting sphere, but bst_openmeeg doesn't when it checks. Unfortunately, this inconsistency leads to bst_openmeeg detecting one point outside the inner skull with the 2019 ICBM template, while force inside skull says they're already inside.
Cheers,
Marc
I checked again, and OpenMEEG doesn't complain on my Win10 laptop.
Are you sure this is really the correct version of the ICBM152 template your are using?
Delete your ICBM152*.zip files from $HOME/.brainstorm/defaults/anatomy to make sure it is using the correct one.
Do you get an error from OpenMEEG?
Can you report it here?
What operating system are you working with?
Could you try if you get the same error on a different windows 10? (the build of OpenMEEG might be different)
The test on Brainstorm relies on inpolyhd, but maybe this is not strict enough of a test:
https://github.com/brainstorm-tools/brainstorm3/blob/master/toolbox/anatomy/tess_force_envelope.m#L56
Would you have any alternative suggestion instead of using this function?
Thanks François.
Yes, I double checked it was the corrected template. OpenMEEG doesn't give an error, I really think it's inpolyhd that gives me a wrong answer in this case. Strange about the inconsistency across systems though. I'm on Ubuntu 18, Matlab 2018b.
I have previously used this function instead:
I used it in this case and it gives the correct answer on my system regardless of centering or not the coordinates. I haven't done extensive tests comparing it to inpolyhd though.
OpenMEEG doesn't give an error
Then how do you know that it is inside the skull for OpenMEEG?
Because you found very different values for this specific vertex in the Gain matrix?
Strange about the inconsistency across systems though. I'm on Ubuntu 18, Matlab 2018b.
What is inconsistent? What do you observe that is different from my version?
I used it in this case and it gives the correct answer on my system regardless of centering or not the coordinates. I haven't done extensive tests comparing it to inpolyhd though.
I remember testing these functions (and many more) many years ago. I'm not sure why I kept this inpolyhd.
Have you simply tried to replace inpolyhd with inpolyhedron in tess_force_envelope.m?
How does it compare in terms of execution speed?
Does it move a lot of vertices when ran on the ICBM152 template, or just the one you wanted to move?
Let me try to clarify: on my system, one inside vertex on the fixed 2019 template is incorrectly detected as outside by inpolyhd before openmeeg is called. (You said that didn't happen on your Windows 10, so that's what's inconsistent.)
However, when using "force inside skull", the vertices are "re-centered" before calling inpolyhd. In that case, I get the correct answer that all vertices are inside.
Have you simply tried to replace inpolyhd with inpolyhedron in tess_force_envelope.m?
Yes, and it gives the correct answer whether re-centering or not.
How does it compare in terms of execution speed?
inpolyhedron seems 35-40% faster on my system.
Does it move a lot of vertices when ran on the ICBM152 template, or just the one you wanted to move?
None: it correctly detects them all as inside.
I replaced inpolyhd with inpolyedron in tess_force_envelope, and then used it on the a cortex surface I slightly shifted outside of the skull:
Inpolyhd: (expected result)
iVertOut = find(~inpolyhd(vCortex, vInner, EnvMat.Faces));
Inpolyhedron: (???)
iVertOut = find(~inpolyhedron(EnvMat.Faces, vInner, vCortex))
Any idea what I'm doing wrong?
If you think inpolyhedron is much better, can you suggest code modifications for tess_force_envelope.m, tess_bem.m, bst_openmeeg.m and bst_headmodeler.m to replace inpolyhd with inpolyhedron? The results should remain almost exactly the same, we don't want to change the behavior of these functions for any other reason than fixing the inconsistencies observed across operating systems.
inpolyhedron seems 35-40% faster on my system.
They run exactly at the same speed on my laptop.
Yeah, I had to use their flag: , 'FlipNormals', true, otherwise it was giving the opposite in/out.
I don't have time right now, but if we don't switch function, at the very least, the check when using openmeeg should be identical as in force envelope, i.e. center the vertices, so that the behavior is consistent across functions.
I tried with FlipNormals but could not get any better results... (but I didn't insist too much, so I probably made some mistakes)
Anyway, if centering the vertices in bst_openmeeg is enough to fix the inconsistency, let's simply do this for now.
Does this fix work for you?
Yup, looks good. Thanks