Freesurfer

freesurfer@nmr.mgh.harvard.edu

30132 discussions

Fwd: fsaverage
by Fco. Javier Román 06 Aug '13

06 Aug '13

Hi Bruce, thanks so much!! Do you know some web (or maybe you cant send to me) to obtained the files of the version 4.5.0? Thanks!! FJ 2013/8/6 Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> > Hi Franciso, > > I think that we made some small mods to the spherical registration in that > time to make it more robust, so things probably did change > > cheers > Bruce > > > On Tue, 6 Aug 2013, Fco. Javier Román wrote: > > Hello! >> I want to know if there are any change in the files of the folder >> fsaverage >> in the different versions of freesurfer. Specifically, I'm interested in >> know if the files lh.pial_avg and rh.pial_avg are the same in the versions >> v4.5.0 and v5.3.0 >> >> Many thanks in advance, >> >> Best, >> -- >> Francisco Javier Román >> >> >> > > 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<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. > -- Francisco Javier Román -- Francisco Javier Román

1 0

fsaverage
by Fco. Javier Román 06 Aug '13

06 Aug '13

Hello! I want to know if there are any change in the files of the folder *fsaverage * in the different versions of freesurfer. Specifically, I'm interested in know if the files lh.pial_avg and rh.pial_avg are the same in the versions v4.5.0 and v5.3.0 Many thanks in advance, Best, -- Francisco Javier Román

2 1

Best way to generate Complete Stats Table
by Salil Soman 06 Aug '13

06 Aug '13

Hi, I have a large dataset for which I run freesurfer and confirmed that the apar+aseg.mgz file is satisfactory. Can someone please recommend the best way to aggregate all of the volumes/other values generated by freesurfer into a single table for this dataset? (e.g. subjects as Rows and values by columns). Best wishes, Sla

5 13

Re: [Freesurfer] Fwd: infant atlas segmentation
by Douglas N Greve 06 Aug '13

06 Aug '13

