[Freesurfer] orientation in freeview

[Zhewei Wang]

Hi all,

I have a problem maybe relevant to the orientation of images in freeview. I
have two images, one is fMRI and one is MRI. They are produced from the
same machine at the same time. I loaded both of them in freeview and it
showed they are matched very well, even they have different resolutions,
different orientation (fMRI is LAS and MRI is PSR), different sform and
qform. I registrated MRI to MNI152, and a transformation matrix is
generated. I apply this matrix on fMRI, then I got the wrong result: I
loaded the fMRI after transformation and MNI152 in freeview, they are not
matched. I use *flirt* for registration.

Can anyone explain to me why it happened? At beginning they are shown
matched in freeview, even they have different orientation. After apply same
transformation, they are shown not matched in freeview even they have same
orientation now (both are LAS).

Thank you so much.


Zhewei
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Topup before trac-all

[Yendiki, Anastasia]

Hi - Running topup is not a problem. Just make sure that there's as many 
entries in the gradient table and b-value table as there are frames in the DWI 
file. So if with topup you're combining 2 sets of DWIs (collected with opposite 
phase-encode directions), you also have to combine the corresponding gradient 
vectors and b-values.


From: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Knut J Bjuland 
[knutjor...@outlook.com]
Sent: Thursday, February 09, 2017 4:57 PM
To: freesurfer@nmr.mgh.harvard.edu
Subject: [Freesurfer] Topup before trac-all

Hi,

I would like to preprocess my dti data with topup (from FSL) before running 
trac-all. Is this a sensible approach? When I tried  running trac-all -prep 
with the output file from topup (*_hifi_nodif.nii.gz) I got an error message:


mv -f /usit/abel/<>/topuop/146/dmri/bvecs 
/usit/abel/<...>/topuop/146/dmri/bvecs.norot
xfmrot /usit/abel/<...>/topuop/146/dmri/dwi.ecclog 
/usit/abel/<...>topuop/146/dmri/bvecs.norot 
/usit/abel/<...>/topuop/146/dmri/bvecs

R: Subscript out of range.



It seems that there's a problem with bvecs and bvals. Should I reorganise my 
bvec and bvals?


Thank you!


Knut J Bjuland
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Freesurfer] Control points and WM edits

[miracooloz]

 Hello Freesurfer, I played around with mri_normalize for control point section by changing the parameters using -b 20 or 23 and writing it in an expert file. However, when I ran recon-all -autorecon2-cp -autorecon3 -expert expert.opts, the command showed "mri_normalize - mprage -noconform ) see screenshot attached.   ‎Shouldn't -b 23 replace  -noconform? That's "mri_normalize -mprage -b 23 " not " mri_normalize -mprage -noconform ". ‎Second question, if I add control points and make white matter edits, should I start recon-all at autorecon2-cp or autorecon2-wm?  Thanks Best, Paul Sent from my BlackBerry 10 smartphone.

Image.PNG
Description: Binary data
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Freesurfer] Topup before trac-all

[Knut J Bjuland]

Hi,

I would like to preprocess my dti data with topup (from FSL) before running 
trac-all. Is this a sensible approach? When I tried  running trac-all -prep 
with the output file from topup (*_hifi_nodif.nii.gz) I got an error message:


mv -f /usit/abel/<>/topuop/146/dmri/bvecs 
/usit/abel/<...>/topuop/146/dmri/bvecs.norot
xfmrot /usit/abel/<...>/topuop/146/dmri/dwi.ecclog 
/usit/abel/<...>topuop/146/dmri/bvecs.norot 
/usit/abel/<...>/topuop/146/dmri/bvecs

R: Subscript out of range.



It seems that there's a problem with bvecs and bvals. Should I reorganise my 
bvec and bvals?


Thank you!


Knut J Bjuland
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] mrisComputeCorrelationTerm: delta is not finite at vno 0

[Douglas Merkitch]

The same thing happened to me on my mac when I changed the FREESURFER_HOME 
variable in the terminal, but not in the .bashrc file that I source when the 
terminal opens.

Hope this helps!

Thanks,

Doug

Douglas Merkitch
Neurological Sciences
Rush University Medical Center



On Feb 9, 2017, at 1:49 PM, 
zkauf...@nmr.mgh.harvard.edu wrote:

Hello Juhyoung,

If its complaining about "RB_all_2008-03-26.gca" then something must have
happened where you still have portions of the old freesurfer installed, or
your mixing versions because Freesurfer v6 has no mention of
RB_all_2008-03-26.gca. Please try completely removing the
/Applications/freesurfer directory and reinstalling v6.0.

If this doesnt work please email me the exact command and error output.



Yes, I set FREESURFER_HOME variable as '/Applications/freesurfer', which I
installed freesurfer v6.
I attached recon-all.log file below.
I can see 'build-stamp.txt:
freesurfer-Darwin-OSX-stable-pub-v6.0.0-2beb96c' in log file.

