Freesurfer

freesurfer@nmr.mgh.harvard.edu

30132 discussions

Fwd: infant atlas segmentation
by Mark Plantz 31 Jul '13

31 Jul '13

---------- Forwarded message ---------- From: Mark Plantz <markplantz2016(a)u.northwestern.edu> Date: Tue, Jul 30, 2013 at 8:39 AM Subject: Re: [Freesurfer] infant atlas segmentation To: Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> Just opened up the default FreeSurferColorLUT.txt file. So it looks like all I have to change is the #No. column of the file, to match the ones in the other LUT used. I actually just received the MRIcro .lut file from the UNC group. [attached] Hopefully this will help with the conversion. However, I still have to figure out how to open the file. Any ideas? On Tue, Jul 30, 2013 at 8:25 AM, Bruce Fischl <fischl(a)nmr.mgh.harvard.edu>wrote: > Hi Mark > > creating a FreeSurfer LUT really isn't that hard. Have you looked at our > standard one? Probably we have the names you already want and you just need > to change our indices to match the ones in your segmentation file (and save > it as a different LUT) > > cheers > Bruce > > On Tue, 30 Jul 2013, Mark Plantz wrote: > > Turns out that the files had been labeled using a color LUT in a program >> called MRIcro. I am now installing this program simply to access the LUT. >> Will it be as simple as exchanging the index values from this LUT to a >> custom LUT in FreeSurfer? >> >> >> On Tue, Jul 30, 2013 at 12:35 AM, Douglas Greve < >> greve(a)nmr.mgh.harvard.edu> >> wrote: >> >> The problem is that you need to create a completely new LUT. The >> labels that get displayed with the standard LUT are going to be >> totally random with respect to what they should display. >> >> On 7/29/13 2:20 PM, Mark Plantz wrote: >> Hi Doug, >> Thanks for the reply. I will definitely go into the LUT and >> change those values to some specific region. My main concern is >> that I think all of these "out of bounds" labels are the >> symptoms of some larger problem. The segmentation looks very >> strange as compared to a typical segmentation (i.e. an >> 'aseg.mgz' file). In fact, the segmentation appears to be >> labeling "left-<region" in the right hemisphere. Have you seen a >> segmentation file that looks like the once I attached before? I >> am used to seeing segmentation files such as the one attached to >> this e-mail. >> >> - Mark >> >> >> On Mon, Jul 29, 2013 at 12:28 PM, Douglas Greve >> <greve(a)nmr.mgh.harvard.edu> wrote: >> >> Mark, the only thing that is wrong with the out of >> bounds regions is that they are not represented in >> the LUT. Once you add an index corresponding to the >> index of the segmentation to the LUT, it will not >> show up as "out of bounds". The brain mask has >> nothing to do with it. >> best >> doug >> >> >> >> On 7/29/13 12:50 PM, Mark Plantz wrote: >> Sorry about that. I received the manual >> segmentations from a UNC medical group<http://www.med.unc.edu/** >> bric/ideagroup/free-softwares/**unc-infant-0-1-2-atla<http://www.med.unc.edu/bric/ideagroup/free-softwares/unc-infant-0-1-2-atla> >> ses>. I actually asked the main researcher >> about the out of bounds regions. He thinks >> that as long as the segmented file lines up >> with the input volumes, a few out of bounds >> regions might be OK. However, these seg >> volumes look very different from a typical >> .aseg volume that I am used to seeing after >> recon-all is run. >> Maybe the segmentation is simply incompatible with >> FreeSurfer? >> >> Thanks for the help. These files are a nightmare! >> >> - MP >> >> >> On Mon, Jul 29, 2013 at 11:40 AM, Bruce Fischl >> <fischl(a)nmr.mgh.harvard.edu> wrote: >> can you cc the list please? Maybe we >> should start over. Where did you get the >> manual segmentations from? >> >> On Mon, 29 Jul 2013, Mark Plantz wrote: >> >> Ahh, right. So it looks like >> the red regions appear to be >> averaged around 248. I am >> not sure why that is the >> case or if it has >> any significance. I attached >> a screen shot for >> reference. >> >> >> On Mon, Jul 29, 2013 at >> 11:29 AM, Bruce Fischl >> <fischl(a)nmr.mgh.harvard.edu> >> wrote: >> it isn't a >> registration file. You >> should just specify it as a >> volume on the freeview >> command line, the same as >> brainmask.mgz >> >> On Mon, 29 Jul 2013, >> Mark Plantz wrote: >> >> I actually tried >> to view the brainmask.mgz >> file with the segmentation >> file [Freeview calls it >> 'registration >> file' I believe]. >> For some reason, >> the file will load without >> segmentation, but when I >> attempt to add the >> registration >> file, I get an >> error >> message: >> "Failed to load >> MRI >> ~/.../../../brainmask.mgz >> >> Could this >> potentially be part of the >> problem? >> >> Thanks >> >> MP >> >> >> On Mon, Jul 29, >> 2013 at 10:57 AM, Mark >> Plantz >> <markplantz2016(a)u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> > >> wrote: >> >> It looks >> like the values vary from >> 20-120 depending on which >> region I run the cursor >> over. >> However, aren't >> those the >> values >> that correspond to the >> brain.mgz regions? Is there >> another way to find the >> segmentation >> values? >> >> >> On Mon, Jul 29, >> 2013 at 10:37 AM, Bruce >> Fischl >> <fischl(a)nmr.mgh.harvard.edu> >> wrote: >> I mean the >> segmentation values that >> give you the "out of bounds" >> message >> On Mon, 29 >> Jul 2013, Mark Plantz wrote: >> >> Hi >> Bruce, >> Do >> you mean the brainmask.mgz >> values? I'm not sure what >> the segmentation #'s exactly >> are. >> >> >> Thanks! >> >> MP >> >> >> On >> Mon, Jul 29, 2013 at 10:17 >> AM, Bruce Fischl >> <fischl(a)nmr.mgh.harvard.edu> >> wrote: >> >> Hi Mark >> >> >> >> what #s are those >> segmentations? It should be >> trivial to just add them to >> the end of >> the >> LUT. >> I wouldn't let them be >> >> out of bounds as there >> might be code around that >> might ignore them then. >> >> >> cheers >> >> Bruce >> >> >> On Mon, 29 Jul 2013, Mark >> Plantz wrote: >> >> >> Hi Doug, >> >> Thanks for >> the reply. After doing some >> research, it looks like >> messing >> with the >> LUT >> might be a >> >> risky decision [and >> way >> >> out of my >> abilities!]. >> >> >> If I were to use >> this segmentation file to >> create a .gca atlas using >> the >> command >> >> mri_ca_train, do you >> >> think it would yield >> >> problems or be >> inaccurate? I guess what I >> am trying to figure out is >> if the >> color >> >> lookup values are even >> >> significant when >> using >> >> the segmentation >> file to create an atlas? >> >> >> Thanks for all of >> the help with this. >> >> >> Best, >> >> >> MP >> >> >> p.s. I attached the >> photo of the segmentation >> volume because this e-mail >> is sort >> of >> old >> >> >> >> On Wed, Jul 24, 2013 >> at 2:39 PM, Douglas N Greve >> <greve(a)nmr.mgh.harvard.edu> >> wrote: >> >> you need a new >> LUT. See my comment from a >> few emails ago. >> >> On 07/24/2013 >> 03:29 PM, Mark Plantz wrote: >> >> I'm not >> actually quite sure what it >> means either. When I use the >> command >> line: >> >> >> tkmedit >> $Subject brain.mgz >> -segmentation <seg.mgz>, >> >> >> I can run the >> cursor over various regions >> and the name of the region >> should pop >> up. >> For some >> >> reason, the red >> >> regions are >> simply labeled as "out of >> bounds." >> >> >> I'll keep >> messing with tkmedit and let >> you know if I find out what >> the >> problem >> is. >> >> >> Thanks guys! >> >> >> MP >> >> >> >> On Wed, Jul 24, 2013 >> at 2:26 PM, Douglas N Greve >> <greve(a)nmr.mgh.harvard.edu >> >> >> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu> >> >> >> >> wrote: >> >> >> what do you mean >> that they are out of bounds? >> >> >> On 07/24/2013 >> 03:25 PM, Mark Plantz wrote: >> >> >> I guess the >> problem is that those >> regions should not be out of >> >> bounds. >> Maybe I need to create a new >> Lookup Table for the >> >> infant >> mri's? Is that possible to >> do? >> >> >> >> On Wed, Jul >> 24, 2013 at 2:21 PM, Douglas >> N Greve >> >> >> <greve(a)nmr.mgh.harvard.edu >> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu> >> > >> >> >> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu> >> >> >> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu> >> >>> >> wrote: >> >> >> Hi Mark, >> please post to the list and >> not to me. >> >> thanks >> >> doug >> >> >> On >> 07/24/2013 03:21 PM, Mark >> Plantz wrote: >> >> >> I >> guess the problem is that >> those regions should not >> >> be out of >> >> >> bounds. Maybe I need to >> create a new Lookup Table >> for the >> >> >> infant mri's? Is that >> possible to do? >> >> >> >> On >> Wed, Jul 24, 2013 at 2:15 >> PM, Douglas N Greve >> >> >> <greve(a)nmr.mgh.harvard.edu >> >> >> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu> >> > >> >> >> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu> >> >> >> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu> >> >> >> >> >> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu> >> >> >> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu> >> > >> >> >> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu> >> >> >> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu> >> >>>> >> wrote: >> >> >> >> >> what is the problem exactly? >> The fact that there >> >> are red >> >> >> regions >> >> >> or that that the red regions >> are labeled as "Out of >> >> >> Bounds"? If >> >> >> the latter, you will need to >> create a LUT that >> >> matches your >> >> >> regions. the out of bounds >> means that the index in the >> >> >> volume does >> >> >> not match an index in the >> LUT. >> >> >> doug >> >> >> >> >> >> On 07/24/2013 01:26 PM, Mark >> Plantz wrote: >> >> >> >> Finally got the >> registration to work. >> However, it >> >> >> looks like >> >> >> the out of bounds >> regions (in red) are still >> >> present >> (even >> >> >> though the regions are >> well within our >> >> boundaries). >> Is >> >> that >> >> >> expected since they were >> labeled in the original >> >> >> segmentation >> >> >> volume? Is there anyway >> to correct those? >> >> >> >> Thanks for all of the >> help! >> >> >> >> - Mark >> >> >> p.s. I attached a >> picture of the original >> >> brain.mgz >> file >> >> >> viewed with the >> corrected segmentation >> volume >> >> >> >> >> On Wed, Jul 24, 2013 at >> 12:22 PM, Mark Plantz >> >> >> >> <markplantz2016(a)u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> > >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> > >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >>> >> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> > >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> >> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> > >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >>>>> >> wrote: >> >> >> >> Finally got the >> registration to work. >> >> However, it >> >> >> looks >> >> >> like the >> >> >> out of bound regions >> (in red) are still >> >> prevalent. >> >> Is >> that >> >> >> expected since they >> were present in the >> >> original >> >> >> segmentation >> >> >> volume? Would there >> be anyway to correct >> >> those? >> >> >> >> Thanks for all the >> help! >> >> >> >> - MP >> >> >> >> >> On Wed, Jul 24, 2013 >> at 11:11 AM, Mark Plantz >> >> >> >> <markplantz2016(a)u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> > >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> > >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >>> >> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> > >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> >> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> > >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >>>>> >> wrote: >> >> >> >> Nevermind, it >> turned out to be a >> >> permissions >> >> >> issue. >> >> >> Thanks! >> >> >> >> >> On Wed, Jul 24, >> 2013 at 10:12 AM, Mark >> >> Plantz >> >> >> >> <markplantz2016(a)u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> > >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> > >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >>> >> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> > >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> >> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> > >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> >>>>> >> wrote: >> >> >> >> Thanks for >> the reply Doug. I >> >> recently ran >> the >> >> >> bbregister >> >> >> command and >> attempted to view the >> >> results >> >> >> using >> >> >> tkregister2. >> I received the >> >> following >> error: >> >> >> >> >> dhcp-165-124-23-232 >> >> >> <tel:165-124-23-232> >> <tel:165-124-23-232 >> <tel:165-124-23-232>> >> >> >> <tel:165-124-23-232 >> <tel:165-124-23-232> >> >> >> <tel:165-124-23-232 >> <tel:165-124-23-232>>> >> >> >> <tel:165-124-23-232 >> <tel:165-124-23-232> >> >> >> <tel:165-124-23-232 >> <tel:165-124-23-232>> >> >> >> <tel:165-124-23-232 >> <tel:165-124-23-232> >> >> >> <tel:165-124-23-232 >> <tel:165-124-23-232>>>>:Desktop >> >> >> >> >> >> IngvalsonLab$ tkregister2 >> --mov >> >> >> >> /Volumes/Wong_Lab/**CochlearImplant/UNC_NiFTI/** >> infant-1yr-mgz/mri/avgseg.mgz >> >> >> --reg >> >> >> /Users/IngvalsonLab/Desktop/**register.dat >> --surf >> >> >> >> >> tkregister_tcl >> >> >> /Applications/freesurfer/**tktools/tkregister2.tcl >> >> >> INFO: no >> target volume specified, >> >> assuming >> >> >> FreeSurfer orig >> >> >> volume. >> >> >> target >> volume orig >> >> >> movable >> volume >> >> >> >> /Volumes/Wong_Lab/**CochlearImplant/UNC_NiFTI/** >> infant-1yr-mgz/mri/avgseg.mgz >> >> >> reg file >> >> >> /Users/IngvalsonLab/Desktop/**register.dat >> >> >> LoadVol >> 1 >> >> >> ZeroCRAS >> 0 >> >> >> $Id: >> tkregister2.c,v 1.121.2.1 >> >> 2011/03/28 >> >> >> 20:25:16 >> >> >> greve Exp $ >> >> >> Diagnostic >> Level -1 >> >> >> >> regio_read_register(): >> Undefined >> >> error: 0 >> >> >> Error >> reading subject from >> >> >> /Users/IngvalsonLab/Desktop/**register.dat >> >> >> ERROR: >> reading >> >> >> >> /Users/IngvalsonLab/Desktop/**register.dat >> >> >> >> dhcp-165-124-23-232 >> >> >> <tel:165-124-23-232> >> <tel:165-124-23-232 >> <tel:165-124-23-232>> >> >> >> <tel:165-124-23-232 >> <tel:165-124-23-232> >> >> >> <tel:165-124-23-232 >> <tel:165-124-23-232>>> >> >> >> <tel:165-124-23-232 >> <tel:165-124-23-232> >> >> >> <tel:165-124-23-232 >> <tel:165-124-23-232>> >> >> >> <tel:165-124-23-232 >> <tel:165-124-23-232> >> >> >> <tel:165-124-23-232 >> <tel:165-124-23-232>>>>:Desktop >> >> >> >> >> >> IngvalsonLab$ >> >> >> >> I do not >> believe it is a >> >> permissions >> issue? >> >> >> >> Could it >> simply be that the >> >> register was >> >> bad? >> Is >> >> >> there an >> >> >> easy way to >> open up the >> >> >> register.dat.mincost file >> >> >> to check >> >> >> the >> registration? >> >> >> >> Thanks >> again, >> >> >> >> MP >> >> >> >> >> On Tue, Jul >> 23, 2013 at 9:32 PM, >> > >

