Hi Bruce, If it isn't too much trouble could you send the program update? I have another set of images (2009c template) which I can contrast enhance for GM/WM regions so I can try this set of images to process along with the images I sent you.
Thanks, Ajay On Thursday, December 3, 2015, Bruce Fischl <fis...@nmr.mgh.harvard.edu <javascript:_e(%7B%7D,'cvml','fis...@nmr.mgh.harvard.edu');>> wrote: > Hi Ajay > > I have found the problem that messed up the surfaces and fixed it. We can > get you an updated mris_fix_topology that will not generate corrupted > surfaces. However, the underlying problem is huge topological defects > caused by low gray/white contrast in this data. For example in the left > hemi, there is on in the insula (e.g. voxels around 362, 213, 200 and 364, > 229, 207 and in the temporal lobe (351, 286, 282, 283, 309, 258). > > > Basically the gray/white contrast isn't high enough for us to accurately > segment the wm with our default procedures. Control points may help a bit, > but you may also need to manually edit the wm.mgz to remove the largest > defects. The easiest way to do this is to visualize them on the > lh.inflated.nofix surface with the lh.defect_labels overlaid to show you > where the defects are, then go into the volume in the wm.mgz and either add > control points or erase wm to fix things. > > Let us know if you want a new mris_fix_topology. I'm not sure it is worth > the trouble since while it will now generate topologically correct surfaces > for this dataset, they will not be geometrically acccurate in the vicinity > of the huge (>200,000 vertices!) defects. > > cheers > Bruce > > > On Wed, 2 Dec 2015, Ajay Kurani wrote: > > Hi Bruce, >> >> The template is the ICBM 2009b nonlinear template (0.5mm isotropic) >> which I downloaded from the >> McGills site ( >> http://www.bic.mni.mcgill.ca/ServicesAtlases/ICBM152NLin2009). The >> template has a >> range of values from 0-100. Then I combined the csf/wm/gm masks (derived >> from the 2009c template >> which is 1mm isotropic) and resampled to 0.5 mm to mask the brain. >> Subsequently I rescaled the >> data to have a range of 0-255 and used this output as my input T1 for >> Freesurfer. Thank you very >> much for looking into this matter, it is much appreciated! I will look >> at the file as you >> suggested. >> >> Sincerely, >> Ajay >> >> On Tue, Dec 1, 2015 at 7:55 AM, Bruce Fischl <fis...@nmr.mgh.harvard.edu> >> wrote: >> Hi Ajay >> >> can you explain your entire processing stream, including the >> details of the >> acquisition? What sequence/coil/scanner was used? You could fix >> your problem by looking >> at the defects on the inflated.nofix, overlaying >> lh.defect_labels on it to see where they are, then figuring out >> what caused them in the >> volume. However, there is a bug in mris_fix_topology that only >> comes up when it >> encounters a large enough defect (with nvertices>200,000). The code >> tries to avoid >> running it's normal genetic algorithm as it would take days (or >> weeks) to finish, since >> it scales with the square of the number of vertices. I haven't >> figured out what is >> going wrong yet, but hopefully will have a code fix soon. >> >> cheers >> Bruce >> >> >> On Tue, 1 Dec 2015, Ajay Kurani wrote: >> >> Hi Bruce, When looking at my top slices in brain ask I >> noticed that the >> gray/white matter shows but the darker areas surrounding it >> are not present >> (this usually goes to the edge of the brain). Could the >> large defects be a >> result of having masked this out on the input file? I >> multiplied the >> template with the GM/WM/CSF masks they provided to get the >> brain extracted >> so I only see this missing in the very top few slices of the >> brain. >> >> Thanks, >> Ajay >> >> On Tuesday, December 1, 2015, Bruce Fischl < >> fis...@nmr.mgh.harvard.edu> >> wrote: >> Hi Falk >> >> I don't think you need to rerun the qsphere. I'm pretty >> sure >> this is a bug in mris_fix_topology for giant defects, >> but >> haven't finished tracking it down yet >> >> cheers >> Bruce >> >> >> On Tue, 1 Dec 2015, Falk Lüsebrink wrote: >> >> >> Hi Ajay, >> >> >> >> you should >> >> >> >> cp ?h.orig.nofix ?h.orig >> >> cp ?h.inflated.nofix ?h.inflated >> >> >> >> with ? being l or r depending your hemisphere. >> After the fixing stage the >> surfaces got damaged somehow, therefore you have >> to >> recreate it them. I’m >> not entirely sure about the qsphere. Probably you >> have to run the -qsphere >> stage again also. >> >> >> >> Best, >> >> Falk >> >> >> >> >> >> Von: Ajay Kurani [mailto:dr.ajay.kur...@gmail.com >> ] >> Gesendet: Montag, 30. November 2015 21:50 >> An: Falk Lüsebrink >> Cc: Freesurfer support list; Bruce Fischl >> Betreff: Re: [Freesurfer] Freesurfer 6.0 - >> Autorecon2 failure >> (mris_euler_number) using high res (0.5mm >> isotropic) T1 image >> >> >> >> Hi Falk, >> >> I used the command and got the following error: >> >> Command: ris_topo_fixer -mgz -warning -seed 1234 >> ICBM lh >> mris_topo_fixer -mgz -warning -seed 1234 ICBM lh >> INFO: assuming .mgz format >> setting seed for random number genererator to 1234 >> reading >> >> inputsurface/home/imuser/Downloads/mni_icbm152_nlin_sym_09b_nifti/mni_icbm152_n >> lin_sym >> _09b/ICBM/surf/lh.orig... >> >> mrisFindNeighbors:/home/imuser/Downloads/mni_icbm152_nlin_sym_09b_nifti/mn >> i_icbm152_nlin_sym >> _09b/ICBM/surf/lh.orig: face[46196].v[0] = 24215, >> but face 46196 not in >> vertex 24215 face list >> >> mris_topo_fixer -mgz -warning -seed 1234 ICBM rh >> INFO: assuming .mgz format >> setting seed for random number genererator to 1234 >> reading >> >> inputsurface/home/imuser/Downloads/mni_icbm152_nlin_sym_09b_nifti/mni_icbm152_n >> lin_sym >> _09b/ICBM/surf/rh.orig... >> >> mrisFindNeighbors:/home/imuser/Downloads/mni_icbm152_nlin_sym_09b_nifti/mn >> i_icbm152_nlin_sym >> _09b/ICBM/surf/rh.orig: face[35822].v[2] = 18903, >> but face 35822 not in >> vertex 18903 face list >> >> Any suggestions would be appreciated. >> >> Thanks, >> >> Ajay >> >> >> >> On Mon, Nov 30, 2015 at 2:41 AM, Falk Lüsebrink >> <falk.luesebr...@ovgu.de> >> wrote: >> >> Hi Ajay, >> >> I ran into the same error processing hires data a >> while ago using a nightly >> build of centos 6 with the hires flag only. Disk >> space or alike wasn't an >> issue. I ran mris_topo_fixer instead of >> mris_fix_topology to get working >> surfaces. >> >> Best, >> Falk >> >> -----Ursprüngliche Nachricht----- >> Von: freesurfer-boun...@nmr.mgh.harvard.edu >> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] >> Im >> Auftrag von Bruce Fischl >> Gesendet: Sonntag, 29. November 2015 22:48 >> An: Freesurfer support list >> Betreff: Re: [Freesurfer] Freesurfer 6.0 - >> Autorecon2 failure >> (mris_euler_number) using high res (0.5mm >> isotropic) T1 image >> >> Hi Ajay >> >> are you sure you didn't run out of disk space? >> That >> error is a sanity check >> on the surfaces that should never occur >> >> cheers >> Bruce >> >> On Sun, 29 Nov 2015, Ajay >> Kurani wrote: >> >> > Hello Freesurfer experts, >> > I am trying to run Freesurfer 6.0 beta >> (downloaded 10/15/15 >> > version) with the -hires flag to process an MNI >> template image which >> > is 0.5mm isotropic. Stage 1 ran well and on >> stage 2 there is an error >> > during >> > pocessing: >> > >> > Command run: >> > recon-all -s ICBM -autorecon2 -openmp 8 -3T >> -hires -expert expert.opts >> > >> > I supplied a skull stripped brain which was nu >> corrected and so I used >> > the T1.mgz and copied it to brainmask.mgz and >> nu.mgz in autorecon1 >> > stage. I then ran autorecon2 and it was working >> well until I was at >> > the -fix stage and ran into the following error: >> > >> > >> > Error: >> > mris_euler_number ./surf/lh.orig >> > mrisFindNeighbors: ./surf/lh.orig: >> face[46196].v[0] = 24215, but face >> > 46196 not in vertex 24215 face list >> > >> > >> > >> > I am not sure if this is due to the fact that we >> have a very high >> > resolution image (template) and if there are any >> modifications needed >> > aside from the hires flag. Are there any >> suggestions you have? >> > >> > Thanks, >> > Ajay >> > >> > >> >> >> >> >> >> >> >> 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.
