Hi,
I get the following warning followed by error in LGI calculation:
________________________________________________________ ... remeasuring lGI value for vertex iV = 6301. It may take a few minutes. WARNING -- Problem for vertex iV = 6301, lGI value is aberrantly high (lGI=48.6447)... ...lGI computation will be stopped. This may be caused by topological defects, check mris_euler_number on the pial surface.
ERROR: compute_lgi did not create output file 'tmp-mris_compute_lgi/rh.pial_lgi.asc'! Linux antarctica 2.6.24-gentoo-r8 #1 SMP Sat May 17 14:07:35 CEST 2008 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux
recon-all exited with ERRORS at Sun May 25 09:22:16 CEST 2008 ________________________________________________________
The suggested mris_euler_number gives: ________________________________________________________ mris_euler_number rh.pial euler # = v-e+f = 2g-2: 155756 - 467454 + 311636 = -62 --> 32 holes F =2V-4: 311636 != 311512-4 (-128) 2E=3F: 934908 = 934908 (0)
total defect index = 64 ________________________________________________________
If I just rerun the LGI calculation, as suggested on the LGI web page, the calculation stops at exactly the same place. I am not sure, if I understand the execution correctly in this case, but while observing the commands, one of the first ones is removing the tmp-.... in the surf directory.
Can anybody suggest me please, how to correct the defect in that particular vertex. The topological defect repair described on the web deals with dura matter pixels removal.
Thanks in advance,
Martin
Martin,
Which version of freesurfer did you use to generate the surfaces? Because the number of topological defects in your surface (64) is very high. You may have to relaunch the surfaces (orig and pial) to get better surfaces (i.e. 0 defect).
Lgi often fail if there are defects, sometimes it will pass if you relaunch it, but if there are numerous defects the algorithm is not able to cope with it.
Marie
Quoting Martin Kavec martin.kavec@gmail.com:
Hi,
I get the following warning followed by error in LGI calculation:
... remeasuring lGI value for vertex iV = 6301. It may take a few minutes. WARNING -- Problem for vertex iV = 6301, lGI value is aberrantly high (lGI=48.6447)... ...lGI computation will be stopped. This may be caused by topological defects, check mris_euler_number on the pial surface.
ERROR: compute_lgi did not create output file 'tmp-mris_compute_lgi/rh.pial_lgi.asc'! Linux antarctica 2.6.24-gentoo-r8 #1 SMP Sat May 17 14:07:35 CEST 2008 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux
recon-all exited with ERRORS at Sun May 25 09:22:16 CEST 2008 ________________________________________________________
The suggested mris_euler_number gives: ________________________________________________________ mris_euler_number rh.pial euler # = v-e+f = 2g-2: 155756 - 467454 + 311636 = -62 --> 32 holes F =2V-4: 311636 != 311512-4 (-128) 2E=3F: 934908 = 934908 (0)
total defect index = 64 ________________________________________________________
If I just rerun the LGI calculation, as suggested on the LGI web page, the calculation stops at exactly the same place. I am not sure, if I understand the execution correctly in this case, but while observing the commands, one of the first ones is removing the tmp-.... in the surf directory.
Can anybody suggest me please, how to correct the defect in that particular vertex. The topological defect repair described on the web deals with dura matter pixels removal.
Thanks in advance,
Martin _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Hi Maria,
On Monday 09 June 2008 15:00:10 Marie Schaer wrote:
Martin,
Which version of freesurfer did you use to generate the surfaces?
with the latest one, 4.0.4
Because the number of topological defects in your surface (64) is very high. You may have to relaunch the surfaces (orig and pial) to get better surfaces (i.e. 0 defect).
Thanks, I'll do that!
Lgi often fail if there are defects, sometimes it will pass if you relaunch it, but if there are numerous defects the algorithm is not able to cope with it.
That's a nice check whether there are still any topological defects left. As you say, in more than 50% of my cases LGI fails.
Thanks,
Martin
Hello, Here is a related question prompted by this thread, perhaps based on a misconception on my part:
I was under the impression that you are guaranteed to get surfaces with an euler number of 2 under the "new" topology fixer of version 4 (which runs by default if the "old" fixer does not initially yield surfaces with an euler number of 2).
Is that not in fact the case?
thanks for clarifying, Mike H.
On Mon, 2008-06-09 at 20:32 +0200, Martin Kavec wrote:
Hi Maria,
On Monday 09 June 2008 15:00:10 Marie Schaer wrote:
Martin,
Which version of freesurfer did you use to generate the surfaces?
with the latest one, 4.0.4
Because the number of topological defects in your surface (64) is very high. You may have to relaunch the surfaces (orig and pial) to get better surfaces (i.e. 0 defect).
Thanks, I'll do that!
Lgi often fail if there are defects, sometimes it will pass if you relaunch it, but if there are numerous defects the algorithm is not able to cope with it.
That's a nice check whether there are still any topological defects left. As you say, in more than 50% of my cases LGI fails.
Thanks,
Martin _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Hi Mike,
I think it is the case. Sorry, I haven't been following this thread. Do you find situations in which the corrected surfaces have the wrong topology?
Bruce
On Mon, 9 Jun 2008, Michael Harms wrote:
Hello, Here is a related question prompted by this thread, perhaps based on a misconception on my part:
I was under the impression that you are guaranteed to get surfaces with an euler number of 2 under the "new" topology fixer of version 4 (which runs by default if the "old" fixer does not initially yield surfaces with an euler number of 2).
Is that not in fact the case?
thanks for clarifying, Mike H.
On Mon, 2008-06-09 at 20:32 +0200, Martin Kavec wrote:
Hi Maria,
On Monday 09 June 2008 15:00:10 Marie Schaer wrote:
Martin,
Which version of freesurfer did you use to generate the surfaces?
with the latest one, 4.0.4
Because the number of topological defects in your surface (64) is very high. You may have to relaunch the surfaces (orig and pial) to get better surfaces (i.e. 0 defect).
Thanks, I'll do that!
Lgi often fail if there are defects, sometimes it will pass if you relaunch it, but if there are numerous defects the algorithm is not able to cope with it.
That's a nice check whether there are still any topological defects left. As you say, in more than 50% of my cases LGI fails.
Thanks,
Martin _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
No, I don't have any examples (although we haven't been looking either). However, Martin's email regarding problems he is encountering on the LGI computation seems premised on having surfaces with topological problems even under v4 -- hence my question.... Am I mis-reading your situation Martin?
thanks, Mike H.
On Mon, 2008-06-09 at 15:03 -0400, Bruce Fischl wrote:
Hi Mike,
I think it is the case. Sorry, I haven't been following this thread. Do you find situations in which the corrected surfaces have the wrong topology?
Bruce
On Mon, 9 Jun 2008, Michael Harms wrote:
Hello, Here is a related question prompted by this thread, perhaps based on a misconception on my part:
I was under the impression that you are guaranteed to get surfaces with an euler number of 2 under the "new" topology fixer of version 4 (which runs by default if the "old" fixer does not initially yield surfaces with an euler number of 2).
Is that not in fact the case?
thanks for clarifying, Mike H.
On Mon, 2008-06-09 at 20:32 +0200, Martin Kavec wrote:
Hi Maria,
On Monday 09 June 2008 15:00:10 Marie Schaer wrote:
Martin,
Which version of freesurfer did you use to generate the surfaces?
with the latest one, 4.0.4
Because the number of topological defects in your surface (64) is very high. You may have to relaunch the surfaces (orig and pial) to get better surfaces (i.e. 0 defect).
Thanks, I'll do that!
Lgi often fail if there are defects, sometimes it will pass if you relaunch it, but if there are numerous defects the algorithm is not able to cope with it.
That's a nice check whether there are still any topological defects left. As you say, in more than 50% of my cases LGI fails.
Thanks,
Martin _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
On Monday 09 June 2008 21:14:35 Michael Harms wrote:
No, I don't have any examples (although we haven't been looking either). However, Martin's email regarding problems he is encountering on the LGI computation seems premised on having surfaces with topological problems even under v4 -- hence my question.... Am I mis-reading your situation Martin?
That's right, Mike, though I guess it may be related to something else than failure of topology fixer. It seems that the reconstruction was interrupted and restarted (recon-all -make all) during the fixer. However, upon the restart the fixer didn't start, but it seems as if the recon-all continued from the step after the fixer, which left behind some topological problems.
Would that be possible, Bruce?
Thanks,
Martin
I guess it's possible but the -make switch is designed to prevent this. Are the surfaces topologically incorrect? What is the euler number for them?
On Mon, 9 Jun 2008, Martin Kavec wrote:
On Monday 09 June 2008 21:14:35 Michael Harms wrote:
No, I don't have any examples (although we haven't been looking either). However, Martin's email regarding problems he is encountering on the LGI computation seems premised on having surfaces with topological problems even under v4 -- hence my question.... Am I mis-reading your situation Martin?
That's right, Mike, though I guess it may be related to something else than failure of topology fixer. It seems that the reconstruction was interrupted and restarted (recon-all -make all) during the fixer. However, upon the restart the fixer didn't start, but it seems as if the recon-all continued from the step after the fixer, which left behind some topological problems.
Would that be possible, Bruce?
Thanks,
Martin
On Monday 09 June 2008 21:57:36 Bruce Fischl wrote:
I guess it's possible but the -make switch is designed to prevent this. Are the surfaces topologically incorrect? What is the euler number for them?
Bruce, this depends on at which point the topology fixing was interrupted. For this thread I reported a case with 64 defects. I am running the recon-all followed by LGI once again to see whether it will pass. I will make sure that the fixer is not interrupted. I'll let you know. "-make" option may not possibly handle interruption of the fixer correctly?
Thanks,
Martin
Martin,
One thing to try is to make sure that your volumes look ok. There is a tutorial here: http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/OutputData
You don't need to download the tutorial data to follow it, just substitute the subject 'bert' which is distributed in the freesurfer/subjects directory, as the example of good output.
You can also send me the subject data in a tarball to this email drop: https://www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Nick
On Tue, 2008-06-10 at 15:42 +0200, Martin Kavec wrote:
On Monday 09 June 2008 21:57:36 Bruce Fischl wrote:
I guess it's possible but the -make switch is designed to prevent this. Are the surfaces topologically incorrect? What is the euler number for them?
Bruce, this depends on at which point the topology fixing was interrupted. For this thread I reported a case with 64 defects. I am running the recon-all followed by LGI once again to see whether it will pass. I will make sure that the fixer is not interrupted. I'll let you know. "-make" option may not possibly handle interruption of the fixer correctly?
Thanks,
Martin _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
freesurfer@nmr.mgh.harvard.edu
-
Bruce Fischl -
Marie Schaer -
Martin Kavec -
Michael Harms -
Nick Schmansky