Is there anything to check more?

Thank you,
Juhyoung



On Feb 9, 2017, at 12:38 PM, Bruce Fischl 
>
wrote:

sounds like you are using the old (5.2) recon-all. Are you sure it is 6
in your path?

And can you email the list so others can answer?

thanks
Bruce


On Thu, 9 Feb 2017, Juhyoung Ryu wrote:

Hi Bruce,
I installed FREESURFER with version 6.0 for your recommendation and I
got an
error:
mri_em_register: could not open GCA
/Applications/freesurfer/average/RB_all_2008-03-26.gca.
That file not exist in 'average' folder, and there is one similar
file: RB_all_2016-05-10.vc700.gca
Do you think I should drop that file manually from FREESURFER v5.2?
Thank you in advance,Juhyoung

Begin forwarded message:
From: Juhyoung Ryu >
Subject: Re: [Freesurfer] mrisComputeCorrelationTerm: delta is not
finite at vno 0
Date: February 8, 2017 at 11:01:23 AM GMT+9
To: Z K >
Cc: Bruce Fischl >
Hi Zeke and Bruce,
Thank you very much for your help.
I'll try it now and share the results.
Thanks!
Juhyoung.

On Feb 8, 2017, at 8:13 AM, Z K
> wrote:
Hello Juhyoung,
I noticed from the recon-all.log files that you are using
freesurfer v5.2. It was revealed that this version had issues
regarding systematic white surface contraction and placement of
the pial surface extending too far:
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.nmr.mgh.harvard.edu_pipermail__freesurfer_2013-2DMay_029581.html=DwIFAw=XxU8ngzB_WPJXKyiin_6iQ=GRn28rC6ssBi3WYtpTHXUZZiKgdhzFrFkzz7_Ref9iw=tbfGn9PX8Y7JNwBmOKbl0cqEDAJdta1JKDch4R2RH-Q=a958-NuaRasmvxPlNYQGH7Xxuni1ja2_K-IPFKTdb38=
I would recommend processing these subjects with version 6.0
https://urldefense.proofpoint.com/v2/url?u=https-3A__surfer.nmr.mgh.harvard.edu_fswiki_DownloadAndInstall=DwIFAw=XxU8ngzB_WPJXKyiin_6iQ=GRn28rC6ssBi3WYtpTHXUZZiKgdhzFrFkzz7_Ref9iw=tbfGn9PX8Y7JNwBmOKbl0cqEDAJdta1JKDch4R2RH-Q=IZpj2AG9on5kqVAJyeidyZ75SJP8XLstoGw15-oiJMk=
-Zeke
On 02/06/2017 01:43 AM, Juhyoung Ryu wrote:

Hi FS developers,

I received errors in one of steps in recon-all.
I analyzed 111 individual subjects' T1 data using
same method, but there
are errors in _only 14 subjects._

Below is screenshot image in the end of
recon-all.log file. I attached
log files from two exemplar subjects below, also.

I'd appreciate if you might help me.
Juhyoung.

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.nmr.mgh.harvard.edu_mailman_listinfo_freesurfer=DwIFAw=XxU8ngzB_WPJXKyiin_6iQ=GRn28rC6ssBi3WYtpTHXUZZiKgdhzFrFkzz7_Ref9iw=tbfGn9PX8Y7JNwBmOKbl0cqEDAJdta1JKDch4R2RH-Q=MDwfHSTvfNLB1hGA3uqMR34lhPdwNmIGoO2KJZWZQCY=
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
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.partners.org_complianceline=DwIFAw=XxU8ngzB_WPJXKyiin_6iQ=GRn28rC6ssBi3WYtpTHXUZZiKgdhzFrFkzz7_Ref9iw=tbfGn9PX8Y7JNwBmOKbl0cqEDAJdta1JKDch4R2RH-Q=uU6KntzMpj5JM5tZY5-gdtSUO9jaucky-Rh0zhfG0kY=
  . If the e-mail was sent
to you in error
but does not contain patient information, please contact the
sender and properly
dispose of the e-mail.

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu

Re: [Freesurfer] mrisComputeCorrelationTerm: delta is not finite at vno 0

[zkaufman]

Hello Juhyoung,

If its complaining about "RB_all_2008-03-26.gca" then something must have
happened where you still have portions of the old freesurfer installed, or
your mixing versions because Freesurfer v6 has no mention of
RB_all_2008-03-26.gca. Please try completely removing the
/Applications/freesurfer directory and reinstalling v6.0.

If this doesnt work please email me the exact command and error output.



