[Freesurfer] issues with bvecs extracted from dicoms
External Email - Use Caution Dear FreeSurfer team! First of all, thanks for the great tools! I have recently started to work with DWI data and there are a few issues I was hoping you could help me with. I have recently found a post on the FSL mailing list mentioning that the bvecs stored in the dicoms header on Siemens scanner are corrected for slice angulation (https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=FSL;5757c231.1005). I assume this means that, for Siemens dicoms, the bvecs are stored in image orientation? Indeed, the bvecs in the dicoms are different than the ones in the table provided by Siemens. When looking at the preprocessing performed by tracula, the flag --bvec-voxel is used when importing the data from dicoms; isn't this be conflicting with the fact that the bvecs are already in image orientation? A second issue I have is when using the bvecs extracted using tracula to perform tractography in trackvis/diffusion toolkit. For some stange reason, I have to flip the z-axis of the bvec (obtained with either --bvec-voxel or --bvec-scanner) to obtain sensible tractography results. When comparing the bvecs from tracula to the table from Siemens the z-axis is indeed flipped. Unfortunately, this flip issue also occurs in a number of other conversion software (e.g. dcm2niix, mrtrix). Does anyone know where this could be coming from? Note, my data was acquired on a Siemens SkyraFit with software version VE11C. Finally, does anyone know what orientation (image/scanner) is expected for the bvecs when using dti_tracker (in diffusion toolkit)? When looking at the default bvec file passed through the GUI interface to dti_tracker, it seems that it requires bvecs in scanner orientation, but I would like to confirm this. Unfortunately, I did not receive any reply to my emails to supp...@trackvis.org. Perhaps someone on this list knows? Thanks in advance! Vincent. ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Re: [Freesurfer] segfault using brainstem module from dev version
Hi Martin, Thank you for the feedback. Our version of FS 5.3 is the centos4 build (which works perfectly) so I downloaded the same when got a copy of dev (nightly build 05-11-16). However, I just tried the centos6 and the brainstem module now works smoothly (including mri_robust_register). There must be a difference between FS 5.3 centos4, dev centos4 and dev centos6 but I have no clue of what that could be or if it even matters. I thought you might like to know. Best, Vincent. On 17.05.2016 19:27, Martin Reuter wrote: > Hi Vincent, > > I tried it on my machine and it works. No segfault and the registration looks > good. Is your dev version older? I don't specifically remember fixing > anything recently, but it may be best to download a more recent > robust_register binary? It could also be that something else is incompatible > on your system (e.g. different centos versions etc). > > Best, Martin > > On 05/13/2016 10:29 AM, Vincent Beliveau wrote: > > Hi Martin, > > I assume you want the actual inputs, not the command, sorry about that ;) > I've attached the tmp folder created by the brainstem module. > > Best, > > Vincent. > > On 13.05.2016 16:21, Vincent Beliveau wrote: > > Hi Martin, > > Thanks for the help. From the brainstem-structures.log, mri_robust_register > is called by the brainstem module as follow: > > /data1/vbeliveau/software/freesurfer-Linux-centos4_x86_64-dev-110516/bin//mri_robust_register > --mov imageDump.mgz --dst > /indirect/data1/vbeliveau/atlas/proc/MR/recon_final/f5249_GD/tmp/BS_T1based//BS-DE-binaryMask_autoCropped.mgz > -lta trash.lta --mapmovhdr imageDump_coregistered.mgz --sat 50 > > Best, > > Vincent > > On 13.05.2016 16:13, Martin Reuter wrote: Hi Eugenio and Vincent, > > I cannot remember when I say robust_register crash the last time. It should > never happen. So it could also be that the inputs are already corrupted. Can > you send the inputs to that command so that I can try to replicate and see if > this is still a bug or what is going on? > > Thanks, Martin > > On 05/13/2016 09:54 AM, Eugenio Iglesias wrote: > > It seems that mri_robust_register crashed. Martin, any ideas? > The algorithm worked because the rough registration from the previous step > was apparently enough to yield a decent segmentation. > Maybe we should consider stopping the whole process if mri_robust_register > dies... > > Juan Eugenio Iglesias > Postdoctoral researcher BCBL > www.jeiglesias.com [1] > www.bcbl.eu [2] > > Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer [3] > > - > > FROM: "Vincent Beliveau" <vincent.beliv...@nru.dk> > TO: "Freesurfer support list" <freesurfer@nmr.mgh.harvard.edu> > SENT: Friday, May 13, 2016 2:40:11 PM > SUBJECT: [Freesurfer] segfault using brainstem module from dev version > > Hi list (and Eugenio), > > I've ran the brainstem module from the dev version on some data processed > with FS v5.3. The module created some great segmentations of brainstem but > when taking a closer look at the log file, there is 2 seg faults which occur > when calls to mri_robust_register are made, with the following output (full > log attached, see line 319 and 371): > > /data1/vbeliveau/software/freesurfer-Linux-centos4_x86_64-dev-110516/bin//mri_robust_register: > line 3: 36835 Segmentation fault mri_robust_register.bin "$@" > /data1/vbeliveau/software/freesurfer-Linux-centos4_x86_64-dev-110516/bin//mri_robust_register > --mov imageDump.mgz --dst > /indirect/data1/vbeliveau/atlas/proc/MR/recon_final/f5249_GD/tmp/BS_T1based//BS-DE-binaryMask_autoCropped.mgz > -lta trash.lta --mapmovhdr imageDump_coregistered.mgz --sat 50: Segmentation > fault > mv: cannot stat ?imageDump_coregistered.mgz?: No such file or directory > > I'm curious about how is this affecting the overall process, as otherwise > everything appears to be working smoothly. > > Best, > > Vincent. > > -- > Vincent Beliveau, MSc > Neurobiology Research Unit > Juliane Maries Vej 28, 3rd floor > Rigshospitalet, building 6931 > DK-2100 Copenhagen, Denmark > > phone: +45 3545 6718 > e-mail: vincent.beliv...@nru.dk > ___ > 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 &g
Re: [Freesurfer] segfault using brainstem module from dev version
Hi Martin, Thanks for the help. From the brainstem-structures.log, mri_robust_register is called by the brainstem module as follow: /data1/vbeliveau/software/freesurfer-Linux-centos4_x86_64-dev-110516/bin//mri_robust_register --mov imageDump.mgz --dst /indirect/data1/vbeliveau/atlas/proc/MR/recon_final/f5249_GD/tmp/BS_T1based//BS-DE-binaryMask_autoCropped.mgz -lta trash.lta --mapmovhdr imageDump_coregistered.mgz --sat 50 Best, Vincent On 13.05.2016 16:13, Martin Reuter wrote: > Hi Eugenio and Vincent, > > I cannot remember when I say robust_register crash the last time. It should > never happen. So it could also be that the inputs are already corrupted. Can > you send the inputs to that command so that I can try to replicate and see if > this is still a bug or what is going on? > > Thanks, Martin > > On 05/13/2016 09:54 AM, Eugenio Iglesias wrote: > >> It seems that mri_robust_register crashed. Martin, any ideas? >> The algorithm worked because the rough registration from the previous step >> was apparently enough to yield a decent segmentation. >> Maybe we should consider stopping the whole process if mri_robust_register >> dies... >> >> Juan Eugenio Iglesias >> Postdoctoral researcher BCBL >> www.jeiglesias.com [1] >> www.bcbl.eu [2] >> >> Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer [3] >> >> - >> >> FROM: "Vincent Beliveau" <vincent.beliv...@nru.dk> >> TO: "Freesurfer support list" <freesurfer@nmr.mgh.harvard.edu> >> SENT: Friday, May 13, 2016 2:40:11 PM >> SUBJECT: [Freesurfer] segfault using brainstem module from dev version >> >> Hi list (and Eugenio), >> >> I've ran the brainstem module from the dev version on some data processed >> with FS v5.3. The module created some great segmentations of brainstem but >> when taking a closer look at the log file, there is 2 seg faults which occur >> when calls to mri_robust_register are made, with the following output (full >> log attached, see line 319 and 371): >> >> /data1/vbeliveau/software/freesurfer-Linux-centos4_x86_64-dev-110516/bin//mri_robust_register: >> line 3: 36835 Segmentation fault mri_robust_register.bin "$@" >> /data1/vbeliveau/software/freesurfer-Linux-centos4_x86_64-dev-110516/bin//mri_robust_register >> --mov imageDump.mgz --dst >> /indirect/data1/vbeliveau/atlas/proc/MR/recon_final/f5249_GD/tmp/BS_T1based//BS-DE-binaryMask_autoCropped.mgz >> -lta trash.lta --mapmovhdr imageDump_coregistered.mgz --sat 50: >> Segmentation fault >> mv: cannot stat ?imageDump_coregistered.mgz?: No such file or directory >> >> I'm curious about how is this affecting the overall process, as otherwise >> everything appears to be working smoothly. >> >> Best, >> >> Vincent. >> >> -- >> Vincent Beliveau, MSc >> Neurobiology Research Unit >> Juliane Maries Vej 28, 3rd floor >> Rigshospitalet, building 6931 >> DK-2100 Copenhagen, Denmark >> >> phone: +45 3545 6718 >> e-mail: vincent.beliv...@nru.dk >> ___ >> 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. > > -- > Martin Reuter, PhD > Assistant Professor of Radiology, Harvard Medical School > Assistant Professor of Neurology, Harvard Medical School > A.A.Martinos Center for Biomedical Imaging > Massachusetts General Hospital > Research Affiliate, CSAIL, MIT > Phone: +1-617-724-5652 > Web : http://reuter.mit.edu > > ___ > 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
[Freesurfer] incorrectly labeled vertices in fsaverage lh labels
Hi everyone, In the lh labels of fsaverage (FS 5.3 stable), vertices 102162 and 102163 seem to be incorrectly labeled in lh.cortex.label rather than lh.Medial_wall.label. Anyone noticed this before? I didn't check rh yet. Regards, Vincent. ___ 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.
Re: [Freesurfer] Name external disk not recognized
Cheap solution, use backticks to evaluate the string, e.g. --reg /`echo $f1`/fsreg.dat On 30.10.2014 15:33, Righart, Ruthger wrote: Dear Freesurfers, Not sure if my question is at the right place here but I'll give it a try. I have a memory disk with white spaces in the name: Seagate Expansion Drive. There is no simple way to rename the disk on my Linux machine. In Unix shell scripting problems with finding the directory can be prevented by putting the whole name in quotation marks, e.g., f1=Seagate Expansion Drive and then after that calling f1 with quotation marks (e.g., cp $f1/file.xxx /destination/ ). However, if I want to use bbregister then it does not recognize the quotation marks. For example, behind the flag --reg /$f1/fsreg.dat Freesurfer tells me that it does not recognize Expansion as a flag (probably because it still reads the white space in the name). I was wondering if there is any simple solution around or if the only option seems to try to rename the disk. Best, Ruthger ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer [1] 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 [2] . 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. Links: -- [1] https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer [2] http://www.partners.org/complianceline ___ 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.
Re: [Freesurfer] success and failure of wm surfaces in (almost) identical structural image
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.g...@nru.dk [3] 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 [4]) 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 sen stian 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.g...@nru.dk [1] 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? -- 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.g...@nru.dk [2] web: http://melanie.clausundmelanie.de/ ___ 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. Links: -- [1] mailto:melanie.g...@nru.dk [2] mailto:melanie.g...@nru.dk [3] mailto:melanie.g...@nru.dk [4] http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0038234 ___ 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
Re: [Freesurfer] success and failure of wm surfaces in (almost) identical structural image
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.g...@nru.dk [23]melanie.g...@nru.dkmelanie.g...@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 [24]) 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 ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu [25] Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer [26] -- Douglas N. Greve, Ph.D. MGH-NMR Center gr...@nmr.mgh.harvard.edu [27] gr...@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 [28] www.nmr.mgh.harvard.edu/facility/filedrop/index.html [29] http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html [30] Outgoing:ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ [31] ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu [32] Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer [33] ___ Freesurfer mailing list Freesurfer
