Hi Bruce,
I have tried to convert by using the following commands but still some error occur.
 
UN:~> set subj=/home/naveed/freesurfer/subjects/CHR01/
UN:~> mri_surf2vol --surfval surf/rh.thickness --hemi rh --fillribbon --template mri/orig.mgz --volregidentity {$subj} --outvol {$subj}_rh.ribbon.nii
gdiagno = -1
ERROR: cannot recognize the type of surf/rh.thickness

Can you help me.
Thank you.

Best Regards,
Muhammad Naveed Iqbal Qureshi
 

> Date: Tue, 7 Jan 2014 08:13:45 -0500
> From: fischl@nmr.mgh.harvard.edu
> To: mniqureshi@hotmail.com
> CC: freesurfer@nmr.mgh.harvard.edu
> Subject: Re: [Freesurfer] Freesurfer Digest, Vol 119, Issue 6
>
> Hi Muhammad
>
> have you looked at the help? It's pretty extensive. If you have trouble
> post again and Doug should be able to guide you
>
> cheers
> Bruce
> On Tue, 7 Jan 2014, Muhammad
> Naveed Iqbal Qureshi wrote:
>
> > Thank you Bruce,
> >  
> > Please guide me how can I use mri_surf2vol command on lh/rh.thickness files
> > to get the output as lh/rh.ribbon.nii for AFNI SUMA.
> > Thank you
> >
> > Best Regards,
> > Muhammad Naveed Iqbal Qureshi
> >
> > > From: freesurfer-request@nmr.mgh.harvard.edu
> > > Subject: Freesurfer Digest, Vol 119, Issue 6
> > > To: freesurfer@nmr.mgh.harvard.edu
> > > Date: Mon, 6 Jan 2014 10:51:33 -0500
> > >
> > > Send Freesurfer mailing list submissions to
> > > freesurfer@nmr.mgh.harvard.edu
> > >
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> > > or, via email, send a message with subject or body 'help' to
> > > freesurfer-request@nmr.mgh.harvard.edu
> > >
> > > You can reach the person managing the list at
> > > freesurfer-owner@nmr.mgh.harvard.edu
> > >
> > > When replying, please edit your Subject line so it is more specific
> > > than "Re: Contents of Freesurfer digest..."
> > >
> > >
> > > Today's Topics:
> > >
> > > 1. erroneuos segmentation labeling of skull outside of brain
> > > (Yuliya Yoncheva)
> > > 2. Re: erroneuos segmentation labeling of skull outside of brain
> > > (Bruce Fischl)
> > > 3. Re: Motion correction for SPACE FLAIR (Bruce Fischl)
> > > 4. Re: erroneuos segmentation labeling of skull outside of brain
> > > (Yuliya Yoncheva)
> > > 5. Re: erroneuos segmentation labeling of skull outside of brain
> > > (Bruce Fischl)
> > > 6. Re: recon-all exited w/errors (Bruce Fischl)
> > > 7. ROI masks created in FreeSurfer used in FSL?? (Frank Hsieh)
> > > 8. converting .thickness files of T1 MRI from FreeSurfer into
> > > AFNI (Muhammad Naveed Iqbal Qureshi)
> > > 9. brain orientation in qdec (L. Schweren)
> > > 10. Re: converting .thickness files of T1 MRI from FreeSurfer
> > > into AFNI (Bruce Fischl)
> > > 11. recon-all error (Emad Ahmadi)
> > > 12. Fwd: Anatomical segmentation - question (Rotem Saar)
> > >
> > >
> > > ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Sun, 5 Jan 2014 15:14:39 -0500
> > > From: Yuliya Yoncheva <yuliya.yoncheva@gmail.com>
> > > Subject: [Freesurfer] erroneuos segmentation labeling of skull outside
> > > of brain
> > > To: freesurfer@nmr.mgh.harvard.edu
> > > Message-ID:
> > > <CAGE5uFc2uD9pMefXjRZE0LQP+GcfhHKWeVkHxOGwDzV1=jYrQA@mail.gmail.com>
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > > Dear FreeSurfer community,
> > >
> > > I am visually inspecting the quality of my recon -all output for a large
> > > dataset and have a rookie question.
> > >
> > > In some instances, when skull stripping ended up leaving some of the
> > skull,
> > > these voxels are associated with a "sgmtn label" (cerebral cortex). In
> > > other instances, although there are a small number of skull voxels that
> > > were not removed automatically, these voxels do not have an associated
> > > "sgmnt label" available in TkMedit Tools.
> > >
> > > Is it the case that only the voxels for which there is a segmentation
> > label
> > > are actually added to the total grey volume estimate?
> > >
> > > Thus, voxels, which have not been automatically labelled would not impact
> > > volume computations?
> > >
> > > Thank you kindly for your help.
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL:http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20140105/3
> > 92deba7/attachment-0001.html
> > > -------------- next part --------------
> > > A non-text attachment was scrubbed...
> > > Name: ExCerCor.png
> > > Type: image/png
> > > Size: 81100 bytes
> > > Desc: not available
> > > Url :http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20140105/3
> > 92deba7/attachment-0001.png
> > >
> > > ------------------------------
> > >
> > > Message: 2
> > > Date: Sun, 5 Jan 2014 15:40:24 -0500 (EST)
> > > From: Bruce Fischl <fischl@nmr.mgh.harvard.edu>
> > > Subject: Re: [Freesurfer] erroneuos segmentation labeling of skull
> > > outside of brain
> > > To: Yuliya Yoncheva <yuliya.yoncheva@gmail.com>
> > > Cc: freesurfer@nmr.mgh.harvard.edu
> > > Message-ID: <alpine.LRH.2.03.1401051539450.16518@nmr.mgh.harvard.edu>
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > > Hi Yuliya
> > >
> > > they are included if they are inside of the ?h.pial surface. We don't use
> > > the cortex aseg label as it is in general less accurate than the surfaces.
> > >
> > > cheers
> > > Bruce
> > > On Sun, 5 Jan 2014, Yuliya Yoncheva wrote:
> > >
> > > > Dear FreeSurfer community,
> > > > I am visually inspecting the quality of my recon -all output for a large
> > > > dataset and have a rookie question.
> > > >
> > > > In some instances, when skull stripping ended up leaving some of the
> > skull,
> > > > these voxels are associated with a "sgmtn label" (cerebral cortex). In
> > other
> > > > instances, although there are a small number of skull voxels that were
> > not
> > > > removed automatically, these voxels do not have an associated "sgmnt
> > label"
> > > > available in TkMedit Tools.
> > > >
> > > > Is it the case that only the voxels for which there is a segmentation
> > label
> > > > are actually added to the total grey volume estimate??
> > > >
> > > > Thus, voxels, which have not been automatically labelled would not
> > impact
> > > > volume computations?
> > > >
> > > > Thank you kindly for your help.
> > > >
> > > >
> > >
> > > ------------------------------
> > >
> > > Message: 3
> > > Date: Sun, 5 Jan 2014 15:55:13 -0500 (EST)
> > > From: Bruce Fischl <fischl@nmr.mgh.harvard.edu>
> > > Subject: Re: [Freesurfer] Motion correction for SPACE FLAIR
> > > To: Octavian Lie <octavian.lie@gmail.com>
> > > Cc: "freesurfer@nmr.mgh.harvard.edu" <freesurfer@nmr.mgh.harvard.edu>
> > > Message-ID: <alpine.LRH.2.03.1401051554470.16518@nmr.mgh.harvard.edu>
> > > Content-Type: text/plain; charset="windows-1252"
> > >
> > > Hi Octavian
> > >
> > > it's not so easy to reduce the bandwidth in the T2-space sequences, but
> > > certainly you can try. Geometry-matched just means that the FOV and
> > > matrix sizes are the same.
> > >
> > > cheers
> > > Bruce
> > > On Fri, 3 Jan 2014, Octavian Lie wrote:
> > >
> > > > Dear Bruce,
> > > >
> > > > Best wishes for 2014!
> > > >
> > > > I will heed your advice and cc to the list. Indeed, the MGH protocol I
> > > > obtained from Andre has one acquisition (NSA).
> > > > Related, I cc this post:
> > > >
> > > > We have been trying adaptations of the T2spaceFLAIR MGH protocol on
> > > > our Phillips 3T scanners (sequences called VISTA). Incorporation of
> > > > the T2 space FLAIR has been mostly successful at editing out the dura
> > > > from the pial surface. The only concern are minute differences
> > > > occasionally appearing as small indentations (at most times <1-2mm)
> > > > between the woFLAIR.pial and the final pial surfaces, including in
> > > > intrasulcal (duraless) areas; the amount of these small mismatches is
> > > > variable from patient to patients, with some trials with almost
> > > > perfect overlap, and others with visible, if small, differences. I
> > > > wonder if this has been your experience too, and if this is due mostly
> > > > to bb registration limits or to differences in pixel bandwidth between
> > > > mprage and space flair sequences (in our case, see below).
> > > > In FSwiki, the recommendation is that T2 space flair ?should be
> > > > bandwidth, geometry and readout matched to the mprage?.
> > > >
> > > > 1. Speaking about pixel bandwidth, logistics most likely would not
> > > > allow application of a MEMPR sequence on our Phillips. According to
> > > > Siemens MPRAGE MGH specs, "exceptions indicate that if a multiple echo
> > > > sequence is not available, one should choose a bandwidth of 195
> > > > Hz/pixel for the MPRAGE". In that case/ using the Siemens Trio MPRAGE
> > > > protocol as if the MEMPR is not available, how one would adjust the
> > > > bandwidth in T2spaceFLAIR protocol (currently ~650 in the Siemens
> > > > space flair and MEMPR protocols) to "match" it to the "simple" MPRAGE
> > > > protocol (decreasing it to 195 ?). Would it be a workaround? (Please
> > > > comment on the Siemens case, obviously, I do not expect any light on
> > > > Phillips without further testing).
> > > > 2. Could you clarify what geometry matched means?
> > > > Please advise,
> > > >
> > > > Thank you,
> > > >
> > > > Octavian
> > > >
> > > > On Fri, Jan 3, 2014 at 9:12 PM, Bruce Fischl
> > <fischl@nmr.mgh.harvard.edu> wrote:
> > > >> Hi Octavian
> > > >>
> > > >> can you cc the list so that others can answer? What is NSA? We don't
> > have a
> > > >> ton of experience with it, but 1 has seemed ok (not sure if we've ever
> > tried
> > > >> two)
> > > >> Bruce
> > > >>
> > > >>
> > > >>
> > > >> On Thu, 2 Jan 2014, Octavian Lie wrote:
> > > >>
> > > >>> Dear Bruce,
> > > >>>
> > > >>> Thank you. We used one vs 2 NSA T2 space FLAIR sequences, without a
> > > >>> consistent difference in results, with the 2-NSA run obviously
> > doubling
> > > >>> the
> > > >>> scan time. Is there a preferred number of NSA you recommend, or we
> > should
> > > >>> be
> > > >>> fine with one? Both are at resolution 1X1X1 mm.
> > > >>> Thank you,
> > > >>>
> > > >>> Octavian
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Thu, Jan 2, 2014 at 11:56 AM, Bruce Fischl
> > <fischl@nmr.mgh.harvard.edu>
> > > >>> wrote:
> > > >>> Hi Octaviaan
> > > >>> no, not really. You should motion correct and average them using
> > > >>> something like mri_motion_correct*
> > > >>>
> > > >>> We do typically bandwidth/readout match them to the memprages so
> > > >>> that there is no differential distortion
> > > >>>
> > > >>> cheers
> > > >>> Bruce
> > > >>>
> > > >>>
> > > >>> On Wed, 1 Jan 2014, Octavian Lie wrote:
> > > >>>
> > > >>> Dear All,
> > > >>>
> > > >>> We recently implemented pial correction using T2
> > > >>> space FLAIR with freesurfer
> > > >>> v 5.3, mostly successfully. We use 2-3 MPRAGE
> > > >>> (sagittal + axial and/or
> > > >>> coronal) volumes as 001.mgz, 002/003.mgz for the
> > > >>> motion correction step in
> > > >>> recon-all pipeline.
> > > >>> The typical times for acquiring space FLAIR in our
> > > >>> settings vary from 2.5 to
> > > >>> 6 min, depending on the resolution/NSA no. I was
> > > >>> wondering how freesurfer
> > > >>> deals with motion artifacts in the space FLAIR
> > > >>> sequence (especially with
> > > >>> longer acquisition times), and if there is a
> > > >>> strategy to minimize motion
> > > >>> distortion with these (such as getting second runs
> > > >>> for averaging, etc).
> > > >>> Please advise,
> > > >>>
> > > >>> Octavian.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> 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.
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >
> > > >
> > > >
> > >
> > > ------------------------------
> > >
> > > Message: 4
> > > Date: Sun, 5 Jan 2014 19:25:53 -0500
> > > From: Yuliya Yoncheva <yuliya.yoncheva@gmail.com>
> > > Subject: Re: [Freesurfer] erroneuos segmentation labeling of skull
> > > outside of brain
> > > To: Bruce Fischl <fischl@nmr.mgh.harvard.edu>
> > > Cc: freesurfer@nmr.mgh.harvard.edu
> > > Message-ID:
> > > <CAGE5uFcchoLxBvaf5Lze9z9_QPU4NGa83WFwZ90auZX3-idsFg@mail.gmail.com>
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > > Hello Bruce,
> > >
> > > thank you very much for your fast response and clarifying that potential
> > > voxels outside the pial surface do not impact cortical measures.
> > >
> > > Best,
> > > Yuliya
> > >
> > >
> > >
> > > On Sun, Jan 5, 2014 at 3:40 PM, Bruce Fischl
> > <fischl@nmr.mgh.harvard.edu>wrote:
> > >
> > > > Hi Yuliya
> > > >
> > > > they are included if they are inside of the ?h.pial surface. We don't
> > use
> > > > the cortex aseg label as it is in general less accurate than the
> > surfaces.
> > > >
> > > > cheers
> > > > Bruce
> > > >
> > > > On Sun, 5 Jan 2014, Yuliya Yoncheva wrote:
> > > >
> > > > Dear FreeSurfer community,
> > > >> I am visually inspecting the quality of my recon -all output for a
> > large
> > > >> dataset and have a rookie question.
> > > >>
> > > >> In some instances, when skull stripping ended up leaving some of the
> > > >> skull,
> > > >> these voxels are associated with a "sgmtn label" (cerebral cortex). In
> > > >> other
> > > >> instances, although there are a small number of skull voxels that were
> > not
> > > >> removed automatically, these voxels do not have an associated "sgmnt
> > > >> label"
> > > >> available in TkMedit Tools.
> > > >>
> > > >> Is it the case that only the voxels for which there is a segmentation
> > > >> label
> > > >> are actually added to the total grey volume estimate?
> > > >>
> > > >> Thus, voxels, which have not been automatically labelled would not
> > impact
> > > >> volume computations?
> > > >>
> > > >> Thank you kindly for your help.
> > > >>
> > > >>
> > > >>
> > > >
> > > > 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.
> > > >
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL:http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20140105/e
> > c136ff2/attachment-0001.html
> > >
> > > ------------------------------
> > >
> > > Message: 5
> > > Date: Sun, 5 Jan 2014 20:29:06 -0500 (EST)
> > > From: Bruce Fischl <fischl@nmr.mgh.harvard.edu>
> > > Subject: Re: [Freesurfer] erroneuos segmentation labeling of skull
> > > outside of brain
> > > To: Yuliya Yoncheva <yuliya.yoncheva@gmail.com>
> > > Cc: freesurfer@nmr.mgh.harvard.edu
> > > Message-ID: <alpine.LRH.2.03.1401052028520.16518@nmr.mgh.harvard.edu>
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > > exactly, or measures derived them them like whole-brain volume
> > >
> > > cheers
> > > Bruce
> > >
> > > On Sun, 5 Jan 2014, Yuliya
> > > Yoncheva wrote:
> > >
> > > > Hello Bruce,
> > > > thank you very much for your fast response and clarifying that potential
> > > > voxels outside the pial surface do not impact cortical measures.
> > > >
> > > > Best,?
> > > > Yuliya
> > > >
> > > >
> > > >
> > > > On Sun, Jan 5, 2014 at 3:40 PM, Bruce Fischl
> > <fischl@nmr.mgh.harvard.edu>
> > > > wrote:
> > > > Hi Yuliya
> > > >
> > > > they are included if they are inside of the ?h.pial surface. We
> > > > don't use the cortex aseg label as it is in general less
> > > > accurate than the surfaces.
> > > >
> > > > cheers
> > > > Bruce
> > > > On Sun, 5 Jan 2014, Yuliya Yoncheva wrote:
> > > >
> > > > Dear FreeSurfer community,
> > > > I am visually inspecting the quality of my recon
> > > > -all output for a large
> > > > dataset and have a rookie question.
> > > >
> > > > In some instances, when skull stripping ended up
> > > > leaving some of the skull,
> > > > these voxels are associated with a "sgmtn label"
> > > > (cerebral cortex). In other
> > > > instances, although there are a small number of
> > > > skull voxels that were not
> > > > removed automatically, these voxels do not have an
> > > > associated "sgmnt label"
> > > > available in TkMedit Tools.
> > > >
> > > > Is it the case that only the voxels for which there
> > > > is a segmentation label
> > > > are actually added to the total grey volume
> > > > estimate??
> > > >
> > > > Thus, voxels, which have not been automatically
> > > > labelled would not impact
> > > > volume computations?
> > > >
> > > > Thank you kindly for your help.
> > > >
> > > >
> > > >
> > > >
> > > > 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.
> > > >
> > > >
> > > >
> > > >
> > >
> > > ------------------------------
> > >
> > > Message: 6
> > > Date: Sun, 5 Jan 2014 20:50:51 -0500 (EST)
> > > From: Bruce Fischl <fischl@nmr.mgh.harvard.edu>
> > > Subject: Re: [Freesurfer] recon-all exited w/errors
> > > To: "Boric, Katica A." <KBORIC@mgh.harvard.edu>
> > > Cc: "freesurfer@nmr.mgh.harvard.edu" <freesurfer@nmr.mgh.harvard.edu>
> > > Message-ID: <alpine.LRH.2.03.1401052049480.16518@nmr.mgh.harvard.edu>
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > > Hi Katica
> > >
> > > what format was the input image to recon-all? Can you verify that tkmedit
> > > has the directions correct (that is what it labels as anterior is actually
> > > anatomically anterior, etc...). If so, then the talairach just failed and
> > > you will need to either try an alternative (like the MNI or SPM
> > talairachs)
> > > or generate it manually.
> > >
> > > cheers
> > > Bruce
> > >
> > >
> > >
> > > On Thu, 2 Jan 2014, Boric, Katica A.
> > > wrote:
> > >
> > > > Happy New Year freesuerfers!
> > > > I run into this error while doing?recon-all :
> > > >
> > > > ERROR: talairach_afd: Talairach Transform: transforms/talairach.xfm
> > > > ***FAILED*** (p=0.0000, pval=0.0000 < threshold=0.0050)
> > > > Manual Talairach alignment may be necessary, or
> > > > include the -notal-check flag to skip this test,
> > > > making sure the -notal-check flag follows -all
> > > > or -autorecon1 in the command string.
> > > >
> > > > I would really appreciate if someone could give me some advice on how to
> > fix
> > > > this error.
> > > >
> > > > Thank you very much!
> > > >
> > > > Katica Boric,
> > > >
> > > >
> > > > ps:?Here is the error log:
> > > >
> > > > #@# Talairach Failure Detection Thu Jan ?2 14:20:32 EST 2014
> > > > /home/XX/XXX/subjects/XXX_SurferOutput/mri
> > > >
> > > > ?talairach_afd -T 0.005 -xfm transforms/talairach.xfm?
> > > >
> > > > ERROR: talairach_afd: Talairach Transform: transforms/talairach.xfm
> > > > ***FAILED*** (p=0.0000, pval=0.0000 < threshold=0.0050)
> > > > INFO: Attempting MINC mritotal to perform Talairach align
> > > > #--------------------------------------------
> > > > #@# Talairach Thu Jan ?2 14:20:33 EST 2014
> > > > /home/XX/XXX/subjects/XXX_SurferOutput/mri
> > > >
> > > > ?mri_nu_correct.mni --n 1 --proto-iters 1000 --distance 50 --no-rescale
> > --i
> > > > orig.mgz --o orig_nu.mgz?
> > > >
> > > >
> > > > ?talairach --i orig_nu.mgz --xfm transforms/talairach.auto.xfm?
> > > >
> > > > /home/XX/XXX/subjects/XXX_SurferOutput/mri
> > > > /usr/local/freesurfer/bin/talairach
> > > > --i orig_nu.mgz --xfm transforms/talairach.auto.xfm
> > > > $Id: talairach,v 1.7 2011/03/02 20:16:40 nicks Exp $
> > > > Linux localhost.localdomain 3.6.11-4.fc16.x86_64 #1 SMP Tue Jan 8
> > 20:57:42
> > > > UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> > > > Thu Jan ?2 14:21:30 EST 2014
> > > > tmpdir is transforms/tmp.talairach.34005
> > > > /home/XX/XXX/subjects/XXX_SurferOutput/mri
> > > > mri_convert orig_nu.mgz transforms/tmp.talairach.34005/src.mnc
> > > > mri_convert orig_nu.mgz transforms/tmp.talairach.34005/src.mnc?
> > > > $Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $
> > > > reading from orig_nu.mgz...
> > > > TR=8.23, TE=3.22, TI=450.00, flip angle=12.00
> > > > i_ras = (-1, -9.03383e-08, 0)
> > > > j_ras = (-1.3411e-07, 2.66591e-08, -1)
> > > > k_ras = (1.59256e-07, 1, -5.93718e-09)
> > > > writing to transforms/tmp.talairach.34005/src.mnc...
> > > > --------------------------------------------
> > > > mritotal -verbose -debug -clobber -modeldir
> > > > /usr/local/freesurfer/mni/bin/../share/mni_autoreg -protocol icbm
> > > > transforms/tmp.talairach.34005/src.mnc transforms/talairach.auto.xfm
> > > > Legacy library shellwords.pl will be removed from the Perl core
> > distribution
> > > > in the next major release. Please install it from the CPAN distribution
> > > > Perl4::CoreLibs. It is being used at
> > /usr/local/freesurfer/mni/bin/mritotal,
> > > > line 460.
> > > > ?
> > > > ?
> > > > Thu Jan ?2 14:21:43 EST 2014
> > > > talairach done
> > > >
> > > > ?cp transforms/talairach.auto.xfm transforms/talairach.xfm?
> > > >
> > > > #--------------------------------------------
> > > > #@# Talairach Failure Detection Thu Jan ?2 14:21:44 EST 2014
> > > > /home/XX/XXX/subjects/XXX_SurferOutput/mri
> > > >
> > > > ?talairach_afd -T 0.005 -xfm transforms/talairach.xfm?
> > > >
> > > > ERROR: talairach_afd: Talairach Transform: transforms/talairach.xfm
> > > > ***FAILED*** (p=0.0000, pval=0.0000 < threshold=0.0050)
> > > > Manual Talairach alignment may be necessary, or
> > > > include the -notal-check flag to skip this test,
> > > > making sure the -notal-check flag follows -all
> > > > or -autorecon1 in the command string.
> > > > See http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/Talairach
> > > > Linux localhost.localdomain 3.6.11-4.fc16.x86_64 #1 SMP Tue Jan 8
> > 20:57:42
> > > > UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> > > >
> > > > recon-all -s xxx_SurferOutput exited with ERRORS at Thu Jan ?2 14:21:45
> > EST
> > > > 2014
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > ------------------------------
> > >
> > > Message: 7
> > > Date: Sun, 5 Jan 2014 23:35:55 -0800
> > > From: Frank Hsieh <two.frank@gmail.com>
> > > Subject: [Freesurfer] ROI masks created in FreeSurfer used in FSL??
> > > To: freesurfer@nmr.mgh.harvard.edu
> > > Message-ID:
> > > <CABBeRCEt37ZwE1-jHuZGC3Vw-D_v2+svOAnQUcSP6kW37qT4oQ@mail.gmail.com>
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > > Dear FreeSurfer Users,
> > >
> > > I ran recon -all on my structural image and created ROI masks (using
> > > mri_label2vol) based on FreeSurfer's cortical parcellation. I'd like to
> > use
> > > these masks for further analysis with FSL. However, it seems that the ROI
> > > masks generated with mri_label2vol have different header information than
> > > that of the original structural image. As a result, I was unable to carry
> > > out further analysis with FSL (e.g., converting these ROI masks into
> > > functional space with hires2example_func.mat). I was wondering if there is
> > > a way to solve this issue.
> > >
> > > Many thanks in advance.
> > > Frank
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL:http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20140105/a
> > 552481b/attachment-0001.html
> > >
> > > ------------------------------
> > >
> > > Message: 8
> > > Date: Mon, 6 Jan 2014 17:11:54 +0900
> > > From: Muhammad Naveed Iqbal Qureshi <mniqureshi@hotmail.com>
> > > Subject: [Freesurfer] converting .thickness files of T1 MRI from
> > > FreeSurfer into AFNI
> > > To: "freesurfer@nmr.mgh.harvard.edu" <freesurfer@nmr.mgh.harvard.edu>
> > > Message-ID: <BLU174-W27296B6C59F4D34F89293AC4B70@phx.gbl>
> > > Content-Type: text/plain; charset="ks_c_5601-1987"
> > >
> > > Hi,
> > > I want to know that how can I convert FreeSurfer .thickness files to AFNI
> > readable format
> > > I tried the following Command but it gives error
> > >
> > >
> > > mri_convert /home/naveed/freesurfer/subjects/CHR01/surf/rh.thickness
> > /media/Freesurfer_Data/Processed/AFNI_format/CHR/CHR01/rh.brik
> > > $Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $
> > > reading from /home/naveed/freesurfer/subjects/CHR01/surf/rh.thickness...
> > > TR=0.00, TE=0.00, TI=0.00, flip angle=0.00
> > > i_ras = (-1, 0, 0)
> > > j_ras = (0, 0, -1)
> > > k_ras = (0, 1, 0)
> > > writing to
> > /media/Freesurfer_Data/Processed/AFNI_format/CHR/CHR01/rh.brik...
> > > AFNI BRIK write unsupported
> > > ERROR: failure writing
> > /media/Freesurfer_Data/Processed/AFNI_format/CHR/CHR01/rh.brik
> > > UN:/media>
> > >
> > > Please let me help me to solve this problem
> > > Thank you :)
> > >
> > >
> > >
> > > Best Regards,
> > >
> > > Muhammad
> > > Naveed Iqbal Qureshi
> > >
> > >
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL:http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20140106/1
> > d3fe803/attachment-0001.html
> > >
> > > ------------------------------
> > >
> > > Message: 9
> > > Date: Mon, 6 Jan 2014 10:45:52 +0100
> > > From: "L. Schweren" <l.j.s.schweren@umcg.nl>
> > > Subject: [Freesurfer] brain orientation in qdec
> > > To: <freesurfer@nmr.mgh.harvard.edu>
> > > Message-ID: <005601cf0ac4$16bda9b0$4438fd10$@umcg.nl>
> > > Content-Type: text/plain; charset="us-ascii"
> > >
> > > Dear experts,
> > >
> > >
> > >
> > > I ran recon-all with qcache. When loading the right hemisphere of
> > fsaverage
> > > (or any other surface reconstruction) into tksurfer (for example command:
> > > tksurfer fsaverage rh white), the left hemisphere surface is displayed,
> > and
> > > it is upside down. When I import annotations they load in the same
> > > orientation as the surface. However, the coordinates and the labels,
> > > displayed in the Tksurfer Tools window, are not. For example, when I move
> > > the cursor to the temporal lobe, the label says it's postcentral. I do not
> > > mind manually turning the surfaces in tksurfer, but I do need to be sure I
> > > am looking at the correct hemispheres, coordinates and labels.
> > >
> > > I hope you can help me solve this. Thank you in advance.
> > >
> > >
> > >
> > > Best wishes,
> > >
> > > Lizanne
> > >
> > >
> > >
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL:http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20140106/5
> > 583e136/attachment-0001.html
> > >
> > > ------------------------------
> > >
> > > Message: 10
> > > Date: Mon, 6 Jan 2014 08:41:58 -0500 (EST)
> > > From: Bruce Fischl <fischl@nmr.mgh.harvard.edu>
> > > Subject: Re: [Freesurfer] converting .thickness files of T1 MRI from
> > > FreeSurfer into AFNI
> > > To: Muhammad Naveed Iqbal Qureshi <mniqureshi@hotmail.com>
> > > Cc: "freesurfer@nmr.mgh.harvard.edu" <freesurfer@nmr.mgh.harvard.edu>
> > > Message-ID: <alpine.LRH.2.03.1401060840550.16518@nmr.mgh.harvard.edu>
> > > Content-Type: text/plain; charset="iso-8859-15"
> > >
> > > Hi Muhammad
> > >
> > > try:
> > >
> > > set sdir=/home/naveed/freesurfer/subjects/CHR01/surf
> > > mris_convert -c $sdir/rh.thickness $sdir/rh.orig $sdir/rh.thickness.brik
> > >
> > > cheers
> > > Bruce
> > >
> > > On Mon, 6 Jan 2014, Muhammad Naveed Iqbal Qureshi wrote:
> > >
> > > > Hi,
> > > > I want to know that how can I convert FreeSurfer .thickness files to
> > AFNI
> > > > readable format
> > > > I tried the following Command but it gives error
> > > >
> > > >
> > > > mri_convert /home/naveed/freesurfer/subjects/CHR01/surf/rh.thickness
> > > > /media/Freesurfer_Data/Processed/AFNI_format/CHR/CHR01/rh.brik
> > > > $Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $
> > > > reading from /home/naveed/freesurfer/subjects/CHR01/surf/rh.thickness...
> > > > TR=0.00, TE=0.00, TI=0.00, flip angle=0.00
> > > > i_ras = (-1, 0, 0)
> > > > j_ras = (0, 0, -1)
> > > > k_ras = (0, 1, 0)
> > > > writing to
> > /media/Freesurfer_Data/Processed/AFNI_format/CHR/CHR01/rh.brik...
> > > > AFNI BRIK write unsupported
> > > > ERROR: failure writing
> > > > /media/Freesurfer_Data/Processed/AFNI_format/CHR/CHR01/rh.brik
> > > > UN:/media>
> > > >
> > > > Please let me help me to solve this problem
> > > > Thank you :)?
> > > >
> > > > Best Regards,
> > > > Muhammad Naveed Iqbal Qureshi
> > > >
> > > >
> > >
> > > ------------------------------
> > >
> > > Message: 11
> > > Date: Mon, 6 Jan 2014 10:40:43 -0500 (EST)
> > > From: "Emad Ahmadi" <emad@nmr.mgh.harvard.edu>
> > > Subject: [Freesurfer] recon-all error
> > > To: freesurfer@nmr.mgh.harvard.edu
> > > Message-ID: <63234.172.19.2.113.1389022843.squirrel@mail.martinos.org>
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > > Hello & Happy New Year!
> > >
> > > I'm running recon-all for one subject on MGH clusters (ERISone), and it
> > > exits with error. I would appreciate it if you help me figure out what the
> > > problem is. The log file is attached.
> > >
> > > All the best throughout 2014!
> > > Emad
> > >
> > >
> > > Emad Ahmadi, MD
> > > ------------------------------------------------
> > > Research Fellow
> > > Department of Radiology
> > > Massachusetts General Hospital
> > > Harvard Medical School
> > >
> > > 25 New Chardon Street, Suite 400
> > > Boston, MA 02114
> > > Tel: 617 726 5237
> > > Email: emad@nmr.mgh.harvard.edu
> > >
> > > -------------- next part --------------
> > > A non-text attachment was scrubbed...
> > > Name: recon-all.log
> > > Type: application/octet-stream
> > > Size: 20022 bytes
> > > Desc: not available
> > > Url :http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20140106/e
> > 6358cca/attachment-0002.obj
> > > -------------- next part --------------
> > > A non-text attachment was scrubbed...
> > > Name: recon1job.bash
> > > Type: application/octet-stream
> > > Size: 1555 bytes
> > > Desc: not available
> > > Url :http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20140106/e
> > 6358cca/attachment-0003.obj
> > >
> > > ------------------------------
> > >
> > > Message: 12
> > > Date: Mon, 6 Jan 2014 17:51:18 +0200
> > > From: Rotem Saar <saar.rotem@gmail.com>
> > > Subject: [Freesurfer] Fwd: Anatomical segmentation - question
> > > To: freesurfer@nmr.mgh.harvard.edu
> > > Message-ID:
> > > <CAMjFEmbcEwbXMOyxw-kuep6NSzdnk=rYHSEvwPGSbiXkBZKxtA@mail.gmail.com>
> > > Content-Type: text/plain; charset="windows-1252"
> > >
> > > Dear freesurfer experts,
> > >
> > > I'm performing anatomical segmentation for Philips dicoms (3T scanner). I
> > > got these two images from the same slice while performing step number 4 in
> > > the script below ? from some reason, the two images don't fit. Should I
> > use
> > > "scale brain" ? I know this is not recommended thus want to consult with u
> > > first ? Can u please comment on why this is happening? Is there any value
> > > that corresponds to "how good is the segmentation" ? if yes, where can I
> > > find it ?
> > >
> > > My script is written below.
> > >
> > > Thanks,
> > >
> > > Rotem
> > >
> > > Anatomical segmentation:
> > >
> > > first step- 23 hours:
> > >
> > > *recon-all -autorecon-all -i ~/Desktop/ FOLDER-NAME /I00001.dcm -s
> > > FOLDER-NAME*
> > >
> > > second step:(gyrus=green, sulcus=red)
> > >
> > > *tksurfer -curv FOLDER-NAME lh/rh inflated*
> > >
> > > third step: (talairch registretion)
> > >
> > > *tkmedit FOLDER-NAME brainmask.mgz*
> > >
> > > File-> transforms-> load transform AUX-> Browse-> talairch.xfm
> > >
> > > forth step: (simetry - allows changing 12df transformation. if we made any
> > > changes we should click "save reg" and run this command again)
> > >
> > > *tkregister2 --mgz --s FOLDER-NAME --fstal --surf orig*
> > >
> > > IF WE CHANGE ANYTHING, CLICK "SAVE REG" AND RUN FROM STARTING POING:
> > > recon-all -all -subjectid FOLDER-NAME
> > >
> > > fifth step: (scalp removal: if removed too much, rise up from the value
> > 25:
> > >
> > > *recon-all -skullstrip -wsthresh 25 -clean-bm -no-wsgcaatlas -s
> > > FOLDER-NAME *
> > >
> > > to check the result press: *tkmedit FOLDER-NAME brainmask.mgz lh.white
> > -aux
> > > T1.mgz -aux-surface rh.white *)
> > >
> > > for hand correction: *tkmedit FOLDER-NAME brainmask.mgz -aux T1.mgz*
> > >
> > > tools-> configure volume brush -> MARK: mode=clone, source=Aux
> > >
> > > tools-> configure brush info (for choosing brush size)
> > >
> > > click on edit voxels: click in MIDDLE for adding voxels, RIGHT for
> > removing
> > > voxels : slice by slice.
> > >
> > > when finish, click: File-> save main volume
> > >
> > > sisxt step: (cp for correcting segmentation)
> > >
> > > *tkmedit FOLDER-NAME brainmask.mgz lh.white -aux T1.mgz -aux-surface
> > > rh.white*
> > >
> > > seventh step: (done)
> > >
> > > *recon-all -autorecon2-cp -autorecon3 -s FOLDER-NAME*
> > >
> > >
> > >
> > >
> > >
> > > Rotem Saar-Ashkenazy
> > > Department of Brain and Cognitive Science
> > > Ben Gurion University of the Negev
> > > Beer-Sheva 84105
> > > Israel
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL:http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20140106/3
> > df4f7b3/attachment.html
> > > -------------- next part --------------
> > > A non-text attachment was scrubbed...
> > > Name: 3.png
> > > Type: image/png
> > > Size: 299694 bytes
> > > Desc: not available
> > > Url :http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20140106/3
> > df4f7b3/attachment.png
> > >
> > > ------------------------------
> > >
> > > _______________________________________________
> > > Freesurfer mailing list
> > > Freesurfer@nmr.mgh.harvard.edu
> > > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> > >
> > > End of Freesurfer Digest, Vol 119, Issue 6
> > > ******************************************
> >
> >