Hello Bruce, I ran some tests overnight. By cranking up the memory of my virtual machine to its maximum (close to the 16GB of my actual machine), mri_compute_volume_fractions could run through at resolutions of -r 0.333 and -r 0.25 :-)
FYI, it took 13min at the default resolution of 0.5, 50min at 0.333 and 150min at 0.25, with my Intel Core i7-3770 3.4GHz processor. More importantly, at both 0.333 and 0.25, the sulcus that did get filled at the default resolution of 0.5 did get filled. But I found other smaller sulci that did not get filled even at 0.25... See RAS coordinate 19 -44 -34 in the csf images at https://www.dropbox.com/sh/tw534pw3z4v9xuh/AACth_3UesAWyRr1i5aM4xd0a?dl=0 with self-explanatory names for one example, and the attached .png images for a quick look. I will try even higher resolutions later. I can live with some procedure where I just visually make sure that this problem is not happening in my MRS voxels and do some manual correction to minimize the damage. But I wish the function was more robust. I guess that the function is filling wm from the inside-out and csf from the outside-in, and compute gm from whatever is not wm or csf, right? If it is the case, I also guess that when entering a sulcus, csf filling stops when the space between the pial surfaces defining that sulcus is too small relative to the resolution used. I further guess that this happens less, or not at all, for wm since the wm surfaces rarely get close to each other (contrarily to the pial surface). And I finally guess that filling wm volume from the inside-out and a wm+gm volume also from the inside-out would allow to compute all three tissue fractions appropriately, while avoiding the problem of tight sulci we observe. Is this series of guess correct? Do you think fooling the function by just changing names of the wm surface to pial surface would allow me to test this idea? Thanks a lot for your precious help! Sébastien -----Original Message----- From: Bruce Fischl [mailto:fis...@nmr.mgh.harvard.edu] Sent: Thursday, September 10, 2015 10:28 AM To: Sebastien Proulx Cc: freesurfer@nmr.mgh.harvard.edu Subject: RE: [Freesurfer] mri_compute_volume_fractions not filling some sulci properly there aren't really any workarounds other than using a machine with more ram. Otherwise you can reduce the resolution. Maybe try -r 0.3333 Bruce On Thu, 10 Sep 2015, Sebastien Proulx wrote: > ho yes, I meant 11.9GB. I could try to crank it up (or closer) to the > physical limit of my machine at 16GB. Would that be enough? Are there work > around, since going higher than 11.9GB might cause problem (memory swapping) > between my virtual machine and my native os. > > -----Original Message----- > From: Bruce Fischl [mailto:fis...@nmr.mgh.harvard.edu] > Sent: Thursday, September 10, 2015 10:15 AM > To: Sebastien Proulx > Cc: freesurfer@nmr.mgh.harvard.edu > Subject: RE: [Freesurfer] mri_compute_volume_fractions not filling > some sulci properly > > presumably you mean GB, not MB? That's not enough - a single distance > transform of a 256^3 volumes at 0.25 mm is 1GB of 4-8 byte voxels and > we have to hold a few in memory > > On Thu, 10 Sep 2015, Sebastien Proulx wrote: > >> 11.9 MB on a virtual Ubuntu 14.04.3 with VMware Player. >> >> -----Original Message----- >> From: Bruce Fischl [mailto:fis...@nmr.mgh.harvard.edu] >> Sent: Thursday, September 10, 2015 10:06 AM >> To: Sebastien Proulx >> Subject: Re: [Freesurfer] mri_compute_volume_fractions not filling >> some sulci properly >> >> how much ram do you have in the machine? You probably need more. Also, can >> you please cc the list on this type of email so others can answer and learn? >> >> thanks >> Bruce >> On Thu, 10 Sep 2015, Sebastien Proulx wrote: >> >>> >>> Hello Bruce ! >>> >>> >>> >>> Thanks for the tip. I tried it but it did not run through, it was killed >>> without much error message: >>> >>> -------------------------------------------------------------------- >>> - >>> - >>> ------------------------------- >>> ------------------------------------------------------- >>> >>> bass@ubuntu:/mnt/hgfs/workOnDropbox/projects/150422_decodingHRF/HRph >>> e n omenology$ mri_compute_volume_fractions -r 0.25 >>> $curSubj"_registerIdentity.dat" $curSubj_FS/mri/brain.mgz >>> $outVol"_PLUS_r" >>> >>> setting resolution = 0.250 >>> >>> arg = 4 >>> >>> reading registration file >>> ha/ha_run3_tissueFractionMasks__tmp/ha_registerIdentity.dat >>> >>> reading surface >>> /mnt/hgfs/workOnDropbox/projects/150422_decodingHRF/HRphenomenology/ >>> s >>> 2 >>> 5_HA_freesurfer/surf/lh.white >>> >>> reading surface >>> /mnt/hgfs/workOnDropbox/projects/150422_decodingHRF/HRphenomenology/ >>> s >>> 2 >>> 5_HA_freesurfer/surf/rh.white >>> >>> reading surface >>> /mnt/hgfs/workOnDropbox/projects/150422_decodingHRF/HRphenomenology/ >>> s >>> 2 >>> 5_HA_freesurfer/surf/lh.pial >>> >>> reading surface >>> /mnt/hgfs/workOnDropbox/projects/150422_decodingHRF/HRphenomenology/ >>> s >>> 2 >>> 5_HA_freesurfer/surf/rh.pial >>> >>> reading volume >>> /mnt/hgfs/workOnDropbox/projects/150422_decodingHRF/HRphenomenology/ >>> s >>> 2 >>> 5_HA_freesurfer/mri/aseg.mgz >>> >>> reading movable volume s25_HA_freesurfer/mri/brain.mgz >>> >>> filling interior of lh pial surface... >>> >>> filling interior of rh pial surface... >>> >>> filling interior of lh white matter surface... >>> >>> Killed >>> >>> -------------------------------------------------------------------- >>> - >>> - >>> ------------------------------- >>> ------------------------------------------------------- >>> >>> >>> >>> Could it have exceeded memory? I’ll rerun it, but in the meanwhile, >>> any tip to get more information for debugging? >>> >>> >>> >>> Also, here attached is a sample script, and you can get a compressed >>> version of the FS folder for one subject here >>> https://www.dropbox.com/s/s0h8flnxonskzbu/s25_HA_freesurfer.tar.gz?dl=0. >>> >>> >>> >>> >>> >>> Thanks a lot again and >>> >>> Have a very good day! >>> >>> >>> >>> Sébastien >>> >>> >>> >> >> >> 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. >> >> >> > > >
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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.