> Yes, I set FREESURFER_HOME variable as '/Applications/freesurfer’, which I
> installed freesurfer v6.
> I attached recon-all.log file below.
> I can see 'build-stamp.txt:
> freesurfer-Darwin-OSX-stable-pub-v6.0.0-2beb96c’ in log file.
>
> Is there anything to check more?
>
> Thank you,
> Juhyoung
>
>
>
>> On Feb 9, 2017, at 12:38 PM, Bruce Fischl 
>> wrote:
>>
>> sounds like you are using the old (5.2) recon-all. Are you sure it is 6
>> in your path?
>>
>> And can you email the list so others can answer?
>>
>> thanks
>> Bruce
>>
>>
>> On Thu, 9 Feb 2017, Juhyoung Ryu wrote:
>>
>>> Hi Bruce,
>>> I installed FREESURFER with version 6.0 for your recommendation and I
>>> got an
>>> error:
>>> mri_em_register: could not open GCA
>>> /Applications/freesurfer/average/RB_all_2008-03-26.gca.
>>> That file not exist in ‘average' folder, and there is one similar
>>> file: RB_all_2016-05-10.vc700.gca
>>>  Do you think I should drop that file manually from FREESURFER v5.2?
>>> Thank you in advance,Juhyoung
>>>
>>>  Begin forwarded message:
>>> From: Juhyoung Ryu 
>>> Subject: Re: [Freesurfer] mrisComputeCorrelationTerm: delta is not
>>> finite at vno 0
>>> Date: February 8, 2017 at 11:01:23 AM GMT+9
>>> To: Z K 
>>> Cc: Bruce Fischl 
>>> Hi Zeke and Bruce,
>>> Thank you very much for your help.
>>> I’ll try it now and share the results.
>>> Thanks!
>>> Juhyoung.
>>>
>>>  On Feb 8, 2017, at 8:13 AM, Z K
>>>   wrote:
>>> Hello Juhyoung,
>>> I noticed from the recon-all.log files that you are using
>>> freesurfer v5.2. It was revealed that this version had issues
>>> regarding systematic white surface contraction and placement of
>>> the pial surface extending too far:
>>> https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2013-May/029581.html
>>> I would recommend processing these subjects with version 6.0
>>>  https://surfer.nmr.mgh.harvard.edu/fswiki/DownloadAndInstall
>>> -Zeke
>>> On 02/06/2017 01:43 AM, Juhyoung Ryu wrote:
>>>
>>>  Hi FS developers,
>>>
>>>  I received errors in one of steps in recon-all.
>>>  I analyzed 111 individual subjects' T1 data using
>>>  same method, but there
>>>  are errors in _only 14 subjects._
>>>
>>>  Below is screenshot image in the end of
>>>  recon-all.log file. I attached
>>>  log files from two exemplar subjects below, also.
>>>
>>>  I’d appreciate if you might help me.
>>>  Juhyoung.
>>>
>>>  ___
>>>  Freesurfer mailing list
>>>  Freesurfer@nmr.mgh.harvard.edu
>>>  https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>> The information in this e-mail is intended only for the person
>>> to whom it is
>>> addressed. If you believe this e-mail was sent to you in error
>>> and the e-mail
>>> contains patient information, please contact the Partners
>>> Compliance HelpLine at
>>> http://www.partners.org/complianceline . If the e-mail was sent
>>> to you in error
>>> but does not contain patient information, please contact the
>>> sender and properly
>>> dispose of the e-mail.
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Error in recon-all (Skull Stripping)

[Diana Tordesillas-Gutiérrez]

Thank you, we did that, and it was indeed an issue with the way we ran it.
Diana

> El 9 feb 2017, a las 18:19, Douglas Greve  
> escribió:
> 
> It says that it was "Killed" which sounds like the job exceeded some resource 
> on the supercomputer. You should contact the administrators to see what the 
> limits are and whether you exceeded them. You can also run the same subject 
> on a regular computer and see if it dies in the same place.
> 
>> On 2/9/17 5:40 AM, Diana Tordesillas-Gutiérrez wrote:
>> 
>> Dear FreeSurfer developers, 
>> 
>> I am a new FreeSurfer user and I am trying to run it in a supercomputer for 
>> the first time. 
>> 
>> Recon-all finished with errors (see log attached) during skull stripping. 
>> 
>> I have searched the archives and only found that it could be a memory 
>> problem, but I am unsure about this. 
>> 
>> The version of freesurfer is: 
>> freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0-2 
>> 
>> Thank you for your help, 
>> Diana 
>> 
>>  
>> 
>> Diana Tordesillas Gutiérrez, PhD 
>> Neuroimaging Unit IDIVAL 
>> IDIVAL Building 
>> Avda. Cardenal Herrera Oria s/n 
>> 39011 Santander 
>> Spain 
>> Tel. +34 942202677 
>> diana.tordesil...@humv.es 
>> diana.tordesil...@gmail.com 
>> 
>> -- 
>> 
>> 
>> 
>> 
>> 
>> ___
>> Freesurfer mailing list
>> Freesurfer@nmr.mgh.harvard.edu
>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> 
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> 
> 
> The information in this e-mail is intended only for the person to whom it is
> addressed. If you believe this e-mail was sent to you in error and the e-mail
> contains patient information, please contact the Partners Compliance HelpLine 
> at
> http://www.partners.org/complianceline . If the e-mail was sent to you in 
> error
> but does not contain patient information, please contact the sender and 
> properly
> dispose of the e-mail.
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Expert file for recon-all -hires

[miracle ozzoude]

hello antonin,
Thanks for the correction.
Best,
Paul

On Thu, Feb 9, 2017 at 12:21 PM, Antonin Skoch  wrote:

> Dear Paul,
>
> for the most recent version 6.0 the default is 10.
>
> Looking at the help of mris_inflate binary and also to the source code.
>
> Antonin
>
>
> Hello Falk Chris and Antonin,
> The default is 55 https://surfer.nmr.mgh.harvard.edu/fswiki/mris_inflate.
> Best,
> Paul
>
> On Thu, Feb 9, 2017 at 10:42 AM, Falk Lüsebrink 
> wrote:
>
> > Dear Chris and Antonin,
> >
> > I found in some archived message or in the wiki that the default used to
> > be 50 iterations at some time in previous releases of FreeSurfer for
> > standard recon-all. Therefore, I changed it to 50 as default for every
> > resolution in the recent release. This works fine for example for up to
> > 0.5x0.5x0.5mm3 data.
> >
> > I'd also say, more is better and I have not experienced any drawbacks.
> > Processing time doesn't seem to increase noticeably, too.
> >
> > Best,
> > Falk
> >
> > --
> > *Von:* freesurfer-boun...@nmr.mgh.harvard.edu [freesurfer-boun...@nmr.mgh.
> > harvard.edu]" im Auftrag von "Antonin Skoch [a...@ikem.cz]
> > *Gesendet:* Donnerstag, 9. Februar 2017 16:20
> > *An:* freesurfer@nmr.mgh.harvard.edu
> > *Betreff:* Re: [Freesurfer] Expert file for recon-all -hires
> >
> > Dear Chris,
> >
> > I have found that -n 15 is for our 0.7x0.7x0.7mm3 data not enough.
> >
> > I determined optimal value -n 30, empirically, by looking at the shape of
> > inflated surface with various number of iterations. Over -n 30 there was
> > almost no further progression in inflation.
> >
> > I suppose that better more than less. But maybe experts can correct me or
> > provide better suggestion.
> >
> > Antonin
> >
> > Hi all,
> >
> > If I'm reading this
> >  correctly,
> > the current best practice for `-hires` is to include an expert file
> > containing "mris_inflate -n 15", and that this should work for all voxel
> > sizes (0.75mm)^3 - (1mm)^3? Or do we need to empirically determine the best
> > value for a given voxel size, and if so, what should be the criteria for
> > making this determination?
> >
> > Thanks,
> > Chris Markiewicz
> >
>
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Expert file for recon-all -hires

[Antonin Skoch]

Dear Paul,

for the most recent version 6.0 the default is 10.

Looking at the help of mris_inflate binary and also to the source code.

Antonin


Hello Falk Chris and Antonin,
The default is 55 https://surfer.nmr.mgh.harvard.edu/fswiki/mris_inflate.
Best,
PaulOn Thu, Feb 9, 2017 at 10:42 AM, Falk Lüsebrink 
wrote:

> Dear Chris and Antonin,
>
> I found in some archived message or in the wiki that the default used to
> be 50 iterations at some time in previous releases of FreeSurfer for
> standard recon-all. Therefore, I changed it to 50 as default for every
> resolution in the recent release. This works fine for example for up to
> 0.5x0.5x0.5mm3 data.
>
> I'd also say, more is better and I have not experienced any drawbacks.
> Processing time doesn't seem to increase noticeably, too.
>
> Best,
> Falk
>
> --
> *Von:* freesurfer-boun...@nmr.mgh.harvard.edu [freesurfer-boun...@nmr.mgh.
> harvard.edu]" im Auftrag von "Antonin Skoch [a...@ikem.cz]
> *Gesendet:* Donnerstag, 9. Februar 2017 16:20
> *An:* freesurfer@nmr.mgh.harvard.edu
> *Betreff:* Re: [Freesurfer] Expert file for recon-all -hires
>
> Dear Chris,
>
> I have found that -n 15 is for our 0.7x0.7x0.7mm3 data not enough.
>
> I determined optimal value -n 30, empirically, by looking at the shape of
> inflated surface with various number of iterations. Over -n 30 there was
> almost no further progression in inflation.
>
> I suppose that better more than less. But maybe experts can correct me or
> provide better suggestion.
>
> Antonin
>
> Hi all,
>
> If I'm reading this 
>  correctly,
> the current best practice for `-hires` is to include an expert file
> containing "mris_inflate -n 15", and that this should work for all voxel
> sizes (0.75mm)^3 - (1mm)^3? Or do we need to empirically determine the best
> value for a given voxel size, and if so, what should be the criteria for
> making this determination?
>
> Thanks,
> Chris Markiewicz
>___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Freesurfer] Full-Time Staff Position – Johns Hopkins University

[Arnold Bakker]

Computational Neuroscience Research Position

The Division of Psychiatric Neuroimaging in the Department of Psychiatry and 
Behavioral Sciences at Johns Hopkins University School of Medicine, has an 
opening for talented candidates with strong computational and programming 
skills. The successful candidate will assist the investigative team with a wide 
range of studies including those of Alzheimer’s disease, Parkinson’s disease, 
obsessive compulsive disorder, ataxia, obesity, feeding behavior and 
depression. Responsibilities will include acquisition and analysis of 
functional and structural brain imaging data, quality control of imaging data, 
maintenance of databases for statistical analysis, statistical analyses and 
assistance with manuscript preparation. A minimum commitment of two years is 
required. Please email a CV, a statement of research interests and career 
goals, and contact information for two or more references to: p...@jhu.edu.

Qualifications

Bachelors or Master’s of Science degree required. Strong background in 
biomedical engineering, computer science, physics, mathematics, statistics, 
computational neuroscience, or a related field is required. Experience with 
Matlab, Python, R, signal and image processing, statistics, databases, Linux 
and shell scripting is required. Experience in neuroimaging/neural data 
analysis using SPM or similar software is strongly preferred. Excellent 
organizational and interpersonal communication skills are required. Successful 
candidate must have great attention to detail and be able to work well 
independently as well as in a team.

 

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Error in recon-all (Skull Stripping)

[Douglas Greve]

It says that it was "Killed" which sounds like the job exceeded some 
resource on the supercomputer. You should contact the administrators to 
see what the limits are and whether you exceeded them. You can also run 
the same subject on a regular computer and see if it dies in the same place.



On 2/9/17 5:40 AM, Diana Tordesillas-Gutiérrez wrote:


Dear FreeSurfer developers,

I am a new FreeSurfer user and I am trying to run it in a 
supercomputer for the first time.


Recon-all finished with errors (see log attached) during skull stripping.

I have searched the archives and only found that it could be a memory 
problem, but I am unsure about this.


The version of freesurfer is: 
freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0-2


Thank you for your help,
Diana



Diana Tordesillas Gutiérrez, PhD
Neuroimaging Unit IDIVAL
IDIVAL Building
Avda. Cardenal Herrera Oria s/n
39011 Santander
Spain
Tel. +34 942202677
diana.tordesil...@humv.es
diana.tordesil...@gmail.com

--





___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Freesurfer] Fwd: LGI using Yeo Atlas

[Martin Juneja]

Hi,

I used following command to extract LGI values from a set of subjects:

recon-all -s  -localGI

Output stats is saved in lh.aparc_lgi.stats file. By default, its
calculating LGI values of 35 areas using *Desikan-Killiany Atlas *but I am
interested in calculating LGI values using Yeo atlas of 7 networks. I was
wondering how can I change the default atlas to Yeo atlas to get LGI value
for each subject.

Thanks a lot.
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Expert file for recon-all -hires

[miracle ozzoude]

Hello Falk Chris and Antonin,
The default is 55 https://surfer.nmr.mgh.harvard.edu/fswiki/mris_inflate.
Best,
Paul

On Thu, Feb 9, 2017 at 10:42 AM, Falk Lüsebrink 
wrote:

> Dear Chris and Antonin,
>
> I found in some archived message or in the wiki that the default used to
> be 50 iterations at some time in previous releases of FreeSurfer for
> standard recon-all. Therefore, I changed it to 50 as default for every
> resolution in the recent release. This works fine for example for up to
> 0.5x0.5x0.5mm3 data.
>
> I'd also say, more is better and I have not experienced any drawbacks.
> Processing time doesn't seem to increase noticeably, too.
>
> Best,
> Falk
>
> --
> *Von:* freesurfer-boun...@nmr.mgh.harvard.edu [freesurfer-boun...@nmr.mgh.
> harvard.edu]" im Auftrag von "Antonin Skoch [a...@ikem.cz]
> *Gesendet:* Donnerstag, 9. Februar 2017 16:20
> *An:* freesurfer@nmr.mgh.harvard.edu
> *Betreff:* Re: [Freesurfer] Expert file for recon-all -hires
>
> Dear Chris,
>
> I have found that -n 15 is for our 0.7x0.7x0.7mm3 data not enough.
>
> I determined optimal value -n 30, empirically, by looking at the shape of
> inflated surface with various number of iterations. Over -n 30 there was
> almost no further progression in inflation.
>
> I suppose that better more than less. But maybe experts can correct me or
> provide better suggestion.
>
> Antonin
>
> Hi all,
>
> If I'm reading this 
>  correctly,
> the current best practice for `-hires` is to include an expert file
> containing "mris_inflate -n 15", and that this should work for all voxel
> sizes (0.75mm)^3 - (1mm)^3? Or do we need to empirically determine the best
> value for a given voxel size, and if so, what should be the criteria for
> making this determination?
>
> Thanks,
> Chris Markiewicz
>
>
>
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Expert file for recon-all -hires