3 5

Hand Segmenting White and Pial Layers
by Liv Wroblewski 31 Jul '13

31 Jul '13

Hi Freesurfer, Here at I-LABS we just finished making a couple new 6-month and 12-month infant templates for ourselves and the neuroscience community to use. When I run the template through the recon-all pipeline, there is significant blurring of the template as opposed to when I look at the original in FSL and the segmentation is not usable for our MEG source localization. I would like to create the grey matter and white matter masks completely by hand over the next week or two from the original nifti image, and then have freesurfer use those masks in the surface reconstructions. Is this possible? If so, how can I do it? Thanks so much in advance, Liv

2 1

Re: [Freesurfer] hippo_subfields atlas
by Juan Eugenio Iglesias 31 Jul '13

31 Jul '13

Did you run recon-all -subjid bert -hippo-subfields? If so, there should be a log file with the output from the hippo-subfield code in $SUBJECTS_DIR/bert/scripts/hippo-subfields.log. You can take a look at it to get an idea of what happened. Kind regards, /Eugenio On 07/31/2013 04:38 PM, Rajapillai Pillai wrote: > Thanks very much for the prompt response. The command I ran was > > $ kvlQuantifyPosteriorProbabilityImages > /Applications/freesurfer/data/GEMS/compressionLookupTable.txt > posterior_right_* posterior_Right-Hippocampus.mgz > > in $SUBJECTS_DIR/bert/mri > > And yeah, it's not in the mri directory. Any idea what might have gone > wrong and how I can try and fix it? > > Thanks, > Raja > > > On Wed, Jul 31, 2013 at 4:29 PM, Juan Eugenio Iglesias > <iglesias(a)nmr.mgh.harvard.edu <mailto:iglesias@nmr.mgh.harvard.edu>> > wrote: > > Hi Raja, > > >> >> I'm have a question regarding the GEMS hippocampal segmentation. >> I saw on the wiki how to run -hippo_subfields, but how do I >> access the atlas itself? What file is it under. > > That would be $FREESURFER_HOME/data/GEMS/CurrentMeshCollection30.gz > > >> >> Also, I'm not sure if I'm missing some files: whenever I try to >> do one of the individual commands using, for example, >> posterior_Right_Hippocampus.mgz, it gives the following error: >> >> volumeInVoxels: >> terminate called after throwing an instance of 'itk::ExceptionObject' >> what(): itkMGHImageIO.cxx:216: >> itk::ERROR: MGHImageIO(0x56b5c0): Can't find/open file: >> posterior_Right-Hippocampus.mgz >> Abort trap >> > > What command is this? In any case, it's pretty clear that the file > is missing.... > > >> Also, upon searching through my freesurfer directory, I cannot >> find any posterior_Right-Hippocamus.mgz or >> posterior_Left-Hippocampus.mgz files. > It should be under the "mri" directory. If it isn't, there was > some problem running the algorithms. > > Cheers, > > /Eugenio > > > > >> >> Thanks very much for your time, >> Raja >> >> >> _______________________________________________ >> Freesurfer mailing list >> Freesurfer(a)nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > -- > ------------------------------------------------------------------------------------- > Juan Eugenio Iglesias, PhD > http://www.jeiglesias.com > iglesias(a)nmr.mgh.harvard.edu <mailto:iglesias@nmr.mgh.harvard.edu> > Athinoula A. Martinos Center for Biomedical Imaging > 149 Thirteenth Street, Suite 2301 > Charlestown, Massachusetts 2129 > U.S.A. > > 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. > > -- ------------------------------------------------------------------------------------- Juan Eugenio Iglesias, PhD http://www.jeiglesias.com iglesias(a)nmr.mgh.harvard.edu Athinoula A. Martinos Center for Biomedical Imaging 149 Thirteenth Street, Suite 2301 Charlestown, Massachusetts 2129 U.S.A.

1 0

hippo_subfields atlas
by Rajapillai Pillai 31 Jul '13

31 Jul '13

Dear Freesurfers, I'm have a question regarding the GEMS hippocampal segmentation. I saw on the wiki how to run -hippo_subfields, but how do I access the atlas itself? What file is it under. Also, I'm not sure if I'm missing some files: whenever I try to do one of the individual commands using, for example, posterior_Right_Hippocampus.mgz, it gives the following error: volumeInVoxels: terminate called after throwing an instance of 'itk::ExceptionObject' what(): itkMGHImageIO.cxx:216: itk::ERROR: MGHImageIO(0x56b5c0): Can't find/open file: posterior_Right-Hippocampus.mgz Abort trap Also, upon searching through my freesurfer directory, I cannot find any posterior_Right-Hippocamus.mgz or posterior_Left-Hippocampus.mgz files. Thanks very much for your time, Raja

2 1

Using gcut multiple times
by Chris Watson 31 Jul '13

31 Jul '13

Hello, Is there any value in running recon-all with "-gcut" multiple times? e.g. in a case where skull/dura continues to be left on brainmask.mgz? Thanks, Chris

2 1

White matter edits
by lexi bryon 31 Jul '13

31 Jul '13

Dear Freesurfer experts, I am running recon-all on child brains and I am have an issue with one brain. One entire temporal gyrus is being excluded from the white matter boundary line. I have entered control points and rerun recon-all using autorecon2-cp. This added the desired white matter to wm.mgz: see attached photo. But as you can see it does not recognize it as white matter and/or create the correct white matter boundary/ pial surface. Any ideas? Sincerely, Alexarae

