Not the first time I guessed wrong then. Unfortunately, it does not seem to be an artefactual impression of a particular 2D projection, as I see it on multiple slices in all 3 orthogonal slice dimensions.
I thought I did provide you with the dataset in previous emails, but here it is again any way (drobox link; please let me know if there is any better way): -- For the SUBJECTS_DIR --> https://www.dropbox.com/sh/akou80jxulmxxuf/AACFQ1aQKYGQH-ZbKLWc0oW3a?dl=0 -- For the mri_compute_volume_fractions outputs --> https://www.dropbox.com/sh/tw534pw3z4v9xuh/AACth_3UesAWyRr1i5aM4xd0a?dl=0 -- Sample code is attached to this email. The RAS coordinates of the rather big sulcus that is not properly filled at resolution 0.5 but is at 0.333 is [13 -48 -16]. One of the other smaller ones that are not filled even at 0.25 is at RAS [14 -57 -38]. I hope you can see and reproduce what I am talking about as much as I hope it is just a silly mistake on my side :-P Thanks a lot again for your help! Sébastien -----Original Message----- From: Bruce Fischl [mailto:fis...@nmr.mgh.harvard.edu] Sent: Friday, September 11, 2015 12:21 PM To: Sebastien Proulx Cc: freesurfer@nmr.mgh.harvard.edu Subject: RE: [Freesurfer] mri_compute_volume_fractions not filling some sulci properly Hi Sebastien that isn't how the algorithm works. If I had to guess, I would guess that what you are seeing is locations with high through-plane curvature so even though a voxel looks like it is all CSF in fact the surface cuts through it. You can see this by moving back and forth a few slices. If you upload the dataset I'll take a look, but I've run those functions on hundreds of datasets and am relatively confident they are correct (although of course bugs happen!) cheers Bruce On Fri, 11 Sep 2015, Sebastien Proulx wrote: > 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/HRp >>>> h 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. >>> >>> >>> >> >> >> >
sampleCode.sh
Description: sampleCode.sh
_______________________________________________ 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.