[Bruce Fischl]

Hi Chris

the smaller the voxels  the more you will need to inflate. I'm hoping to 
find some time to make this adaptive as in principal it's all computable, 
but haven't gotten to it yet.

cheers
Bruce

On Thu, 9 Feb 
2017, Christopher Markiewicz wrote:

> Hi all,
> 
> If I'm reading this
>  correctly,
> the current best practice for `-hires` is to include an expert file
> containing "mris_inflate -n 15", and that this should work for all voxel
> sizes (0.75mm)^3 - (1mm)^3? Or do we need to empirically determine the best
> value for a given voxel size, and if so, what should be the criteria for
> making this determination?
> Thanks,
> Chris Markiewicz
> 
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Expert file for recon-all -hires

[Falk Lüsebrink]

Dear Chris and Antonin,

I found in some archived message or in the wiki that the default used to be 50 
iterations at some time in previous releases of FreeSurfer for standard 
recon-all. Therefore, I changed it to 50 as default for every resolution in the 
recent release. This works fine for example for up to 0.5x0.5x0.5mm3 data.

I'd also say, more is better and I have not experienced any drawbacks. 
Processing time doesn't seem to increase noticeably, too.

Best,
Falk


Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu]" im Auftrag von "Antonin Skoch 
[a...@ikem.cz]
Gesendet: Donnerstag, 9. Februar 2017 16:20
An: freesurfer@nmr.mgh.harvard.edu
Betreff: Re: [Freesurfer] Expert file for recon-all -hires

Dear Chris,

I have found that -n 15 is for our 0.7x0.7x0.7mm3 data not enough.

I determined optimal value -n 30, empirically, by looking at the shape of 
inflated surface with various number of iterations. Over -n 30 there was almost 
no further progression in inflation.

I suppose that better more than less. But maybe experts can correct me or 
provide better suggestion.

Antonin


Hi all,

If I'm reading this <
https://surfer.nmr.mgh.harvard.edu/fswiki/SubmillimeterRecon> correctly,
the current best practice for `-hires` is to include an expert file
containing "mris_inflate -n 15", and that this should work for all voxel
sizes (0.75mm)^3 - (1mm)^3? Or do we need to empirically determine the best
value for a given voxel size, and if so, what should be the criteria for
making this determination?

Thanks,
Chris Markiewicz



___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] recon-all -localGI with longitudinal pipeline output

[Martin Reuter]

Hi Mihaela, 

probably you are trying to run the localGI on a longitudinal directory. As the 
help text output says, you need to make sure you tell that to recon-al by 
passing the original command again (including the -long ….) and instead of -all 
you specify -localGI. 

Renaming hides from recon-all that this is a longitudinal run. It may work for 
this specific case (localGI) but not necessarily for other flags. So when touch 
a longitudinal directory always specify the full recon-al command with -long 
timepoint and base id. 

Best, Martin

> On 27 Jan 2017, at 21:01, Mihaela Stefan  wrote:
> 
> Hello FreeSurfers,
> 
> I am trying to run recon-all -s  -localGI on a longitudinal dataset 
> but I get this error:
> 
> ERROR: Are you trying to run or re-run a longitudinal time point?
>If so, please specify the following parameters:
> 
>\' -long   \'
> 
>where  is the time point id (SAME as cross sectional
>ID) and  is the ID created in the -base run.
>The directory .long. will be created
>automatically or used for output, if it already exists.
> 
> Do I really need these if I want to run -localGI or for some reason recon-all 
> thinks that I am trying to re-run the longitudinal pipeline? I renamed the 
> folder replacing "long" (e.g. OAS2_0001_MR1.new.OAS2_0001 instead of 
> OAS2_0001_MR1.long.OAS2_0001 ) and recon-all -localGI seems to work. 
> 
> Is there a better way to do this?
> 
> Thanks!
> Mihaela
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Edits to Aseg in the Longitudinal Stream

[Martin Reuter]

Hi Tamara, 

that depends on where you edit. Cross or base or long. Generally when editing 
in the longitudinal stream you always use the same recon-all command that you 
used initially, and only replace the -all with the new flag to tell it to start 
later in the process (here -autorecon2-noaseg ) 
not sure if you also need to do -autorecon3, probably does not hurt to make 
sure all steps are run.

Best, Martin

> On 30 Jan 2017, at 19:40, Tamara Tavares  wrote:
> 
> Hello,
> 
> After I make edits to my aseg output in the longitudinal stream, do I just
> run the following command to recreate the final volumes:
> 
> recon-long -autorecon2-noaseg -subjid 
> 
> I assume the -subjid is the name of the edited time point and  is
> the name of the recreated volumes?
> 
> Thank you,
> Tamara
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [Freesurfer] Longitudinal stream with v6 but cross with v5.3

[Martin Reuter]

Hi Matthieu, 

sorry for the late reply. Yes you should be able to do that (as long as it is 
consistent for all subjects). Test it for one subject and then run the rest.

Best, Martin

> On 30 Jan 2017, at 16:51, Matthieu Vanhoutte  
> wrote:
> 
> Dear experts,
> 
> Does anybody could answer my last request ?
> 
> Best,
> Matthieu
> 
> 2017-01-26 9:58 GMT+01:00 Matthieu Vanhoutte  >:
> Dear FS's experts,
> 
> I have run all my cross with v5.3 and hesitate to run all longitudinal 
> process with v6. Does that make sense and will improve the process or would 
> it be risky to do this ?
> 
> Many thanks for your lights !
> 
> Best regards,
> Matthieu
> 
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Freesurfer] Parallelization implementation in Freesurfer 6.0

[Francis Tyson Thomas]

Hello Freesurfer team!

Having gone through the instructions for making use of the parallelization
in Freesurfer v6, I'm confused as to how exactly the calls for fine grained
and coarse grained paralleization differ. As per the release notes,
following is stated -

*Parallelization: a new flag was introduced which enables two forms of
compute parallelization that significantly reduces the runtime. As a point
of reference, using a new-ish workstation (2015+), the recon-all -all
runtime is just under 3 hours. When the -parallel flag is specified at the
end of the recon-all command-line, it will enable 'fine-grained'
parallelized code, making use of OpenMP, embedded in many of the binaries,
namely affecting mri_em_register and mri_ca_register. By default, it
instructs the binaries to use 4 processors (cores), meaning, 4 threads will
run in parallel in some operations (manifested in 'top' by mri_ca_register,
for example, showing 400% CPU utilization). This can be overridden by
including the flag -openmp  after -parallel, where  is the number
of processors you'd like to use (ex. 8 if you have an 8 core machine). Note
that this parallelization was introduced in v5.3, but many new routines
were OpenMP-parallelized in v6. The other form of parallelization, a
'coarse' form, enabled when the -parallel flag is specified, is such that
during the stages where left and right hemispheric data is processed, each
hemi binary is run separately (and in parallel, manifesting itself in 'top'
as two instances of mris_sphere, for example). Note that a couple of the
hemi stages (eg. mris_sphere) make use of a tiny amount of OpenMP code,
which means that for brief periods, as many as 8 cores are utilized (2
binaries running code that each make use of 4 threads). In general, though,
a 4 core machine can easily handle those periods. Be aware that if you
enable this -parallel flag on instances of recon-all running through a job
scheduler (like a cluster), it may not make your System Administrator happy
if you do not pre-allocate a sufficient number of cores for your job, as
you will be taking cycles from other cores that may be running jobs
belonging to other cluster users.*

Does this mean a command executed as "recon-all -s vol0 -i
junk/orig/001/IM-0001-0001.dcm -all -parallel" would be a coarse grained
parallelization and the command executed as "recon-all -s vol0 -i
junk/orig/001/IM-0001-0001.dcm -all -parallel -openmp 8" be a fine grained
parallelization?

Thanks,
Tyson
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Freesurfer] Error in recon-all (Skull Stripping)

[Diana Tordesillas-Gutiérrez]

Dear FreeSurfer developers,

I am a new FreeSurfer user and I am trying to run it in a supercomputer 
for the first time.


Recon-all finished with errors (see log attached) during skull stripping.

I have searched the archives and only found that it could be a memory 
problem, but I am unsure about this.


The version of freesurfer is: 
freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0-2


Thank you for your help,
Diana



Diana Tordesillas Gutiérrez, PhD
Neuroimaging Unit IDIVAL
IDIVAL Building
Avda. Cardenal Herrera Oria s/n
39011 Santander
Spain
Tel. +34 942202677
diana.tordesil...@humv.es
diana.tordesil...@gmail.com

--



Thu Feb  9 09:53:26 CET 2017
/gpfs/csic_users/res/uc35/uc35002/Sujetos/prueba
/gpfs/res_apps/FREESURFER/freesurfer/bin/recon-all
-all -s prueba
subjid prueba
setenv SUBJECTS_DIR /gpfs/csic_users/res/uc35/uc35002/Sujetos
FREESURFER_HOME /gpfs/res_apps/FREESURFER/freesurfer
Actual FREESURFER_HOME /gpfs/res_projects/apps/FREESURFER/freesurfer
build-stamp.txt: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0-2beb96c
Linux login1 2.6.32-642.6.2.el6.x86_64 #1 SMP Tue Oct 25 15:06:33 CDT 2016 x86_64 x86_64 x86_64 GNU/Linux
cputime  10:00
filesize unlimited
datasize unlimited
stacksizeunlimited
coredumpsize 0 kbytes
memoryuseunlimited
vmemoryuse   unlimited
descriptors  1024 
memorylocked unlimited
maxproc  1024 

 total   used   free sharedbuffers cached
