And is that area outside of the brain not present in the wm.mgz or filled.mgz on the good output? The orig.nofix should hug the boundary of the wm.mgz doug
On 08/26/2014 04:53 PM, Vincent Beliveau wrote: > > I've attached ?h.orig.nofix for both recon with and without wm error. > They are similar to ?h.orig in the sense that the one from the recon > with wm error misclassifies part of dura as wm. Interestingly when > looking at ?h.orig.nofix from the recon with error overlayed on > brain.finalsurfs.mgz of the recon without error I can see a few voxels > in the misclassified dura are removed from brain.finalsurfs, although > not all. Could this small difference explain why we see the wm error > in one case and not the other? > > On 26.08.2014 20:24, Douglas N Greve wrote: > >> how about the ?h.orig.nofix >> >> On 08/26/2014 10:45 AM, Vincent Beliveau wrote: >>> Dear Sebastian, Attached is the *.orig for both recon (green being >>> the one with wm error and red being the one with error). >>> Unfortunately they are not identical; a section of the dura is >>> misclassified as wm in the red delineation. As mentionned before, >>> both orig.mgz are numerically identical in that area. As I also >>> mentionned before, the recon were ran on the same machine, same os, >>> same binaries. You expressed some confusion as to what were trying >>> to achieve. We want to figure out why, given numerically almost >>> identical inputs, Freesurfer correctly delineates wm in one case but >>> fails in the other. Unfortunately this type of error appears to be >>> systematic in some of our data. Vincent. On 26.08.2014 16:22, >>> Sebastian Moeller wrote: >>>> Hi Vincent hi Melanie, please show us the *.orig surfaces on the >>>> critical slice. I predict that these will be identical, If so you >>>> can ignore everything except brain.finalsurfs.mgz. Are the two >>>> versions of this file identical around the area of mis-classified >>>> tissue? I predict that there will be a slight difference. Also if >>>> you take Vincent’s brain.finalsurf.mgz and put this into Melanie’s >>>> recon and redo the generation of the wm surfaces I predict that now >>>> Melinie’s version will show the same problem. On Aug 26, 2014, at >>>> 16:08 , Melanie Ganz <[email protected] >>>> <mailto:[email protected]>[email protected]>> wrote: >>>>> Hi Sebastian, I'm afraid that the problem is slightly more >>>>> complicated. The inputs to recon-all are almost numerically >>>>> identical (to the 4th decimal); when converted to orig.mgz, all >>>>> voxels which are not identical (about only 700 of all the 1677216 >>>>> voxels) vary only by 1 due to rounding. Their distribution is >>>>> sparse and do not overlap with the white matter errors. Can such a >>>>> small source of variation give this kind of difference? Ok, >>>>> Freesurfer uses some random initialization, however as far as I >>>>> know the seed is not random and set to 1234. We have looked at all >>>>> the outputs created before wm.mgz >>>>> (orig,nu,T1,brainmask,norm,nu_noneck,aseg,brain,wm,filled) and the >>>>> only one showing a differences overlapping the wm errors is >>>>> filled.mgz; >>>> I think the filled.mgz is changed during the generation of the wm >>>> surfaces (at least temporarily)... >>>>> in all the other images the differences are minor. >>>> Are you running the analyses on exactly the same machine and get >>>> different results or are you using two “identical” computers? I ask >>>> as I think there is a paper about the reproducibility of freesurfer >>>> reconstructions >>>> (http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0038234) >>>> >>>> with different freesurfer versions or different hardware/operating >>>> systems that might explain a bit of systematic variance. But I >>>> guess I still do not exactly understand what the problem is that >>>> you want to solve here …. Best Regards Sebastian >>>>> Thanks. Vincent. P.S.: I keep sending the mails, since Vincent has >>>>> problems posting to the list. ;-) On 26-08-2014 15:32, Sebastian >>>>> Moeller wrote: >>>>>> Hi Melanie, I guess your post got me confused then, since you did >>>>>> not really explain what your figure shows. With the information >>>>>> from this post I assume that red and yellow are wm and pia >>>>>> respectively from and recon and blue and green are from the >>>>>> second. On Aug 26, 2014, at 15:16 , Melanie Ganz >>>>>> <[email protected] >>>>>> <mailto:[email protected]>[email protected]>> wrote: >>>>>>> Hi Sebastian, it is clear to us how to fix this, this is not the >>>>>>> issue here. The issue is that my colleague and I ran the same >>>>>>> image, he used the original dicom as source and I a nifti >>>>>>> version prepared for other processing, >>>>>> Plain conversion of dicim to nifty or further processing? >>>>>>> and we get very different results! And this even thought the >>>>>>> actual images vary quite a bit. >>>>>> Well some processes use random seeds, so if these differs between >>>>>> reckons and the intensity of the dura is close to threshold for >>>>>> skull stripping you got your problem right there. Have a look at >>>>>> the orig surfaces, if those do not show wrong wm-voxels in the >>>>>> dura its the refinement process later on that introduces this >>>>>> problem. You state in a later map that there are differences in >>>>>> brain mask.mgz, which I believe to be the input for the volume to >>>>>> use for image gradient based surface adjustments (actually brain >>>>>> mask.mgz should be a start of a chain that ends in >>>>>> brain.finalsurfs.mgz I believe). So from my understanding this >>>>>> makes all sense. But unfortunately is not going to help you... >>>>>>> So thanks for the input, but this does not explain our >>>>>>> processing difference. Especially not, since the wm.mgz files >>>>>>> are basically identical. >>>>>> Does not matter the wm.mgz gets turned into filled.mgz but these >>>>>> only define the orig surfaces lh.orig and rh.orig not the *.wm… I >>>>>> think that >>>>>> https://surfer.nmr.mgh.harvard.edu/fswiki/ReconAllDevTablegives a >>>>>> decent overview of the inputs and outputs of all freesurfer >>>>>> processing stages, (I guess you know that already). Best Regards >>>>>> Sebastian >>>>>>> Cheers, Melanie On 26-08-2014 15:12, Sebastian Moeller wrote: >>>>>>>> Hi Melanie, this looks like your brain mask contains bright >>>>>>>> dura mater that gets mis-classified as white matter, this I >>>>>>>> assumed happened n the skull stripping step, If you edit the >>>>>>>> brain mask to exclude the offending dura you should be fine (or >>>>>>>> alternatively it might help to edit the wm.mgz so the voxels >>>>>>>> contain a value of 1 where the offending dura sits, but I am >>>>>>>> not sure that this will work) and then re-run the following >>>>>>>> steps of the recon. So have a look at brainmask.mgz. I assume >>>>>>>> with image you mean volume? I believe this really is showing >>>>>>>> that you might need to play with the skull-stripping process a >>>>>>>> bit to get rid of the sure better (or with your sequence so you >>>>>>>> get less signal from those structures in the first place ;) ) >>>>>>>> Best Regards Sebastian On Aug 26, 2014, at 13:50 , Melanie Ganz >>>>>>>> wrote: >>>>>>>>> Dear Freesurfer community, We've encountered a strange >>>>>>>>> situation where the pial and wm surface delineation is >>>>>>>>> successful for one image but contains wm (and subsequent pial) >>>>>>>>> errors for another, almost identical structural image (see >>>>>>>>> attached image, red and yellow are for the successful surface >>>>>>>>> and blue and green are for the failed one). We've tried to >>>>>>>>> identify the source for this discrepancy but I'm at a loss. >>>>>>>>> All voxels of the original input images are identical to the >>>>>>>>> 4th decimal and when converted to orig.mgz only a few voxels >>>>>>>>> appear to be different due to rounding, none of which overlap >>>>>>>>> with the wm surface errors. Both images were processed on the >>>>>>>>> same setup (hardware and software, Freesurfer stable 5.3). >>>>>>>>> Unfortunately, this error is quite systematic in my dataset; >>>>>>>>> about 10% of the images show this type of error. Any >>>>>>>>> suggestions on how to investigate this? I've uploaded example >>>>>>>>> of good and bad at recon >>>>>>>>> ftp://surfer.nmr.mgh.harvard.edu/transfer/incoming/failed_wm_recon.tar.gz >>>>>>>>> >>>>>>>>> in case you'd like to have a closer look. Thanks for your >>>>>>>>> help. Vincent and Melanie >>>>>>>>> _______________________________________________ Freesurfer >>>>>>>>> mailing list [email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> 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. >>>>>>>> _______________________________________________ Freesurfer >>>>>>>> mailing list [email protected] >>>>>>>> <mailto:[email protected]> >>>>>>>> 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. >>>>>>> -- Melanie Ganz, MSc, Ph.D. Neurobiology Research Unit >>>>>>> University of Copenhagen Rigshospitalet Rockefeller Center >>>>>>> Juliane Maries Vej 28/30, 3. DK-2100 Copenhagen Denmark phone: >>>>>>> +45 3545 6718 e-mail: [email protected] >>>>>>> <mailto:[email protected]> web: >>>>>>> http://melanie.clausundmelanie.de/ >>>>>>> _______________________________________________ Freesurfer >>>>>>> mailing list [email protected] >>>>>>> <mailto:[email protected]> >>>>>>> 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. >>>>>> _______________________________________________ Freesurfer >>>>>> mailing list [email protected] >>>>>> <mailto:[email protected]> >>>>>> 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. >>>>> -- Melanie Ganz, MSc, Ph.D. Neurobiology Research Unit University >>>>> of Copenhagen Rigshospitalet Rockefeller Center Juliane Maries Vej >>>>> 28/30, 3. DK-2100 Copenhagen Denmark phone: +45 3545 6718 e-mail: >>>>> [email protected] <mailto:[email protected]> >>>>> [email protected]> web: http://melanie.clausundmelanie.de/ >>>>> _______________________________________________ Freesurfer mailing >>>>> list [email protected] >>>>> <mailto:[email protected]> >>>>> 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. >>> _______________________________________________ Freesurfer mailing >>> list [email protected] >>> <mailto:[email protected]> >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> -- >> Douglas N. Greve, Ph.D. >> MGH-NMR Center >> [email protected] <mailto:[email protected]> >> Phone Number: 617-724-2358 >> Fax: 617-726-7422 >> >> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting >> FileDrop:https://gate.nmr.mgh.harvard.edu/filedrop2 >> www.nmr.mgh.harvard.edu/facility/filedrop/index.html >> <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> >> Outgoing:ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ >> >> _______________________________________________ >> Freesurfer mailing list >> [email protected] <mailto:[email protected]> >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > > _______________________________________________ > Freesurfer mailing list > [email protected] > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Douglas N. Greve, Ph.D. MGH-NMR Center [email protected] Phone Number: 617-724-2358 Fax: 617-726-7422 Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ _______________________________________________ Freesurfer mailing list [email protected] https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