I think I gave you the wrong command line for mri_label2vol. Try added --invertmtx to the command line. Sorry for the wild goose chase. doug On 08/06/2013 04:00 PM, Mark Plantz wrote: > The bbregister output looks like a typical intensity volume [attached]. > > Out of curiosity, I ran mri_label2vol with a different segmentation > volume (the aparc+aseg default). It looks like the images are not > inverted, but the sagittal has been switched with the coronal view. Is > it possible that my version of mri_label2mri has a bug? > > > > > On Tue, Aug 6, 2013 at 2:46 PM, Douglas N Greve > <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> wrote: > > > What happens if you load the output of bbregister? > > > On 08/06/2013 03:30 PM, Mark Plantz wrote: > > The output of bbregister is actually fine. It seems like the > inversion happens after mri_label2vol is run. I am currently > viewing in FreeView, but the tkmedit command is: > > tkmedit CMH-8169 001.mgz -segmentation > /Applications/freesurfer/subjects/CMH-8169/mri/output.mgz > > LoadSegmentationVolume main > /Applications/freesurfer/subjects/CMH-8169/mri/output.mgz > /Applications/freesurfer/FreeSurferColorLUT.txt > Reading /Applications/freesurfer/tktools/tkm_common.tcl > Reading /Applications/freesurfer/tktools/tkm_wrappers.tcl > Reading /Applications/freesurfer/lib/tcl/fsgdfPlot.tcl > Reading /Applications/freesurfer/tktools/tkUtils.tcl > > > > > > On Tue, Aug 6, 2013 at 12:59 PM, Douglas N Greve > <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>>> wrote: > > That all looks right, and the number of labels = 0 is not a > problem. Is the output of bbregister flipped? What is your > tkmedit > command? > doug > > > On 08/06/2013 10:13 AM, Mark Plantz wrote: > > I think that the registration turned out ok [well it isn't > upside down]. I attached a few screenshots. > > My bbregister command is: > > *bbregister --s CMH-8169 --mov > > /Volumes/Wong_Lab/CochlearImplant/UNC_NiFTI/infant-1yr-mgz/seg.mgz > --init-fsl --reg > > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/register.dat > --t1 --o > > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/output.mgz* > * > > * > Subsequently, my mri_label2vol command is: > > *ingvalsons-imac:~ IngvalsonLab$ mri_label2vol --seg > > /Volumes/Wong_Lab/CochlearImplant/UNC_NiFTI/infant-1yr-mgz/seg.mgz > --temp > > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/output.mgz > --reg > > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/register.dat > --o /Users/IngvalsonLab/Desktop/output.mgz * > > > Number of labels: 0 > Annot File: (null) > Template Volume: > > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/output.mgz > Outut Volume: /Users/IngvalsonLab/Desktop/output.mgz > Registration File: > > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/register.dat > Fill Threshold: 0 > Label Vox Vol: 1 > ProjType: (null) > ProjTypeId: 0 > ProjStart: 0 > ProjStop: 0 > ProjDelta: 0.1 > Subject: (null) > Hemi: (null) > UseNewASeg2Vol: 1 > DoLabelStatVol 0 > LabelCodeOffset 0 > setenv SUBJECTS_DIR /Applications/freesurfer/subjects > $Id: mri_label2vol.c,v 1.34.2.5 2012/06/08 17:31:03 > greve Exp $ > Template RAS-to-Vox: -------- > -1.000 0.000 0.000 128.000; > -0.000 -0.000 -1.000 128.000; > -0.000 1.000 -0.000 128.000; > 0.000 0.000 0.000 1.000; > Template Voxel Volume: 1 > nHits Thresh: 0 > Loading registration from > > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/register.dat > RegMat: -------- > -0.994 -0.098 0.042 0.715; > 0.043 -0.001 0.999 -14.682; > 0.097 -0.995 -0.005 2.026; > 0.000 0.000 0.000 1.000; > Label RAS-to-Vox: -------- > 0.994 0.098 -0.042 127.285; > -0.097 0.995 0.005 125.974; > 0.043 -0.001 0.999 113.318; > 0.000 0.000 0.000 1.000; > ASeg2Vol: Building LUT > ASeg2Vol: Sorting > ASeg2Vol: Mapping > ASeg2Vol: Reverse Map > nmisses = 9739499 (73560 filled) > ASeg2Vol: done > ingvalsons-imac:~ IngvalsonLab$ > > > Is it significant that number of labels = 0? Or is that > because I am using a segmentation volume instead of an > actual > .label file? > > Other than that, I cannot seem to determine why the output > images would be inverted by 180 degrees. > > Thank you in advance > MP > > > > > On Mon, Aug 5, 2013 at 4:26 PM, Douglas Greve > <greve(a)nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>>>> wrote: > > > did you look at the registration with tkregister2? > When > bbregister > finished, it would have printed out the command > line to > run (it is > also at the end of the log file). If that looks > ok, please > send > your bbregister command. > doug > > > On 8/5/13 1:47 PM, Mark Plantz wrote: > > Thanks Doug. mri_label2vol worked well, except it > looks like all > of the files are inverted by 90 degrees. They > appear > inverted in > both tkmedit and 'FreeView.' I read that > inversions > are common in > "fslview" but not in tkmedit. Any idea what > could be > causing this > problem? > > My command line is: > > *mri_label2vol --seg > > > /Volumes/Wong_Lab/CochlearImplant/UNC_NiFTI/infant-1yr-mgz/seg.mgz > --temp > /Users/IngvalsonLab/Desktop/temp.mgz --o > seg_new.mgz --reg > register.dat* > * > > * > I didn't encounter any errors with > mri_label2vol nor > bbregister > [which was used to generate register.dat and > temp.mgz]. > > Any ideas what could be causing this problem? > > I can attach more images if this one doesn't > portray the > inversion well. > > Thanks a lot > > MP > > > On Mon, Aug 5, 2013 at 10:12 AM, Douglas Greve > <greve(a)nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>>>> wrote: > > > The file that you pass it with the --reg > option is the > registration file (eg, --reg > register.dat). This > can be used > for input to mri_vol2vol or mri_label2vol. > mri_label2vol is > appropriate for a segmetation > > doug > > > > On 8/5/13 10:22 AM, Mark Plantz wrote: > > Thank you. Do you know how to access the > transform that is > outputted by bbregister. I am just > obtaining > an output > volume <volume.mgz>>? > > > On Thu, Aug 1, 2013 at 3:56 PM, Bruce > Fischl > <fischl(a)nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu> > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu>> > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu>>>> wrote: > > Hi Mark > > you can use the transform that > bbregister > outputs and > give it to mri_convert with -at > <transform > name> > > cheers > > Bruce > > > On Thu, 1 Aug 2013, Mark Plantz wrote: > > One last question: Is there > any flag I > can use with > 'bbregister' that > prevents the labels from > changing in > my segmentation > volume? This is > occuring because the volume > that I am > moving has > labels. For some reason, > the labels change ever so > slightly in > the output file. > > > On Thu, Aug 1, 2013 at 2:28 > PM, Bruce > Fischl > <fischl(a)nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu> > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu>> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu>>>> > > wrote: > glad it worked out > Bruce > On Thu, 1 Aug 2013, Mark > Plantz > wrote: > > Just as an update, it > turns out that my > segmentation > volume had been > slightly altered > during > the conversion > from .nii to > .mgz. I completely > forgot to use the -rt > nearest flag to > prevent the > labels from becoming > distorted. That is > why the > segmentation > looked so > fuzzy with various > regions > labeled incorrectly. > Apparently, I should check > the basics before > overcomplicating the problem, > haha. Thanks for > the help > everyone! > > > On Thu, Aug 1, 2013 at > 9:36 AM, Mark Plantz > <markplantz2016(a)u.northwestern.edu > <mailto:markplantz2016@u.northwestern.edu> > <mailto:markplantz2016@u.northwestern.edu > <mailto:markplantz2016@u.northwestern.edu>> > > <mailto:markplantz2016@u.northwestern.edu > <mailto:markplantz2016@u.northwestern.edu> > > <mailto:markplantz2016@u.northwestern.edu > <mailto:markplantz2016@u.northwestern.edu>>>> wrote: > Sounds good. I also > just realized > that the > segmentation values > are varying from > 0-255, which > makes me think > that the file is > only > designed for the > grayscale/heat/etc. > settings [where 0 is > darkest regions and > 255 is > brightest regions]. > Is that a valid > assumption? Also, if this is > the case, > would > it be impossible to > create a .gca file using > mri_ca_train with > these files? > Thanks for the help. > > MP > > > On Wed, Jul 31, > 2013 at > 8:43 PM, Douglas > Greve > > <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>>>> wrote: > > Just make > sure that > you create a > new file and > do not > repeat index numbers. > > > On 7/31/13 > 2:02 PM, > Mark Plantz wrote: > That makes > sense. > Wouldn't that > cause there to > be > some overlap > between > different > regions, since > the > same index > #'s used > by the two > programs > (FreeSurfer > & MRIcro) correspond > to different > brain > regions? > > > On Tue, Jul 30, > 2013 at > 12:50 PM, > Douglas Greve > > <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>>>> wrote: > > for every > line in > that file, you > will need to > create a line in the > new LUT, > something like > > > 8 > Frontal_Mid_R 0 > 255 0 0 > > This will > make the > right mid > frontal green = > (0,255,0) > > > > > On 7/30/13 > 9:55 AM, > Mark Plantz wrote: > Hmm, so I > received > the text part > of the > LUT. Looks > like this > is completely > different from the segmented > regions > that we > would want. > [attached]. Can't > seem to > understand > how this text file > could be related to > the default > FreeSurfer LUT. It looks like the > labeling for an AAL > map. This probably > wont' work will it? > - Mark > > > On Tue, Jul 30, > 2013 at > 8:47 AM, Bruce > Fischl > <fischl(a)nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu> > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu>> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu>>>> wrote: > the UNC one? > No, you > should ask > them > On Tue, 30 > Jul 2013, > Mark Plantz > wrote: > > > > ---------- Forwarded message > ---------- > From: Mark > Plantz > <markplantz2016(a)u.northwestern.edu > <mailto:markplantz2016@u.northwestern.edu> > <mailto:markplantz2016@u.northwestern.edu > <mailto:markplantz2016@u.northwestern.edu>> > > <mailto:markplantz2016@u.northwestern.edu > <mailto:markplantz2016@u.northwestern.edu> > > <mailto:markplantz2016@u.northwestern.edu > <mailto:markplantz2016@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 > <mailto:fischl@nmr.mgh.harvard.edu> > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu>> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@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 > <mailto:fischl@nmr.mgh.harvard.edu> > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu>> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@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 > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@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 > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@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 > aUNCmedicalgroup<http://www.med.unc.edu/bric/ideagroup/free-softwares/unc-in > fan > t-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 > <mailto:fischl@nmr.mgh.harvard.edu> > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu>> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@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 > <mailto:fischl@nmr.mgh.harvard.edu> > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu>> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@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 > <mailto:markplantz2016@u.northwestern.edu> > <mailto:markplantz2016@u.northwestern.edu > <mailto:markplantz2016@u.northwestern.edu>> > > <mailto:markplantz2016@u.northwestern.edu > <mailto:markplantz2016@u.northwestern.edu> > > <mailto:markplantz2016@u.northwestern.edu > <mailto:markplantz2016@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 > <mailto:fischl@nmr.mgh.harvard.edu> > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu>> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@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 > <mailto:fischl@nmr.mgh.harvard.edu> > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu>> > > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu> > <mailto:fischl@nmr.mgh.harvard.edu > <mailto:fischl@nmr.mgh.harvard.edu>>>> > > > wrote: > > > Hi > > ... > > [Message clipped] > > -- Douglas N. Greve, Ph.D. MGH-NMR Center greve(a)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 Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

1 0

functional ROI-based structural statistics?
by Yang, Daniel 06 Aug '13

06 Aug '13

Dear FreeSurfer Experts, Theoretically, if you have a set of functional ROIs, is it possible to derive the cortical thickness, white surface area, and gray matter volume of those functional ROIs in FreeSurfer? Many thanks!! Daniel -- Yung-Jui "Daniel" Yang, PhD Postdoctoral Researcher Yale Child Study Center New Haven, CT (203) 737-5454

3 7

Re: [Freesurfer] Fwd: infant atlas segmentation
by Mark Plantz 06 Aug '13

06 Aug '13

The output of bbregister is actually fine. It seems like the inversion happens after mri_label2vol is run. I am currently viewing in FreeView, but the tkmedit command is: tkmedit CMH-8169 001.mgz -segmentation /Applications/freesurfer/subjects/CMH-8169/mri/output.mgz LoadSegmentationVolume main /Applications/freesurfer/subjects/CMH-8169/mri/output.mgz /Applications/freesurfer/FreeSurferColorLUT.txt Reading /Applications/freesurfer/tktools/tkm_common.tcl Reading /Applications/freesurfer/tktools/tkm_wrappers.tcl Reading /Applications/freesurfer/lib/tcl/fsgdfPlot.tcl Reading /Applications/freesurfer/tktools/tkUtils.tcl On Tue, Aug 6, 2013 at 12:59 PM, Douglas N Greve <greve(a)nmr.mgh.harvard.edu>wrote: > That all looks right, and the number of labels = 0 is not a problem. Is > the output of bbregister flipped? What is your tkmedit command? > doug > > > On 08/06/2013 10:13 AM, Mark Plantz wrote: > >> I think that the registration turned out ok [well it isn't upside down]. >> I attached a few screenshots. >> >> My bbregister command is: >> >> *bbregister --s CMH-8169 --mov /Volumes/Wong_Lab/** >> CochlearImplant/UNC_NiFTI/**infant-1yr-mgz/seg.mgz --init-fsl --reg >> /Volumes/Wong_Lab/LabMRIData/**FreeSurfer/CMH-8169/**bbregister/register.dat >> --t1 --o /Volumes/Wong_Lab/LabMRIData/**FreeSurfer/CMH-8169/** >> bbregister/output.mgz* >> * >> >> * >> Subsequently, my mri_label2vol command is: >> >> *ingvalsons-imac:~ IngvalsonLab$ mri_label2vol --seg /Volumes/Wong_Lab/** >> CochlearImplant/UNC_NiFTI/**infant-1yr-mgz/seg.mgz --temp >> /Volumes/Wong_Lab/LabMRIData/**FreeSurfer/CMH-8169/**bbregister/output.mgz >> --reg /Volumes/Wong_Lab/LabMRIData/**FreeSurfer/CMH-8169/**bbregister/register.dat >> --o /Users/IngvalsonLab/Desktop/**output.mgz * >> >> >> Number of labels: 0 >> Annot File: (null) >> Template Volume: /Volumes/Wong_Lab/LabMRIData/**FreeSurfer/CMH-8169/** >> bbregister/output.mgz >> Outut Volume: /Users/IngvalsonLab/Desktop/**output.mgz >> Registration File: /Volumes/Wong_Lab/LabMRIData/**FreeSurfer/CMH-8169/** >> bbregister/register.dat >> Fill Threshold: 0 >> Label Vox Vol: 1 >> ProjType: (null) >> ProjTypeId: 0 >> ProjStart: 0 >> ProjStop: 0 >> ProjDelta: 0.1 >> Subject: (null) >> Hemi: (null) >> UseNewASeg2Vol: 1 >> DoLabelStatVol 0 >> LabelCodeOffset 0 >> setenv SUBJECTS_DIR /Applications/freesurfer/**subjects >> $Id: mri_label2vol.c,v 1.34.2.5 2012/06/08 17:31:03 greve Exp $ >> Template RAS-to-Vox: -------- >> -1.000 0.000 0.000 128.000; >> -0.000 -0.000 -1.000 128.000; >> -0.000 1.000 -0.000 128.000; >> 0.000 0.000 0.000 1.000; >> Template Voxel Volume: 1 >> nHits Thresh: 0 >> Loading registration from /Volumes/Wong_Lab/LabMRIData/** >> FreeSurfer/CMH-8169/**bbregister/register.dat >> RegMat: -------- >> -0.994 -0.098 0.042 0.715; >> 0.043 -0.001 0.999 -14.682; >> 0.097 -0.995 -0.005 2.026; >> 0.000 0.000 0.000 1.000; >> Label RAS-to-Vox: -------- >> 0.994 0.098 -0.042 127.285; >> -0.097 0.995 0.005 125.974; >> 0.043 -0.001 0.999 113.318; >> 0.000 0.000 0.000 1.000; >> ASeg2Vol: Building LUT >> ASeg2Vol: Sorting >> ASeg2Vol: Mapping >> ASeg2Vol: Reverse Map >> nmisses = 9739499 (73560 filled) >> ASeg2Vol: done >> ingvalsons-imac:~ IngvalsonLab$ >> >> >> Is it significant that number of labels = 0? Or is that because I am >> using a segmentation volume instead of an actual .label file? >> >> Other than that, I cannot seem to determine why the output images would >> be inverted by 180 degrees. >> >> Thank you in advance >> MP >> >> >> >> >> On Mon, Aug 5, 2013 at 4:26 PM, Douglas Greve <greve(a)nmr.mgh.harvard.edu<mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>> wrote: >> >> >> did you look at the registration with tkregister2? When bbregister >> finished, it would have printed out the command line to run (it is >> also at the end of the log file). If that looks ok, please send >> your bbregister command. >> doug >> >> >> On 8/5/13 1:47 PM, Mark Plantz wrote: >> >>> Thanks Doug. mri_label2vol worked well, except it looks like all >>> of the files are inverted by 90 degrees. They appear inverted in >>> both tkmedit and 'FreeView.' I read that inversions are common in >>> "fslview" but not in tkmedit. Any idea what could be causing this >>> problem? >>> >>> My command line is: >>> >>> *mri_label2vol --seg >>> >>> /Volumes/Wong_Lab/**CochlearImplant/UNC_NiFTI/**infant-1yr-mgz/seg.mgz >>> --temp >>> /Users/IngvalsonLab/Desktop/**temp.mgz --o seg_new.mgz --reg >>> register.dat* >>> * >>> >>> * >>> I didn't encounter any errors with mri_label2vol nor bbregister >>> [which was used to generate register.dat and temp.mgz]. >>> >>> Any ideas what could be causing this problem? >>> >>> I can attach more images if this one doesn't portray the >>> inversion well. >>> >>> Thanks a lot >>> >>> MP >>> >>> >>> On Mon, Aug 5, 2013 at 10:12 AM, Douglas Greve >>> <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu>>> >>> wrote: >>> >>> >>> The file that you pass it with the --reg option is the >>> registration file (eg, --reg register.dat). This can be used >>> for input to mri_vol2vol or mri_label2vol. mri_label2vol is >>> appropriate for a segmetation >>> >>> doug >>> >>> >>> >>> On 8/5/13 10:22 AM, Mark Plantz wrote: >>> >>>> Thank you. Do you know how to access the transform that is >>>> outputted by bbregister. I am just obtaining an output >>>> volume <volume.mgz>>? >>>> >>>> >>>> On Thu, Aug 1, 2013 at 3:56 PM, Bruce Fischl >>>> <fischl(a)nmr.mgh.harvard.edu >>>> <mailto:fischl@nmr.mgh.**harvard.edu<fischl(a)nmr.mgh.harvard.edu>>> >>>> wrote: >>>> >>>> Hi Mark >>>> >>>> you can use the transform that bbregister outputs and >>>> give it to mri_convert with -at <transform name> >>>> >>>> cheers >>>> >>>> Bruce >>>> >>>> >>>> On Thu, 1 Aug 2013, Mark Plantz wrote: >>>> >>>> One last question: Is there any flag I can use with >>>> 'bbregister' that >>>> prevents the labels from changing in my segmentation >>>> volume? This is >>>> occuring because the volume that I am moving has >>>> labels. For some reason, >>>> the labels change ever so slightly in the output file. >>>> >>>> >>>> On Thu, Aug 1, 2013 at 2:28 PM, Bruce Fischl >>>> <fischl(a)nmr.mgh.harvard.edu >>>> <mailto:fischl@nmr.mgh.**harvard.edu<fischl(a)nmr.mgh.harvard.edu> >>>> >> >>>> >>>> wrote: >>>> glad it worked out >>>> Bruce >>>> On Thu, 1 Aug 2013, Mark Plantz wrote: >>>> >>>> Just as an update, it turns out that my >>>> segmentation >>>> volume had been >>>> slightly altered during the conversion >>>> from .nii to >>>> .mgz. I completely >>>> forgot to use the -rt nearest flag to >>>> prevent the >>>> labels from becoming >>>> distorted. That is why the segmentation >>>> looked so >>>> fuzzy with various regions >>>> labeled incorrectly. >>>> Apparently, I should check the basics before >>>> overcomplicating the problem, >>>> haha. Thanks for the help everyone! >>>> >>>> >>>> On Thu, Aug 1, 2013 at 9:36 AM, Mark Plantz >>>> <markplantz2016(a)u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >>>> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu>>> >>>> wrote: >>>> Sounds good. I also just realized >>>> that the >>>> segmentation values >>>> are varying from 0-255, which >>>> makes me think >>>> that the file is >>>> only designed for the >>>> grayscale/heat/etc. >>>> settings [where 0 is >>>> darkest regions and 255 is >>>> brightest regions]. >>>> Is that a valid >>>> assumption? Also, if this is the case, would >>>> it be impossible to >>>> create a .gca file using >>>> mri_ca_train with >>>> these files? >>>> Thanks for the help. >>>> >>>> MP >>>> >>>> >>>> On Wed, Jul 31, 2013 at 8:43 PM, Douglas >>>> Greve >>>> <greve(a)nmr.mgh.harvard.edu >>>> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu>>> >>>> wrote: >>>> >>>> Just make sure that you create a >>>> new file and >>>> do not >>>> repeat index numbers. >>>> >>>> >>>> On 7/31/13 2:02 PM, Mark Plantz wrote: >>>> That makes sense. Wouldn't that >>>> cause there to >>>> be >>>> some overlap between different >>>> regions, since >>>> the >>>> same index #'s used by the two >>>> programs >>>> (FreeSurfer >>>> & MRIcro) correspond to different >>>> brain >>>> regions? >>>> >>>> >>>> On Tue, Jul 30, 2013 at 12:50 PM, >>>> Douglas Greve >>>> <greve(a)nmr.mgh.harvard.edu >>>> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu>>> >>>> wrote: >>>> >>>> for every line in that file, you >>>> will need to >>>> create a line in the new LUT, >>>> something like >>>> >>>> >>>> 8 Frontal_Mid_R 0 255 0 0 >>>> >>>> This will make the right mid >>>> frontal green = >>>> (0,255,0) >>>> >>>> >>>> >>>> >>>> On 7/30/13 9:55 AM, Mark Plantz wrote: >>>> Hmm, so I received the text part >>>> of the >>>> LUT. Looks like this is completely >>>> different from the segmented regions >>>> that we would want. [attached]. Can't >>>> seem to understand how this text file >>>> could be related to the default >>>> FreeSurfer LUT. It looks like the >>>> labeling for an AAL map. This probably >>>> wont' work will it? >>>> - Mark >>>> >>>> >>>> On Tue, Jul 30, 2013 at 8:47 AM, Bruce >>>> Fischl >>>> <fischl(a)nmr.mgh.harvard.edu >>>> <mailto:fischl@nmr.mgh.**harvard.edu<fischl(a)nmr.mgh.harvard.edu>>> >>>> wrote: >>>> the UNC one? No, you should ask >>>> them >>>> On Tue, 30 Jul 2013, Mark Plantz >>>> wrote: >>>> >>>> >>>> >>>> ---------- Forwarded message >>>> ---------- >>>> From: Mark Plantz >>>> <markplantz2016(a)u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >>>> <mailto:markplantz2016@u.**northwestern.edu<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 >>>> <mailto:fischl@nmr.mgh.**harvard.edu<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 >>>> <mailto:fischl@nmr.mgh.**harvard.edu<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 >>>> <mailto:greve@nmr.mgh.harvard.**edu<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 >>>> <mailto:greve@nmr.mgh.harvard.**edu<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 >>>> aUNCmedicalgroup<http://www.** >>>> med.unc.edu/bric/ideagroup/**free-softwares/unc-in<http://www.med.unc.edu/bric/ideagroup/free-softwares/unc-in> >>>> fan >>>> t-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 >>>> <mailto:fischl@nmr.mgh.**harvard.edu<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 >>>> <mailto:fischl@nmr.mgh.**harvard.edu<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> >>>> <mailto:markplantz2016@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 >>>> <mailto:fischl@nmr.mgh.**harvard.edu<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 >>>> <mailto:fischl@nmr.mgh.**harvard.edu<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 b >>>> >>>> ... >> >> [Message clipped] >> >> > -- > Douglas N. Greve, Ph.D. > MGH-NMR Center > greve(a)nmr.mgh.harvard.edu > Phone Number: 617-724-2358 > Fax: 617-726-7422 > > Bugs: surfer.nmr.mgh.harvard.edu/**fswiki/BugReporting<http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > FileDrop: https://gate.nmr.mgh.harvard.**edu/filedrop2<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/ <ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/> > > > > 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<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. > >

2 1

Re asegstats2table
by Catherine Bois 06 Aug '13

06 Aug '13

Dear Freesurfer experts, I am currently trying to obtain mean thickness values for certain sub-regions of the cortex. I have previously used this command asegstats2table --subjects X_* --meas thickness --tablefile aseg_stats.txt however now (Ive updated to v 5.3) I receive this error asegstats2table: error: option --meas: invalid choice: 'thickness' (choose from 'volume', 'Area_mm2', 'nvoxels', 'nvertices', 'mean', 'std', 'snr', 'max') Has the thickness option been taken away? If this is the case, should I use mris_anatomical stats for labels instead? Or is there still a way to use asegstats2table for subregions (for example for anterior cingulate? Eg in aseg_stats to table I can get the volumes but not thickness values for caudal anterior cingulate?) Thanks for your help! Best Wishes, Cathy -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

2 1

Re: [Freesurfer] Fwd: infant atlas segmentation
by Mark Plantz 06 Aug '13

06 Aug '13

As an update, I noticed that the bbregister output log had an interesting warning statement: WARNING:: Flipping Left/Right orientation (as det < 0) tkregister_tcl /Applications/freesurfer/tktools/tkregister2.tcl target volume /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/tmp.bbregister.4857/fslregister/movvol.fslregister.nii movable volume /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/tmp.bbregister.4857/template.nii reg file /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/tmp.bbregister.4857/fslregister/swapreg.dat LoadVol 0 ZeroCRAS 0 $Id: tkregister2.c,v 1.121.2.1 2011/03/28 20:25:16 greve Exp $ Diagnostic Level -1 INFO: loading target /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/tmp.bbregister.4857/fslregister/movvol.fslregister.nii INFO: target does not conform to COR format, so I'm going to reslice to COR. This will not affect the final registration. Not sure if this is common. I'll e-mail back if I figure anything else out. MP On Tue, Aug 6, 2013 at 9:13 AM, Mark Plantz < markplantz2016(a)u.northwestern.edu> wrote: > I think that the registration turned out ok [well it isn't upside down]. I > attached a few screenshots. > > My bbregister command is: > > *bbregister --s CMH-8169 --mov > /Volumes/Wong_Lab/CochlearImplant/UNC_NiFTI/infant-1yr-mgz/seg.mgz > --init-fsl --reg > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/register.dat > --t1 --o > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/output.mgz* > * > * > Subsequently, my mri_label2vol command is: > > *ingvalsons-imac:~ IngvalsonLab$ mri_label2vol --seg > /Volumes/Wong_Lab/CochlearImplant/UNC_NiFTI/infant-1yr-mgz/seg.mgz --temp > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/output.mgz > --reg > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/register.dat > --o /Users/IngvalsonLab/Desktop/output.mgz * > > Number of labels: 0 > Annot File: (null) > Template Volume: > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/output.mgz > Outut Volume: /Users/IngvalsonLab/Desktop/output.mgz > Registration File: > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/register.dat > Fill Threshold: 0 > Label Vox Vol: 1 > ProjType: (null) > ProjTypeId: 0 > ProjStart: 0 > ProjStop: 0 > ProjDelta: 0.1 > Subject: (null) > Hemi: (null) > UseNewASeg2Vol: 1 > DoLabelStatVol 0 > LabelCodeOffset 0 > setenv SUBJECTS_DIR /Applications/freesurfer/subjects > $Id: mri_label2vol.c,v 1.34.2.5 2012/06/08 17:31:03 greve Exp $ > Template RAS-to-Vox: -------- > -1.000 0.000 0.000 128.000; > -0.000 -0.000 -1.000 128.000; > -0.000 1.000 -0.000 128.000; > 0.000 0.000 0.000 1.000; > Template Voxel Volume: 1 > nHits Thresh: 0 > Loading registration from > /Volumes/Wong_Lab/LabMRIData/FreeSurfer/CMH-8169/bbregister/register.dat > RegMat: -------- > -0.994 -0.098 0.042 0.715; > 0.043 -0.001 0.999 -14.682; > 0.097 -0.995 -0.005 2.026; > 0.000 0.000 0.000 1.000; > Label RAS-to-Vox: -------- > 0.994 0.098 -0.042 127.285; > -0.097 0.995 0.005 125.974; > 0.043 -0.001 0.999 113.318; > 0.000 0.000 0.000 1.000; > ASeg2Vol: Building LUT > ASeg2Vol: Sorting > ASeg2Vol: Mapping > ASeg2Vol: Reverse Map > nmisses = 9739499 (73560 filled) > ASeg2Vol: done > ingvalsons-imac:~ IngvalsonLab$ > > > Is it significant that number of labels = 0? Or is that because I am using > a segmentation volume instead of an actual .label file? > > Other than that, I cannot seem to determine why the output images would be > inverted by 180 degrees. > > Thank you in advance > MP > > > > > On Mon, Aug 5, 2013 at 4:26 PM, Douglas Greve <greve(a)nmr.mgh.harvard.edu>wrote: > >> >> did you look at the registration with tkregister2? When bbregister >> finished, it would have printed out the command line to run (it is also at >> the end of the log file). If that looks ok, please send your bbregister >> command. >> doug >> >> >> On 8/5/13 1:47 PM, Mark Plantz wrote: >> >> Thanks Doug. mri_label2vol worked well, except it looks like all of the >> files are inverted by 90 degrees. They appear inverted in both tkmedit and >> 'FreeView.' I read that inversions are common in "fslview" but not in >> tkmedit. Any idea what could be causing this problem? >> >> My command line is: >> >> *mri_label2vol --seg >> /Volumes/Wong_Lab/CochlearImplant/UNC_NiFTI/infant-1yr-mgz/seg.mgz --temp >> /Users/IngvalsonLab/Desktop/temp.mgz --o seg_new.mgz --reg register.dat* >> * >> * >> I didn't encounter any errors with mri_label2vol nor bbregister [which >> was used to generate register.dat and temp.mgz]. >> >> Any ideas what could be causing this problem? >> >> I can attach more images if this one doesn't portray the inversion well. >> >> Thanks a lot >> >> MP >> >> >> On Mon, Aug 5, 2013 at 10:12 AM, Douglas Greve <greve(a)nmr.mgh.harvard.edu >> > wrote: >> >>> >>> The file that you pass it with the --reg option is the registration file >>> (eg, --reg register.dat). This can be used for input to mri_vol2vol or >>> mri_label2vol. mri_label2vol is appropriate for a segmetation >>> >>> doug >>> >>> >>> >>> On 8/5/13 10:22 AM, Mark Plantz wrote: >>> >>> Thank you. Do you know how to access the transform that is outputted by >>> bbregister. I am just obtaining an output volume <volume.mgz>>? >>> >>> >>> On Thu, Aug 1, 2013 at 3:56 PM, Bruce Fischl < >>> fischl(a)nmr.mgh.harvard.edu> wrote: >>> >>>> Hi Mark >>>> >>>> you can use the transform that bbregister outputs and give it to >>>> mri_convert with -at <transform name> >>>> >>>> cheers >>>> >>>> Bruce >>>> >>>> >>>> On Thu, 1 Aug 2013, Mark Plantz wrote: >>>> >>>> One last question: Is there any flag I can use with 'bbregister' that >>>>> prevents the labels from changing in my segmentation volume? This is >>>>> occuring because the volume that I am moving has labels. For some >>>>> reason, >>>>> the labels change ever so slightly in the output file. >>>>> >>>>> >>>>> On Thu, Aug 1, 2013 at 2:28 PM, Bruce Fischl < >>>>> fischl(a)nmr.mgh.harvard.edu> >>>>> wrote: >>>>> glad it worked out >>>>> Bruce >>>>> On Thu, 1 Aug 2013, Mark Plantz wrote: >>>>> >>>>> Just as an update, it turns out that my segmentation >>>>> volume had been >>>>> slightly altered during the conversion from .nii to >>>>> .mgz. I completely >>>>> forgot to use the -rt nearest flag to prevent the >>>>> labels from becoming >>>>> distorted. That is why the segmentation looked so >>>>> fuzzy with various regions >>>>> labeled incorrectly. >>>>> Apparently, I should check the basics before >>>>> overcomplicating the problem, >>>>> haha. Thanks for the help everyone! >>>>> >>>>> >>>>> On Thu, Aug 1, 2013 at 9:36 AM, Mark Plantz >>>>> <markplantz2016(a)u.northwestern.edu> wrote: >>>>> Sounds good. I also just realized that the >>>>> segmentation values >>>>> are varying from 0-255, which makes me think >>>>> that the file is >>>>> only designed for the grayscale/heat/etc. >>>>> settings [where 0 is >>>>> darkest regions and 255 is brightest regions]. >>>>> Is that a valid >>>>> assumption? Also, if this is the case, would >>>>> it be impossible to >>>>> create a .gca file using mri_ca_train with >>>>> these files? >>>>> Thanks for the help. >>>>> >>>>> MP >>>>> >>>>> >>>>> On Wed, Jul 31, 2013 at 8:43 PM, Douglas Greve >>>>> <greve(a)nmr.mgh.harvard.edu> wrote: >>>>> >>>>> Just make sure that you create a new file and >>>>> do not >>>>> repeat index numbers. >>>>> >>>>> >>>>> On 7/31/13 2:02 PM, Mark Plantz wrote: >>>>> That makes sense. Wouldn't that cause there to >>>>> be >>>>> some overlap between different regions, since >>>>> the >>>>> same index #'s used by the two programs >>>>> (FreeSurfer >>>>> & MRIcro) correspond to different brain >>>>> regions? >>>>> >>>>> >>>>> On Tue, Jul 30, 2013 at 12:50 PM, Douglas Greve >>>>> <greve(a)nmr.mgh.harvard.edu> wrote: >>>>> >>>>> for every line in that file, you will need to >>>>> create a line in the new LUT, something like >>>>> >>>>> >>>>> 8 Frontal_Mid_R 0 255 0 0 >>>>> >>>>> This will make the right mid frontal green = >>>>> (0,255,0) >>>>> >>>>> >>>>> >>>>> >>>>> On 7/30/13 9:55 AM, Mark Plantz wrote: >>>>> Hmm, so I received the text part of the >>>>> LUT. Looks like this is completely >>>>> different from the segmented regions >>>>> that we would want. [attached]. Can't >>>>> seem to understand how this text file >>>>> could be related to the default >>>>> FreeSurfer LUT. It looks like the >>>>> labeling for an AAL map. This probably >>>>> wont' work will it? >>>>> - Mark >>>>> >>>>> >>>>> On Tue, Jul 30, 2013 at 8:47 AM, Bruce Fischl >>>>> <fischl(a)nmr.mgh.harvard.edu> wrote: >>>>> the UNC one? No, you should ask >>>>> them >>>>> On Tue, 30 Jul 2013, Mark Plantz >>>>> wrote: >>>>> >>>>> >>>>> >>>>> ---------- 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 aUNCmedicalgroup< >>>>> http://www.med.unc.edu/bric/ideagroup/free-softwares/unc-in >>>>> fan >>>>> t-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> >>>>> >>>>> 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 b >>>> >>>> ... >> >> [Message clipped] > > >

2 1

J_white
by Linn Mittlestein 06 Aug '13

06 Aug '13

Dear freesurfer experts, I am currently do group analysis in qdec, and I canot select jacobian white from the drop down menu, I thought this would be an option? Do I do have additional steps to get these values? Kind Regards, Linn

3 3

trac-preproc
by Alan Francis 06 Aug '13

06 Aug '13

Hi All: When I ran trac-preproc I got an error that read s as follows: trac-preproc exited with ERRORS at Mon Aug 5 13:12:53 EDT 2013. I do have a bvec.txt and bval file in each directory. thanks for your help, Alan The following are the messages: csh::alanf@cerebro[/autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data] : trac-all -prep -c /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons/dmrirc INFO: SUBJECTS_DIR is /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons INFO: Diffusion root is /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons/ Actual FREESURFER_HOME /autofs/cluster/freesurfer/centos6_x86_64/stable5_3_0 trac-preproc -c /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons//BW_101/scripts/dmrirc.local -log /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons//BW_101/scripts/trac-all.log -cmd /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons//BW_101/scripts/trac-all.cmd #------------------------------------- /usr/local/freesurfer/stable5_3_0//bin/trac-preproc #------------------------------------- #@# Image corrections Mon Aug 5 13:12:10 EDT 2013 mri_convert /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons//BW_101/Diffusion_Recons/20080424_182054563000-000012-000001DTIValeras012a001.nii /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons//BW_101/dmri/dwi_orig.nii.gz mri_convert /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons//BW_101/Diffusion_Recons/20080424_182054563000-000012-000001DTIValeras012a001.nii /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons//BW_101/dmri/dwi_orig.nii.gz $Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $ reading from /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons//BW_101/Diffusion_Recons/20080424_182054563000-000012-000001DTIValeras012a001.nii... TR=7570.00, TE=0.00, TI=0.00, flip angle=0.00 i_ras = (-0.989696, 0.0161603, 0.142271) j_ras = (0.0163, 0.999867, -0.000183368) k_ras = (0.142255, -0.00213754, 0.989828) writing to /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons//BW_101/dmri/dwi_orig.nii.gz... cp /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons/bvecs.txt /autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons//BW_101/dmri/dwi_orig.mghdti.bvecs cp: cannot stat `/autofs/space/dali_003/users/BW_project_DTI/FreeSurfer_5.3_Data/diffusion_recons/bvecs.txt': No such file or directory Linux cerebro 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed Mar 13 00:26:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux trac-preproc exited with ERRORS at Mon Aug 5 13:12:53 EDT 2013

2 6

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