Mem:  659491167785820   58163296732 2784204237620
-/+ buffers/cache:3269780   62679336
Swap: 33046524 191752   32854772


program versions used
$Id: recon-all,v 1.580.2.16 2017/01/18 14:11:24 zkaufman Exp $
$Id: mri_motion_correct.fsl,v 1.15 2016/02/16 17:17:20 zkaufman Exp $
mri_convert.bin -all-info 
ProgramName: mri_convert.bin  ProgramArguments: -all-info  ProgramVersion: $Name: stable6 $  TimeStamp: 2017/02/09-08:53:27-GMT  BuildTimeStamp: Jan 18 2017 16:38:58  CVS: $Id: mri_convert.c,v 1.226 2016/02/26 16:15:24 mreuter Exp $  User: uc35002  Machine: login1  Platform: Linux  PlatformVersion: 2.6.32-642.6.2.el6.x86_64  CompilerName: GCC  CompilerVersion: 40400 
FLIRT version 5.5
$Id: talairach_avi,v 1.13 2015/12/23 04:25:17 greve Exp $
mri_convert.bin --version 
stable6
ProgramName: tkregister2_cmdl  ProgramArguments: --all-info  ProgramVersion: $Name: stable6 $  TimeStamp: 2017/02/09-08:53:27-GMT  BuildTimeStamp: Jan 18 2017 16:38:58  CVS: $Id: tkregister2.c,v 1.132.2.1 2016/08/02 21:17:29 greve Exp $  User: uc35002  Machine: login1  Platform: Linux  PlatformVersion: 2.6.32-642.6.2.el6.x86_64  CompilerName: GCC  CompilerVersion: 40400 
Program nu_correct, built from:
Package MNI N3, version 1.12.0, compiled by nicks@terrier (x86_64-unknown-linux-gnu) on 2015-06-19 at 01:25:34
ProgramName: mri_make_uchar  ProgramArguments: -all-info  ProgramVersion: $Name: stable6 $  TimeStamp: 2017/02/09-08:53:28-GMT  BuildTimeStamp: Jan 18 2017 16:38:58  CVS: $Id: mri_make_uchar.c,v 1.4 2011/03/02 00:04:14 nicks Exp $  User: uc35002  Machine: login1  Platform: Linux  PlatformVersion: 2.6.32-642.6.2.el6.x86_64  CompilerName: GCC  CompilerVersion: 40400 
ProgramName: mri_normalize  ProgramArguments: -all-info  ProgramVersion: $Name:  $  TimeStamp: 2017/02/09-08:53:28-GMT  BuildTimeStamp: Jan 18 2017 16:38:58  CVS: $Id: mri_normalize.c,v 1.88.2.3 2016/12/27 16:47:13 zkaufman Exp $  User: uc35002  Machine: login1  Platform: Linux  PlatformVersion: 2.6.32-642.6.2.el6.x86_64  CompilerName: GCC  CompilerVersion: 40400 
ProgramName: mri_watershed  ProgramArguments: -all-info  ProgramVersion: $Name: stable6 $  TimeStamp: 2017/02/09-08:53:28-GMT  BuildTimeStamp: Jan 18 2017 16:38:58  CVS: $Id: mri_watershed.cpp,v 1.103 2016/06/17 18:00:49 zkaufman Exp $  User: uc35002  Machine: login1  Platform: Linux  PlatformVersion: 2.6.32-642.6.2.el6.x86_64  CompilerName: GCC  CompilerVersion: 40400 
ProgramName: mri_gcut  ProgramArguments: -all-info  ProgramVersion: $Name: stable6 $  TimeStamp: 2017/02/09-08:53:28-GMT  BuildTimeStamp: Jan 18 2017 16:38:58  CVS: $Id: mri_gcut.cpp,v 1.14 2011/03/02 00:04:16 nicks Exp $  User: uc35002  Machine: login1  Platform: Linux  PlatformVersion: 2.6.32-642.6.2.el6.x86_64  CompilerName: GCC  CompilerVersion: 40400 
ProgramName: mri_segment  ProgramArguments: -all-info  ProgramVersion: $Name:  $  TimeStamp: 2017/02/09-08:53:28-GMT  BuildTimeStamp: Jan 18 2017 16:38:58  CVS: $Id: mri_segment.c,v 1.43.2.1 2016/10/27 22:24:52 zkaufman Exp $  User: uc35002  Machine: login1  Platform: Linux  PlatformVersion: 2.6.32-642.6.2.el6.x86_64  CompilerName: GCC  CompilerVersion: 40400 
ProgramName: mri_label2label.bin  ProgramArguments: -all-info  ProgramVersion: $Name:  $  TimeStamp: 2017/02/09-08:53:29-GMT  BuildTimeStamp: Jan 18 2017 16:38:58  CVS: $Id: mri_label2label.c,v 1.48.2.2 2016/12/12 14:15:26