2 1

freesurfer 5.3 T2 flags error
by Joana Braga Pereira 31 Jul '13

31 Jul '13

Dear FreeSurfers, I tried using FreeSurfer 5.3 with the new T2 flags and I got the following error: INFO: Reading transformation from file /tmp/1b2003d0-08c9-4e48-9e9d-622f29f0ff44/mri/transforms/T2raw.lta... Reading transform with LTAreadEx() No such file or directory ERROR: Reading transform from file /tmp/1b2003d0-08c9-4e48-9e9d-622f29f0ff44/mri/transforms/T2raw.lta Linux pe01 3.5.0-27-generic #46~precise1-Ubuntu SMP Tue Mar 26 19:33:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux This is the command I used: /usr/local/freesurfer-5.3/bin/recon-all -T2 0517a9f6-098e-47e8-9038-347d8ec7f840/PPMI_3557_MR_Axial_PD-T2_TSE__br_raw_20110406143102862_49_S103376_I226466.dcm -i 1d58a0ab-3be7-4f18-974a-7faed908c840/MR_MPRAGE_GRAPPA__br_raw_20110406143100268_1_S103377_I226467.dcm -subjid 1b2003d0-08c9-4e48-9e9d-622f29f0ff44 -all -mprage -nuintensitycor-3T -qcache -T2pial Does anyone know why I got this error with the T2 or what I did wrong? Many thanks! joana

1 0

GLM Analysis: ROI (--label)
by Rachel Jonas 30 Jul '13

30 Jul '13

Hi FreeSurfer users, I am running a GLM analysis on the command line, and would like to look specifically within an ROI. I added the flag: --label lh.orbitofrontal.label, in my case, to mri_glmfit, but keep getting an error. It seems that whenever it hits this line in the command, it quits. If I put this flag at the very end (after I specify the glmdir, which I do at the very end), it'll just complete the analysis as if this flag wasn't even there, resulting in a full-brain analysis. Am I missing something here re: how to add in this flag? Any help would be much appreciated! Rachel Jonas

2 1

Cerebellar parcellation
by charles laidi 30 Jul '13

30 Jul '13

Dear Freesurfers, I would like to perform cerebellar parcellation on structural mri with freesurfer. I asked if this was possible 6 months ago (see message below, saying that this feature wasn't available for now). I checked on freesurfer wiki the release notes about Freesurfer version 5.2.0 saying that new cortical parcellations and label were available. "Cortical, Cerebellar, Striatum Parcellation in MNI152 space found in average/<Yeo_JNeurophysiol11_MNI152>, average/<Buckner_JNeurophysiol11_MNI152> and average/<Choi_JNeurophysiol12_MNI152>. See README file in each directory for more details. Note that these README files will be updated to reflect minor improvements in parcellations beyond the publication wikipages". My understanding is that cerebellar parcellation on structural mri is still not available, could you tell me if I'm right ? When I'm checking the link on the release notes it doesn't seems to concern structural imaging. Thanks a lot for your attention, sorry if my question seems obvious but I'm not very familiar with freesurfer. Charles PS : -answer : Hi Charles, that is true at the moment, although we are working on something that should be ready relatively soon. cheers Bruce -question : Dear freesurfer, I'm trying to perform parcellation on the cerebellum. After reading closely freesurfer wiki and the questions related to this topic on the mailing list, my understanding is that there is no way to perform fully automted cerebellar parcellation on structural mri with freesurfer. Could you tell me if I'm right ? Thanks a lot for your attention Charles

2 1

are many *.dat files written out to disk in <subj_dir>/mri and then deleted when autorecon completes?
by Montillo, Albert (GE Global Research) 30 Jul '13

30 Jul '13

After importing a subject's data (T1 single time point) I run a script with these commands: recon-all -s <subject> -autorecon1 recon-all -s <subject> -autorecon2 recon-all -s <subject> -autorecon3 I did this twice, once on each of two linux machines. I am using the same exact input intensity T1 data and importing the data into separate subject names (e1859_workingBak and e1858_nonworking) so there is no collision. Why am I getting many (really 1000's ) of v1_1.dat files in the $SUBJECTS_DIR/<subject>/mri of one of the machines, even though the input data is the same? They are named vNNN_N.dat where N is a digit . Contents of one of these files is below. The contents of the subject folders are represented below using the du -k . command. Now in this nonworking case the job terminated early (run time limit on the job which I can fix ) ; however I am curious: are all of these *.dat files (40GB worth!) written out all the time and then deleted at the end of the recon tasks? This happens on one red-hat linux machine (cluster ) but not on another for the same subject data Is this normal behavior? Are the dat files written out normally and then deleted later in the processing (since I don't see them in the run that completed). Contents of a subject after a successful run to completion: [e1858_workingBak]$ du -k . 1176 ./scripts 16 ./mri/transforms/bak 108200 ./mri/transforms 14088 ./mri/orig 176068 ./mri 149940 ./surf 16 ./tmp 35228 ./label 1096 ./touch 544 ./stats 16 ./src 16 ./trash 16 ./bem 364132 . Contents of same MRI input data to a different subject name, whose processing (same as above) terminated prematurely: [e1858_nonworking]$ du -k . 800 ./scripts 16 ./mri/transforms/bak 108200 ./mri/transforms 14088 ./mri/orig 41027804 ./mri 29252 ./surf 16 ./tmp 16 ./label 360 ./touch 16 ./stats 16 ./src 16 ./trash 16 ./bem 41058328 . This is when the processing of e1858_nonworking got terminated: [scripts]$ tail recon-all-status.log #@# Intensity Normalization2 Thu Jul 25 19:20:22 EDT 2013 #@# Mask BFS Thu Jul 25 19:24:53 EDT 2013 #@# WM Segmentation Thu Jul 25 19:24:56 EDT 2013 #@# Fill Thu Jul 25 19:27:47 EDT 2013 #@# Tessellate lh Thu Jul 25 19:28:47 EDT 2013 #@# Smooth1 lh Thu Jul 25 19:28:56 EDT 2013 #@# Inflation1 lh Thu Jul 25 19:29:01 EDT 2013 #@# QSphere lh Thu Jul 25 19:29:37 EDT 2013 #@# Fix Topology lh Thu Jul 25 19:35:03 EDT 2013 #@# Make White Surf lh Thu Jul 25 19:55:20 EDT 2013 This is the contents of one (v1_1.dat ) of the many *.dat files in /mri [mri]$ tail v1_1.dat 12.014513 223.051927 250.208421 12.052258 222.911943 252.203797 12.090005 222.771944 254.199159 12.127751 222.631960 256.194520 12.165498 222.491960 258.189912 12.203243 222.351976 260.185273 12.240990 222.211977 262.180635 12.278736 222.071992 264.175996 12.316483 221.931993 266.171358 12.354229 221.791994 268.166750

2 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Freesurfer