In the bad output of the fill, is it hanging onto the mask by a small thread, one that does not exist in the good wm/fill? When the wm is analyzed to get the fill, it removes "islands". I think that extracerebral stuff is an island in the good (and so removed) and still connected in the bad. It may be that the connection is just above some threshold in the bad but just below threshold in the good. Does this make sense?
doug
On 08/26/2014 06:08 PM, Vincent Beliveau wrote:
That area outside the brain is not present in both wm.mgz and filled.mgz for the failed output but for the good output, it is present in wm.mgz but not in filled.mgz (see attached figures). Again, given the similarity of the inputs it is surprising that the wm.mgz and filled.mgz end up being segmented so differently.
On 26.08.2014 23:41, Douglas N Greve wrote:
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 <Melanie.Ganz@nru.dk mailto:Melanie.Ganz@nru.dkMelanie.Ganz@nru.dk>Melanie.Ganz@nru.dk>> 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 >> <Melanie.Ganz@nru.dk >> mailto:Melanie.Ganz@nru.dkMelanie.Ganz@nru.dk>Melanie.Ganz@nru.dk>> >> 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/ReconAllDevTablegivesa 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 Freesurfer@nmr.mgh.harvard.edu >>>>> mailto:Freesurfer@nmr.mgh.harvard.edu >>>>> 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. >>>> _______________________________________________ Freesurfer >>>> mailing list Freesurfer@nmr.mgh.harvard.edu >>>> mailto:Freesurfer@nmr.mgh.harvard.edu >>>> 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. >>> -- 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: Melanie.Ganz@nru.dk >>> mailto:Melanie.Ganz@nru.dk Melanie.Ganz@nru.dk> web: >>> http://melanie.clausundmelanie.de/ >>> _______________________________________________ Freesurfer >>> mailing list Freesurfer@nmr.mgh.harvard.edu >>> mailto:Freesurfer@nmr.mgh.harvard.edu >>> 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. >> _______________________________________________ Freesurfer >> mailing list Freesurfer@nmr.mgh.harvard.edu >> mailto:Freesurfer@nmr.mgh.harvard.edu >> 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. > -- 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: Melanie.Ganz@nru.dk > mailto:Melanie.Ganz@nru.dk Melanie.Ganz@nru.dk> > Melanie.Ganz@nru.dk mailto:Melanie.Ganz@nru.dk> web: > http://melanie.clausundmelanie.de/ > _______________________________________________ Freesurfer > mailing list Freesurfer@nmr.mgh.harvard.edu > mailto:Freesurfer@nmr.mgh.harvard.edu > 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.
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu mailto:Freesurfer@nmr.mgh.harvard.edu Freesurfer@nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu mailto:greve@nmr.mgh.harvard.edu greve@nmr.mgh.harvard.edu> 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 http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing:ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu mailto:Freesurfer@nmr.mgh.harvard.edu Freesurfer@nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu mailto:Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu mailto:greve@nmr.mgh.harvard.edu 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 Freesurfer@nmr.mgh.harvard.edu mailto:Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer