Hi Freesurfers,
I have a couple of questions regarding WM segmentation. My dataset is a large healthy sample of children and adolescents (8-19 years old). Freesurfer 4.01 for linux has been used for processing.
Firstly, in about 20% of my subjects there are some voxels segmented as WM isthmuscingulate located between thalamus and pallidum, seemingly not connected to the rest of WM isthmuscingulate located more posteriorly. See pictures for illustrations (marked with the cursor).
Secondly, in many of my subjects (about 50%) a few voxels (usually fewer than 10) above hippocampus, next to ventralDC are segmented as parahippocampal WM. See cursor in last picture for an illustration.
Does anyone have any experice with these problems or any suggestions on how do deal with them? Both problems could probably be solved with manual segmentation, but it would be very time consuming.
Best regards, Christian
Hi Christian, these are both bugs. I've fixed both of them. The fix will be available in the next release, but if you give me your platform details, I can get you a binary to test out.
doug
c.k.tamnes@psykologi.uio.no wrote:
Hi Freesurfers,
I have a couple of questions regarding WM segmentation. My dataset is a large healthy sample of children and adolescents (8-19 years old). Freesurfer 4.01 for linux has been used for processing.
Firstly, in about 20% of my subjects there are some voxels segmented as WM isthmuscingulate located between thalamus and pallidum, seemingly not connected to the rest of WM isthmuscingulate located more posteriorly. See pictures for illustrations (marked with the cursor).
Secondly, in many of my subjects (about 50%) a few voxels (usually fewer than 10) above hippocampus, next to ventralDC are segmented as parahippocampal WM. See cursor in last picture for an illustration.
Does anyone have any experice with these problems or any suggestions on how do deal with them? Both problems could probably be solved with manual segmentation, but it would be very time consuming.
Best regards, Christian
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Dear freesurfers,
I get an error message while running recon-all on two on my subjects (on both version 4.02 and 4.05 on a CentOS linux station). It seems to be the same error that is described earlier this summer by Sky Raptentsetsang.
The error message is: MrisComputeWhiteVolume: src (14, 721, 277) maps to src (14, 721, 277) - OBB
Recon-all does finish, but it takes a lot longer than usual. The error message is repeated thousands of times and the error log is massive as Sky also describes below.
Is there some way to fix these errors?
best regards, Christian Tamnes
Hi Sky,
this means that the aseg voxel that corresponds to the interior of the ?h.white surface has been computed to be outside the aseg volume, which definitely means something is wrong. Can you tar up one subject like this (without the 6G of error messages!) and we'll take a look?
thanks, Bruce
On Fri, 27 Jun 2008, Sky Raptentsetsang wrote:
This is a very strange and amusing issue that is occurring with a population of subjects that I ran previously on version 3.0.5 and am now rerunning on version 4.0.4. The subjects are finishing recon-all with no errors after substantially longer than usual, because the mri_segstats script appears to be looking for WM volumes that are not there, and the error is printed out over a 106 million times but still manages to finish recon-all....amazing. Below I have pasted the lines before the repeating errors. In blue is the repeating portion. In short these files seem to be anywhere from 3GB to 6GB and is managing to filling up our memory resources. :)
Is there a flag that I can invoke that will skip this seemingly needless error loop?
#-------------------------------------------- [EMAIL PROTECTED] Inflation2 rh Wed Jun 25 22:25:25 PDT 2008 /cind/00/FCDv4/Freesurfer/subjects/FCD009-1/scripts
mris_inflate ../surf/rh.smoothwm ../surf/rh.inflated
avg radius = 43.6 mm, total surface area = 69264 mm^2 writing inflated surface to ../surf/rh.inflated writing sulcal depths to ../surf/rh.sulc step 030: RMS=0.029 (target=0.015) step 060: RMS=0.016 (target=0.015) inflation complete. inflation took 1.5 minutes
mris_curvature -thresh .999 -n -a 5 -w -distances 10 10 ../surf/rh.inflated
normalizing curvature values. averaging curvature patterns 5 times. sampling 10 neighbors out to a distance of 10 mm 276 vertices thresholded to be in k1 ~ [-0.22 0.26], k2 ~ [-0.11 0.05] total integrated curvature = 0.565*4pi (7.101) --> 0 handles ICI = 1.4, FI = 7.8, variation=135.859 144 vertices thresholded to be in [-0.01 0.02] writing Gaussian curvature to ../surf/rh.inflated.K...thresholding curvature at 99.90% le vel curvature mean = 0.000, std = 0.001 122 vertices thresholded to be in [-0.13 0.12] done. writing mean curvature to ../surf/rh.inflated.H...curvature mean = -0.018, std = 0.022 done. #-------------------------------------------- [EMAIL PROTECTED] ASeg Stats Wed Jun 25 22:29:01 PDT 2008 /cind/00/FCDv4/Freesurfer/subjects/FCD009-1
mri_segstats --seg mri/aseg.mgz --sum stats/aseg.stats --pv mri/norm.mgz --excludeid 0 - -brain-vol-from-seg --brainmask mri/brainmask.mgz --in mri/norm.mgz --in-intensity-name n orm --in-intensity-units MR --etiv --subject FCD009-1 --surf-wm-vol --ctab /opt/freesurfe r4.0.4/ASegStatsLUT.txt
MRIScomputeWhiteVolume: src (0, 279, 274) maps to (104, -12, 235) - OOB atlas_icv = 1.19127e+06 Loading mri/aseg.mgz Getting Cerebral WM volumes from surface No such file or directory MRIScomputeWhiteVolume: src (0, 279, 275) maps to (104, -12, 235) - OOB No such file or directory MRIScomputeWhiteVolume: src (0, 280, 273) maps to (104, -13, 236) - OOB No such file or directory MRIScomputeWhiteVolume: src (0, 280, 274) maps to (104, -12, 236) - OOB No such file or directory
Hopefully you can save us a HUGE amount of disk space and maybe get a laugh out of it as we did.
Sky
Christian,
Updated mri_segstats and mris_wm_volume executables for centos 32/64bit can be downloaded from here:
ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/fsdev/nicks/stable
Nick
On Wed, 2008-08-20 at 10:57 +0200, c.k.tamnes@psykologi.uio.no wrote:
Dear freesurfers,
I get an error message while running recon-all on two on my subjects (on both version 4.02 and 4.05 on a CentOS linux station). It seems to be the same error that is described earlier this summer by Sky Raptentsetsang.
The error message is: MrisComputeWhiteVolume: src (14, 721, 277) maps to src (14, 721, 277) - OBB
Recon-all does finish, but it takes a lot longer than usual. The error message is repeated thousands of times and the error log is massive as Sky also describes below.
Is there some way to fix these errors?
best regards, Christian Tamnes
Hi Sky,
this means that the aseg voxel that corresponds to the interior of the ?h.white surface has been computed to be outside the aseg volume, which definitely means something is wrong. Can you tar up one subject like this (without the 6G of error messages!) and we'll take a look?
thanks, Bruce
On Fri, 27 Jun 2008, Sky Raptentsetsang wrote:
This is a very strange and amusing issue that is occurring with a population of subjects that I ran previously on version 3.0.5 and am now rerunning on version 4.0.4. The subjects are finishing recon-all with no errors after substantially longer than usual, because the mri_segstats script appears to be looking for WM volumes that are not there, and the error is printed out over a 106 million times but still manages to finish recon-all....amazing. Below I have pasted the lines before the repeating errors. In blue is the repeating portion. In short these files seem to be anywhere from 3GB to 6GB and is managing to filling up our memory resources. :)
Is there a flag that I can invoke that will skip this seemingly needless error loop?
#-------------------------------------------- [EMAIL PROTECTED] Inflation2 rh Wed Jun 25 22:25:25 PDT 2008 /cind/00/FCDv4/Freesurfer/subjects/FCD009-1/scripts
mris_inflate ../surf/rh.smoothwm ../surf/rh.inflated
avg radius = 43.6 mm, total surface area = 69264 mm^2 writing inflated surface to ../surf/rh.inflated writing sulcal depths to ../surf/rh.sulc step 030: RMS=0.029 (target=0.015) step 060: RMS=0.016 (target=0.015) inflation complete. inflation took 1.5 minutes
mris_curvature -thresh .999 -n -a 5 -w -distances 10 10 ../surf/rh.inflated
normalizing curvature values. averaging curvature patterns 5 times. sampling 10 neighbors out to a distance of 10 mm 276 vertices thresholded to be in k1 ~ [-0.22 0.26], k2 ~ [-0.11 0.05] total integrated curvature = 0.565*4pi (7.101) --> 0 handles ICI = 1.4, FI = 7.8, variation=135.859 144 vertices thresholded to be in [-0.01 0.02] writing Gaussian curvature to ../surf/rh.inflated.K...thresholding curvature at 99.90% le vel curvature mean = 0.000, std = 0.001 122 vertices thresholded to be in [-0.13 0.12] done. writing mean curvature to ../surf/rh.inflated.H...curvature mean = -0.018, std = 0.022 done. #-------------------------------------------- [EMAIL PROTECTED] ASeg Stats Wed Jun 25 22:29:01 PDT 2008 /cind/00/FCDv4/Freesurfer/subjects/FCD009-1
mri_segstats --seg mri/aseg.mgz --sum stats/aseg.stats --pv mri/norm.mgz --excludeid 0 - -brain-vol-from-seg --brainmask mri/brainmask.mgz --in mri/norm.mgz --in-intensity-name n orm --in-intensity-units MR --etiv --subject FCD009-1 --surf-wm-vol --ctab /opt/freesurfe r4.0.4/ASegStatsLUT.txt
MRIScomputeWhiteVolume: src (0, 279, 274) maps to (104, -12, 235) - OOB atlas_icv = 1.19127e+06 Loading mri/aseg.mgz Getting Cerebral WM volumes from surface No such file or directory MRIScomputeWhiteVolume: src (0, 279, 275) maps to (104, -12, 235) - OOB No such file or directory MRIScomputeWhiteVolume: src (0, 280, 273) maps to (104, -13, 236) - OOB No such file or directory MRIScomputeWhiteVolume: src (0, 280, 274) maps to (104, -12, 236) - OOB No such file or directory
Hopefully you can save us a HUGE amount of disk space and maybe get a laugh out of it as we did.
Sky
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Hello,
I'm having an issue with tksurfer - whenever I try to load a surface, the display only shows scattered points (with the vaguely recognizable shape of the intended surface). I've noticed the following error that may be related to this:
libGL error: open DRM failed (Operation not permitted) libGL error: reverting to indirect rendering
I'm using the freesurfer-Linux-centos4_x86_64-stable-pub-v3.0.2 version. Any ideas as to what is going on?
Thank you very much for your help.
Best,
Joao Pereira
Hi Joao,
is this true for any subject or only this one?
cheers, Bruce On Wed, 20 Aug 2008, Joao Pereira wrote:
Hello,
I'm having an issue with tksurfer - whenever I try to load a surface, the display only shows scattered points (with the vaguely recognizable shape of the intended surface). I've noticed the following error that may be related to this:
libGL error: open DRM failed (Operation not permitted) libGL error: reverting to indirect rendering
I'm using the freesurfer-Linux-centos4_x86_64-stable-pub-v3.0.2 version. Any ideas as to what is going on?
Thank you very much for your help.
Best,
Joao Pereira
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Joao,
Make sure your graphics driver is up to date. Also make sure that 'glxgears' runs properly on your system. That exercises the OpenGL X driver.
Nick
On Wed, 2008-08-20 at 16:37 +0100, Joao Pereira wrote:
Hello,
I'm having an issue with tksurfer - whenever I try to load a surface, the display only shows scattered points (with the vaguely recognizable shape of the intended surface). I've noticed the following error that may be related to this:
libGL error: open DRM failed (Operation not permitted) libGL error: reverting to indirect rendering
I'm using the freesurfer-Linux-centos4_x86_64-stable-pub-v3.0.2 version. Any ideas as to what is going on?
Thank you very much for your help.
Best,
Joao Pereira
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
freesurfer@nmr.mgh.harvard.edu