[Freesurfer] obtain a V1 mask.nii.gz

[lujiao luo]

Hello, experts,

I am trying to obtain a V1 mask and use it as a seed of my fiber
tracking. But I do not know how to get the BA.nii.gz file, and I've
obtained BA.ctab and lh.BA.annot files by using flag recon_all. Would
someone give me some suggestions about this?

Thanks so much for your  help!

Yours Lulu
___
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] MRI artifacts detection

[Jordi Delgado]

Dear FS experts,

I'm studying the most common artifacts on MRI scanning. I started with the
SNR calculation (which is included in recent FS versions), but I'm afraid
that these artifact is filtered/processed with the scanner control program,
and I'm wasting time trying to calculate this ratio.

My qüestion is, any one of you know if the scanners control programs are
correcting SNR, Inhomogeneties, motion, etc? Have any sense to detect these
artifacts, as a quality assurance method before to accept/decline the
adquired image with an external method of the scanner control program?

Thank you in advance,

-- 
Jordi Delgado Mengual
PIC (Port d'Informació Científica)
Campus UAB, Edifici D
E-08193 Bellaterra, Barcelona
Tel: +34 93 586 82 32 Fax: +34 93 581 41 10
http://www.pic.es
Avis - Aviso - Legal Notice: http://www.ifae.es/legal.html
___
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] optseq2 malloc memory / matrix rank-deficient

[Koolschijn , Cédric]

Dear FS-experts,

I've been using optseq for many years without problems, however, I run into a 
couple now.
My code is the following:

optseq2 --ntp 255 --tr 2.0 --tprescan 4.0 --psdwin 0.0 16.0 1 --ev Gain2 5.0 
8.0 --ev Gain4 5.0 8.0 --ev Gain6 5.0 8.0 --ev Gain8 5.0 8.0 --ev Loss2 5.0 8.0 
--ev Loss4 5.0 8.0 --ev Loss6 5.0 8.0 --ev Loss8 5.0 8.0 --ev Catch 5.0 8.0 
--tnullmin 2.0 --tnullmax 6.0 --tsearch 24 --focb 100 --ar1 .37 --evc 1 1 1 1 
-1 -1 -1 -1 0 --evc -1.5 -.5 .5 1.5 -1.5 -.5 .5 1.5 0 --evc -1.5 -.5 .5 1.5 1.5 
.5 -.5 -1.5 0 --cost eff --nkeep 3 --o output_run1

If I run this on a computational cluster (CentOS 5) with more than enough RAM, 
I get the following message after on screen summary:
outstem = output_run1
*** glibc detected *** optseq2: malloc(): memory corruption: 0x03f3e4e0 
***
*** glibc detected *** optseq2: malloc(): memory corruption: 0x03f3e4e0 
***

And nothing happens after that.

If I run the same code on my iMac Lion 10.7.5, it seems to be working, but I 
get multiple "warnings":
/usr/pubsw/packages/vxl/1.13.0/src/core/vnl/algo/vnl_qr.txx: vnl_qr::solve() 
: matrix is rank-deficient by 112

The number at the end changes each time.
In addition, the process consumes my RAM (8GB) like it's nothing.

The strange thing is, I do get usable output.


Any ideas what might be causing this?

Many thanks!

Cédric


P.C.M.P. Koolschijn (Cédric), PhD
Dutch Autism & ADHD Research Center
Brain and Cognition
Amsterdam, The Netherlands
E p.c.m.p.koolsch...@uva.nl
W http://www.dutcharc.nl




___
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] beta v5.3 for fedora 18 and ubuntu 13

[Joerg Pfannmoeller]

Hello Nick,

just installed and tested the BETA version. Up to now no problem encountered. 
Recon-all is just running as a test (using -use-gpu). OS is Lubuntu 13.04. I 
report on the segmentation as soon as it is finished.

So long Joerg

On Sun, 12 May 2013 22:41:25 -0400 (EDT)
"Nick Schmansky"  wrote:

> Fedora 18, Ubuntu 13 and Gentoo 64 users,
> 
> another beta of the upcoming v5.3 is available here:
> 
> ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/5.3.0-BETA/freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0-BETA.tar.gz
> 
> this one is just intended for the Fedora 18, Ubuntu 13, Gentoo 64 users
> who wished to test that the segfault problem in v5.2 and the prior beta
> v5.3 is fixed.  Your help in testing this release is appreciated.
> 
> Thanks,
> 
> Nick
> 
> 
> 
> 
> 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.
> 


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

Re: [Freesurfer] beta v5.3 for fedora 18 and ubuntu 13

[Jörg Pfannmöller]

Just for completeness, I refer to my first contribution:

http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg28267.html

















On Mon, 13 May 2013 13:58:30 +0200
Joerg Pfannmoeller  wrote:

> Hello Nick,
> 
> just installed and tested the BETA version. Up to now no problem encountered. 
> Recon-all is just running as a test (using -use-gpu). OS is Lubuntu 13.04. I 
> report on the segmentation as soon as it is finished.
> 
> So long Joerg
> 
> On Sun, 12 May 2013 22:41:25 -0400 (EDT)
> "Nick Schmansky"  wrote:
> 
> > Fedora 18, Ubuntu 13 and Gentoo 64 users,
> > 
> > another beta of the upcoming v5.3 is available here:
> > 
> > ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/5.3.0-BETA/freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0-BETA.tar.gz
> > 
> > this one is just intended for the Fedora 18, Ubuntu 13, Gentoo 64 users
> > who wished to test that the segfault problem in v5.2 and the prior beta
> > v5.3 is fixed.  Your help in testing this release is appreciated.
> > 
> > Thanks,
> > 
> > Nick
> > 
> > 
> > 
> > 
> > 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.
> > 
> 
> 
> -- 
> Joerg Pfannmoeller 
> ___
> 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] obtain a V1 mask.nii.gz

[Bruce Fischl]

Hi Lulu

what version are you running? If it's a newer one you should have label 
files in the label subdir named [lr]h.V1.label and [lr]h.V1.thresh.label (a 
thresholded version of the first one).


cheers
Bruce


On Mon, 13 May 2013, lujiao luo 
wrote:



Hello, experts,
I am trying to obtain a V1 mask and use it as a seed of my fiber tracking. But 
I do not know how to get the
BA.nii.gz file, and I've obtained BA.ctab and lh.BA.annot files by using flag 
recon_all. Would someone give me
some suggestions about this?

Thanks so much for your  help!

Yours Lulu

___
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] MRI artifacts detection

[Bruce Fischl]

Hi Jordi

this is definitely vendor specific. In Siemens you can for example turn 
on "prescan normalization" which will correct for intensity bias. You can 
have it generate two series - one with and one withour the correction. What 
other artifacts do you mean? There are lots of possibilities


cheers
Bruce



On Mon, 13 May 2013, 
Jordi Delgado wrote:



Dear FS experts,

I'm studying the most common artifacts on MRI scanning. I started with the SNR 
calculation (which is included
in recent FS versions), but I'm afraid that these artifact is 
filtered/processed with the scanner control
program, and I'm wasting time trying to calculate this ratio.

My qüestion is, any one of you know if the scanners control programs are 
correcting SNR, Inhomogeneties,
motion, etc? Have any sense to detect these artifacts, as a quality assurance 
method before to accept/decline
the adquired image with an external method of the scanner control program?

Thank you in advance,

--
Jordi Delgado Mengual
PIC (Port d'Informació Científica)
Campus UAB, Edifici D
E-08193 Bellaterra, Barcelona
Tel: +34 93 586 82 32 Fax: +34 93 581 41 10
http://www.pic.es
Avis - Aviso - Legal Notice: http://www.ifae.es/legal.html

___
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] MRI artifacts detection

[Jordi Delgado]

Hi Bruce,

Thank you for your fast answer. I'm focusing on SNR, Motion Correction and
Intensity Inhomogeneities.

Regards,


2013/5/13 Bruce Fischl 

> Hi Jordi
>
> this is definitely vendor specific. In Siemens you can for example turn on
> "prescan normalization" which will correct for intensity bias. You can have
> it generate two series - one with and one withour the correction. What
> other artifacts do you mean? There are lots of possibilities
>
> cheers
> Bruce
>
>
>
>
> On Mon, 13 May 2013, Jordi Delgado wrote:
>
>  Dear FS experts,
>>
>> I'm studying the most common artifacts on MRI scanning. I started with
>> the SNR calculation (which is included
>> in recent FS versions), but I'm afraid that these artifact is
>> filtered/processed with the scanner control
>> program, and I'm wasting time trying to calculate this ratio.
>>
>> My qüestion is, any one of you know if the scanners control programs are
>> correcting SNR, Inhomogeneties,
>> motion, etc? Have any sense to detect these artifacts, as a quality
>> assurance method before to accept/decline
>> the adquired image with an external method of the scanner control program?
>>
>> Thank you in advance,
>>
>> --
>> Jordi Delgado Mengual
>> PIC (Port d'Informació Científica)
>> Campus UAB, Edifici D
>> E-08193 Bellaterra, Barcelona
>> Tel: +34 93 586 82 32 Fax: +34 93 581 41 10
>> http://www.pic.es
>> Avis - Aviso - Legal Notice: http://www.ifae.es/legal.html
>>
>>
>>
>
> 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.
>



-- 
Jordi Delgado Mengual
PIC (Port d'Informació Científica)
Campus UAB, Edifici D
E-08193 Bellaterra, Barcelona
Tel: +34 93 586 82 32 Fax: +34 93 581 41 10
http://www.pic.es
Avis - Aviso - Legal Notice: http://www.ifae.es/legal.html
___
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] obtain a V1 mask.nii.gz

[lujiao luo]

Hello Bruce,

Thanks so much for your reply.

Yes, you are right,  I've obtained the  lh.V1.label. But I couldn't figure
out how to create a roi.nii.gz mask by using the lhV1.lable file or
lhBA.annot, and then I can use it as a seed for my fiber tracking.

Yours Lulu.



2013/5/13 Bruce Fischl 

> Hi Lulu
>
> what version are you running? If it's a newer one you should have label
> files in the label subdir named [lr]h.V1.label and [lr]h.V1.thresh.label (a
> thresholded version of the first one).
>
> cheers
> Bruce
>
>
>
> On Mon, 13 May 2013, lujiao luo wrote:
>
>  Hello, experts,
>> I am trying to obtain a V1 mask and use it as a seed of my fiber
>> tracking. But I do not know how to get the
>> BA.nii.gz file, and I've obtained BA.ctab and lh.BA.annot files by using
>> flag recon_all. Would someone give me
>> some suggestions about this?
>>
>> Thanks so much for your  help!
>>
>> Yours Lulu
>>
>>
>>
>
> 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] obtain a V1 mask.nii.gz

[Bruce Fischl]

try mri_label2vol

cheers
Bruce
On Mon, 13 May 2013, lujiao luo wrote:


Hello Bruce,
Thanks so much for your reply.

Yes, you are right,  I've obtained the  lh.V1.label. But I couldn't figure out 
how to create a roi.nii.gz mask by using the
lhV1.lable file or lhBA.annot, and then I can use it as a seed for my fiber 
tracking.

Yours Lulu.



2013/5/13 Bruce Fischl 
  Hi Lulu

  what version are you running? If it's a newer one you should have label 
files in the label subdir named
  [lr]h.V1.label and [lr]h.V1.thresh.label (a thresholded version of the 
first one).

  cheers
  Bruce


  On Mon, 13 May 2013, lujiao luo wrote:

Hello, experts,
I am trying to obtain a V1 mask and use it as a seed of my fiber 
tracking. But I do not know how to get
the
BA.nii.gz file, and I've obtained BA.ctab and lh.BA.annot files by 
using flag recon_all. Would someone
give me
some suggestions about this?

Thanks so much for your  help!

Yours Lulu




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] obtain a V1 mask.nii.gz

[lujiao luo]

Thanks so much for your suggestion, Bruce. I will have a try.

Yours Lulu


2013/5/13 Bruce Fischl 

> try mri_label2vol
>
>
> cheers
> Bruce
> On Mon, 13 May 2013, lujiao luo wrote:
>
>  Hello Bruce,
>> Thanks so much for your reply.
>>
>> Yes, you are right,  I've obtained the  lh.V1.label. But I couldn't
>> figure out how to create a roi.nii.gz mask by using the
>> lhV1.lable file or lhBA.annot, and then I can use it as a seed for my
>> fiber tracking.
>>
>> Yours Lulu.
>>
>>
>>
>> 2013/5/13 Bruce Fischl 
>>   Hi Lulu
>>
>>   what version are you running? If it's a newer one you should have
>> label files in the label subdir named
>>   [lr]h.V1.label and [lr]h.V1.thresh.label (a thresholded version of
>> the first one).
>>
>>   cheers
>>   Bruce
>>
>>
>>   On Mon, 13 May 2013, lujiao luo wrote:
>>
>> Hello, experts,
>> I am trying to obtain a V1 mask and use it as a seed of my
>> fiber tracking. But I do not know how to get
>> the
>> BA.nii.gz file, and I've obtained BA.ctab and lh.BA.annot
>> files by using flag recon_all. Would someone
>> give me
>> some suggestions about this?
>>
>> Thanks so much for your  help!
>>
>> Yours Lulu
>>
>>
>>
>>
>> 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] MRI artifacts detection

[Inati, Souheil (NIH/NIMH) [E]]

Question from the MR Physics peanut gallery:
How are you defining/measuring SNR for the anatomical sequences?

(Sticking to Siemens.)  The way I think about this, if what you have are the 
dicoms from an mprage which was collected with a receiver array, acceleration 
and pre-scan normalization, then estimating anything about the electrical noise 
is impossible because (…. insert inappropriate vendor trashing here ….).  
Basically, the vendors have not designed their recon chains to produce images 
in SNR units.  Or even images with a body coil intensity reference (i.e. 
pre-scan normalize) with a proper accounting of the noise so that you could 
make an image of the noise variance at each pixel to then feed into a smart 
segmentation.

Thoughts?

-Souheil

-

Souheil Inati, PhD
Staff Scientist
FMRI Facility
NIMH/NIH/DHHS
souheil.in...@nih.gov




On May 13, 2013, at 9:13 AM, Jordi Delgado 
mailto:jordi...@pic.es>> wrote:

Hi Bruce,

Thank you for your fast answer. I'm focusing on SNR, Motion Correction and 
Intensity Inhomogeneities.

Regards,


2013/5/13 Bruce Fischl 
mailto:fis...@nmr.mgh.harvard.edu>>
Hi Jordi

this is definitely vendor specific. In Siemens you can for example turn on 
"prescan normalization" which will correct for intensity bias. You can have it 
generate two series - one with and one withour the correction. What other 
artifacts do you mean? There are lots of possibilities

cheers
Bruce




On Mon, 13 May 2013, Jordi Delgado wrote:

Dear FS experts,

I'm studying the most common artifacts on MRI scanning. I started with the SNR 
calculation (which is included
in recent FS versions), but I'm afraid that these artifact is 
filtered/processed with the scanner control
program, and I'm wasting time trying to calculate this ratio.

My qüestion is, any one of you know if the scanners control programs are 
correcting SNR, Inhomogeneties,
motion, etc? Have any sense to detect these artifacts, as a quality assurance 
method before to accept/decline
the adquired image with an external method of the scanner control program?

Thank you in advance,

--
Jordi Delgado Mengual
PIC (Port d'Informació Científica)
Campus UAB, Edifici D
E-08193 Bellaterra, Barcelona
Tel: +34 93 586 82 32 Fax: +34 93 581 41 
10
http://www.pic.es
Avis - Aviso - Legal Notice: http://www.ifae.es/legal.html




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.



--
Jordi Delgado Mengual
PIC (Port d'Informació Científica)
Campus UAB, Edifici D
E-08193 Bellaterra, Barcelona
Tel: +34 93 586 82 32 Fax: +34 93 581 41 10
http://www.pic.es
Avis - Aviso - Legal Notice: http://www.ifae.es/legal.html
___
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

Re: [Freesurfer] Binary volume to surface label

[Jonathan DuBois]

Hi Bruce,

Thanks for your help yesterday. I was able to create the .mgh file using
the -output_type mgh option, but I am still unable to load it in tksurfer
as label or anything else. If you or Doug have any other suggestions, I
would really appreciate it. Thanks!

Jonathan


On Sun, May 12, 2013 at 4:55 PM, Bruce Fischl wrote:

> Hi Jonathan
>
> try -output_type mgh. It should create a "volume" that is nvertices long.
> Not sure if it can directly create a label file, maybe Doug knows?
>
>
> Bruce
>
>
> On Sun, 12 May 2013, Jonathan DuBois wrote:
>
>  I used the following options: mri_vol2surf --hemi lh --regheader subject01
>> --cortex --mov label.mgz --o ./label.mghIt ran without error, but I could
>>
>> not open the resulting file in tksurfer as either a label or an overlay:
>> -
>> /Applications/freesurfer/**tktools/tksurfer.bin: no data in label file
>> /Users/label.mgh
>> tkmedit: Trying to open /Users/label.dat
>> surfer: Interpreting overlay volume /Users/label.mgh as encoded scalar
>> volume
>>
>> Best,
>> Jonathan
>>
>>
>> On Sun, May 12, 2013 at 1:57 PM, Bruce Fischl > >
>> wrote:
>>   try using --regheader
>>
>>   cheers
>>   Bruce
>>   On Sun, 12 May 2013, Jonathan DuBois wrote:
>>
>> Hi Bruce,
>> I would like to convert the .mgz label volume to a
>> surface label for that
>> subject, but mri_vol2surf requires a registration
>> file.
>>
>> Best,
>> Jonathan
>>
>>
>>
>> On Sunday, May 12, 2013, Bruce Fischl wrote:
>>   Hi Jonathan
>>
>>   you don't need to register it if it's shown
>> properly in tkmedit
>>   or freeview. Can you tell us more about what
>> you are trying to
>>   do?
>>   Bruce
>>
>>
>>   On Sun, 12 May 2013, Jonathan DuBois wrote:
>>
>> Hi Bruce,
>> Thanks for the quick response. The label
>> is a
>> manually traced area of the
>> cortex. It is in subject scanner space
>> and has a
>> single value, so it
>> probably would not work with bbregister.
>> I can load
>> it in tkmedit as a
>> segmentation and the alignment is
>> correct. I
>> attached a screenshot. Is there
>> a way to select the values greater than
>> zero in
>> tkmedit and save as a label
>> that could be used in vol2surf? I have
>> other labels
>> that are larger so I
>> would prefer not to retrace them if
>> possible.
>>
>> Inline image 2
>> Best,
>> Jonathan
>>
>>
>> On Sun, May 12, 2013 at 10:11 AM, Bruce
>> Fischl
>> 
>> wrote:
>>   Hi Jonathan
>>
>>   what is the label? What space is
>> it in? If it
>> has gray/white
>>   contrast you could try bbregister.
>>
>>   cheers
>>   Bruce
>>   On Sat, 11 May 2013, Jonathan
>> DuBois wrote:
>>
>> Hi Freesurfer Experts,
>> I have a binary volume label
>> in subject
>> space that I
>> converted from MINC to MGZ.
>> I would like
>> to register
>> it to
>> the surface of that subject
>> as a flat
>> label. I
>> thought I would be able to
>> do so with
>> mri_vol2surf
>> but I am not
>> sure how to generate the
>> required
>> registration file.
>> Is that the correct command,
>> and if so,
>> which
>> registration
>> file should I use?
>>
>> Thanks
>> Jonathan
>>
>>
>>
>>
>> The information in this e-mail is
>> intended only for
>> the person to whom
>> it is
>> addressed. If you be

Re: [Freesurfer] Unable to run trac-all on a subject from whom...

[celine]

Hi again
I am sorry I found out that I needed to delete this file IsRunning.trac
and then it works again.
Sorry for the inconvenience
Best
Celine

> Hi Freesurfer team
> I am very new with tracula so my problem might be very obvious.
>
> I previously run trac-all -prep on a patient and it worked fine, then when
> I ran trac-all -bedp, after 30 hours, I thought there might be a problem
> so that I killed the job. Since then, I am not able to run again trac-all
> -prep on this subject and I can't see in the log file why.
>
> Here are the log files.
> I deleted all the previous preprocessing, but it didn't change my output.
> Thanks a lot for your help
> Celine
>
>
>
> --
> Celine Louapre, MD
> Research Fellow at Massachusetts General Hospital
> Department of Radiology, MGH
>
> Building 149, Room 2301
> 13th Street
> Charlestown, MA  02129___
> 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] Binary volume to surface label

[Bruce Fischl]

you should be able to load it into tksurfer as an overlay.

cheers
Bruce
On Mon, 13 May 
2013, Jonathan DuBois wrote:



Hi Bruce, 
Thanks for your help yesterday. I was able to create the .mgh file using the 
-output_type mgh option, but I am still unable to
load it in tksurfer as label or anything else. If you or Doug have any other 
suggestions, I would really appreciate it. Thanks!

Jonathan


On Sun, May 12, 2013 at 4:55 PM, Bruce Fischl  
wrote:
  Hi Jonathan

  try -output_type mgh. It should create a "volume" that is nvertices long. 
Not sure if it can directly create a label
  file, maybe Doug knows?

  Bruce


  On Sun, 12 May 2013, Jonathan DuBois wrote:

  I used the following options: mri_vol2surf --hemi lh --regheader subject01
--cortex --mov label.mgz --o ./label.mghIt ran without error, but I could
not open the resulting file in tksurfer as either a label or an overlay:
-
/Applications/freesurfer/tktools/tksurfer.bin: no data in label file
/Users/label.mgh
tkmedit: Trying to open /Users/label.dat
surfer: Interpreting overlay volume /Users/label.mgh as encoded scalar
volume

Best, 
Jonathan


On Sun, May 12, 2013 at 1:57 PM, Bruce Fischl 
wrote:
      try using --regheader

      cheers
      Bruce
      On Sun, 12 May 2013, Jonathan DuBois wrote:

            Hi Bruce, 
            I would like to convert the .mgz label volume to a
            surface label for that
            subject, but mri_vol2surf requires a registration
            file.

            Best, 
            Jonathan



            On Sunday, May 12, 2013, Bruce Fischl wrote:
                  Hi Jonathan

                  you don't need to register it if it's shown
            properly in tkmedit
                  or freeview. Can you tell us more about what
            you are trying to
                  do?
                  Bruce


                  On Sun, 12 May 2013, Jonathan DuBois wrote:

                        Hi Bruce, 
                        Thanks for the quick response. The label
            is a
                        manually traced area of the
                        cortex. It is in subject scanner space
            and has a
                        single value, so it
                        probably would not work with bbregister.
            I can load
                        it in tkmedit as a
                        segmentation and the alignment is
            correct. I
                        attached a screenshot. Is there
                        a way to select the values greater than
            zero in
                        tkmedit and save as a label
                        that could be used in vol2surf? I have
            other labels
                        that are larger so I
                        would prefer not to retrace them if
            possible.

                        Inline image 2
                        Best, 
                        Jonathan


                        On Sun, May 12, 2013 at 10:11 AM, Bruce
            Fischl
                        
                        wrote:
                              Hi Jonathan

                              what is the label? What space is
            it in? If it
                        has gray/white
                              contrast you could try bbregister.

                              cheers
                              Bruce
                              On Sat, 11 May 2013, Jonathan
            DuBois wrote:

                                    Hi Freesurfer Experts, 
                                    I have a binary volume label
            in subject
                        space that I
                                    converted from MINC to MGZ.
            I would like
                        to register
                                    it to
                                    the surface of that subject
            as a flat
                        label. I
                                    thought I would be able to
            do so with
                        mri_vol2surf
                                    but I am not
                                    sure how to generate the
            required
                        registration file.
                                    Is that the correct command,
            and if so,
                        which
                                    registration
                                    file should I use?

                                    Thanks
                                    Jonathan




                        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
  

Re: [Freesurfer] Correction for multiple comparisons question

[Fotiadis, Panagiotis]

Thanks for the clarifications, Doug!

1) I am using FS stable version 5.0.0, so I'm assuming that the --2spaces flag 
has probably been implemented for the more recent FS versions. 

2) Thanks, that makes a lot more sense now.

In addition, since clusters are formed based on the number of neighboring 
voxels above the set voxel-based threshold, how is it possible to have reported 
(from the summary) clusters that have a cluster-wise p value higher than the 
voxel-based one? Isn't the cluster-wise p value of a cluster the maximum p 
value of all the contiguous voxels in that cluster?

Thanks again for all your help.
Panos





From: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Douglas Greve 
[gr...@nmr.mgh.harvard.edu]
Sent: Monday, May 13, 2013 12:22 AM
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] Correction for multiple comparisons question

Hi Panagiotis,

On 5/12/13 9:32 PM, Fotiadis, Panagiotis wrote:
> Hi Freesurfer experts,
>
> I was wondering about three things concerning the use of the mri_glmfit-sim 
> command:
>
> 1) I tried running it with the --2spaces flag in order to Bonferroni correct 
> over the two hemispheres but it tells me that the specific flag is not 
> recognized. Is there another way to correct over the two hemispheres?
What version are you using? You can just adjust the clusterwise
threshold by dividing by 2 (eg, if you want a clusterwise threshold of
.05, then set it to .025)
>
> 2) I set the cluster-based threshold to 0.999 in order to see all of the 
> clusters and varied the voxel-based threshold in order to see the differences 
> that it would make on the results. Specifically, i set it to be 1.3, 2.0, 
> 2.3, and 3.0. Between the four different occurring cluster summaries, there 
> was only one common cluster that appeared in all four summaries. As expected, 
> the number of voxels of the specific cluster was decreasing as its voxel-wise 
> threshold was increasing.
>
> a)  However, the reported cluster-wise threshold  varied between 0.05 to 0.96 
> in those four cases. Does this sound reasonable? Shouldn't the cluster wise p 
> values of the same cluster-between the four cases-be less dispersed?
I'm not sure what you mean here. At 3.0, the cluster may be very small
and so could appear to be very insignificant.
>
> b)  If there is a cluster reported in only one of the four summaries (i.e. 
> when the voxel-based threshold is 1.3) that say has a cluster-wise p value of 
> 0.03, do I consider that significant or not, since it does not appear in any 
> other summary with such a low cluster wise p value and since the only 
> published p value is the cluster wise one?
In principle, it is significant. A lot of reviewers balk at such a
liberal voxel-wise threshold since gaussian random fields breaks down at
liberal thresholds. However, this uses simulations and not GRF. You
should make sure the reviewers know this. There still might be some
resistance since you could be picking up some low spatial frequency
trends (ie, stuff that is not spatially gaussian) in addition to your
true activation.

doug
>
> Thank you in advance for your time,
> Panagiotis Fotiadis
> ___
> 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
___
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] Working with MEMPRAGE

[Jonathan Holt]

Hi all,

last question promise. Successfully completed mris_make_surfaces for both 
hemispheres. in my day-to-day editing I open tkmedit thusly:

tkmedit  brainmask.mgz -aux $SUBJECTS_DIR/subjid/mri/wm.mgz -surface 
$SUBJECTS_DIR/subjid/surf/lh.white -aux-surface 
$SUBJECTS_DIR/subjid/surf/rh.white -aparc+aseg 

this works for mprage subjects. In evaluating and possibly editing MEMPRAGE 
subjects, which surfaces should I have opened in tkmedit, as there seem to be 
many more this time around.

best,
jon
On May 11, 2013, at 6:49 PM, Bruce Fischl wrote:

> Hi Kayle
> 
> it's been a long time since I wrote that code and we've only run it a few 
> times. If you upload your subject directory I'll take a look
> 
> cheers
> Bruce
> On Sat, 11 May 
> 2013, Kayle Sawyer wrote:
> 
>> Hi all,
>> 
>> I tried to use the 4-echo MEMPRAGE dura detection for mris_make_surfaces, 
>> but I'm not sure if it worked. The terminal output, including commands, is 
>> attached. It was run with version 
>> freesurfer-Linux-centos6_x86_64-stable-v5.3.0-BETA-20130509.
>> 
>> On the original recon, in the rh, there is a segment of dura marked as grey 
>> inside the pial line, at 94 111 169. The surfaces did not appear to change 
>> substantially after I reran mris_make_surfaces with the -dura flag 
>> specifying the 4-echo MEMPRAGE, which I placed in the mri directory. You can 
>> see the before and after for yourself on the attached screenshots, or if you 
>> have NMR access, here:
>> /space/ficus/6/users/SNEF_edits/OB01_orig/
>> /space/ficus/6/users/SNEF_edits/OB01_orig_dura/
>> 
>> I saw this output from mris_make_surfaces for the rh, so maybe -dura did 
>> correct a different defect?
>> 7 non-cortical segments detected
>> only using segment with 1900 vertices
>> 
>> Any help would be appreciated, because we have over 130 brains and the fewer 
>> manual corrections, the better!
>> 
>> Thanks,
>> -Kayle
>> 
>> 
>> 
>> 
>> From: Douglas Greve 
>> Date: Thu, May 9, 2013 at 8:44 PM
>> Subject: Re: [Freesurfer] Working with MEMPRAGE
>> To: freesurfer@nmr.mgh.harvard.edu
>> 
>> 
>> 
>> the dcmunpack command is right. You should make sure to analyze only the
>> RMS in recon-all (ie , that is the only volume that goes into mri/orig
>> doug
>> 
>> 
>> On 5/9/13 6:48 PM, Bruce Fischl wrote:
>>> Hi Kayle
>>> 
>>> you would run recon-all on the RMS, then run the dura stuff posthoc.
>>> 
>>> cheers
>>> Bruce
>>> On Thu,
>>> 9 May 2013, Kayle Sawyer wrote:
>>> 
 Hi all,
 
 Can the MEMPRAGE be specified in recon-all with the -i flag? We have been 
 using the MEMPRAGE RMS scans and discarding the multiecho scans. If we 
 instead specify the multiecho scans for recon-all, do we need to give any 
 additional parameters (e.g. the number of echoes) for it to utilize the 4 
 echoes to detect dura and refine pial surfaces in mris_make_surfaces, as 
 described below? Or would we have to run recon-all with the RMS, then 
 after it finishes re-run mris_make_surfaces manually with the -dura flag 
 to refine the pial surface?
 
 Also, I'd like to make sure we are using dcmunpack properly. We take the
>>> scan.info file and parse it like this: "-run [MEMPRAGE_4e_p2_1mm_iso run
>>> number] 3danat mgz 001.mgz" so the multi echo scan gets put into one mgz
>>> file, and the RMS gets put into a separate mgz file.
 Thanks,
 -Kayle
 
 On May 9, 2013, at 12:00 PM, freesurfer-requ...@nmr.mgh.harvard.edu wrote:
> Message: 35
> Date: Thu, 9 May 2013 10:44:23 -0400 (EDT)
> From: Bruce Fischl 
> Subject: Re: [Freesurfer] Working with MEMPRAGE
> To: Jonathan Holt 
> Cc: freesurfer@nmr.mgh.harvard.edu
> Message-ID:
>
> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
> 
> it needs to be:
> 
> mris_make_surfaces -dura memprage_echo%d.mgz 4 subjid lh
> 
> note the "4" which tells it how many echoes to read
> 
> On Thu, 9 May 2013, Jonathan Holt wrote:
> 
>> I input:
>> 
>> mris_make_surfaces -dura memprage_echo%d.mgz subjid lh
>> 
>> it returns:
>> 
>> detecting dura using 0 echos from memprage_echo%d.mgz
>> 
>> 
>> Should I execute the command in the same directory as the mgz's? Should 
>> they be set up or placed in a specific directory? I also, as with 
>> recon-all, exported the proper subject directory beforehand.
>> 
>> 
>> On May 9, 2013, at 10:37 AM, Bruce Fischl wrote:
>> 
>>> can you send me the full command line? It should say 4 echoes, not 0
>>> On Thu, 9 May 2013, Jonathan Holt wrote:
>>> 
 Thanks Bruce,
 
 should the hemisphere's be processed separately, or how do I signify 
 lh and rh simultaneously?
 
 Also, should the fact that after running mris_make_surfaces, it says 
 "detecting dura using 0 echos from memprage_echo%d.mgz" be worrisome? 
 I've got 4 different echos, all mgz

Re: [Freesurfer] Working with MEMPRAGE

[Bruce Fischl]

Hi Jon

there shouldn't be more surfaces I don't think - the ?h.white and 
?h.pial should still be the ones you look at
Bruce


On Mon, 13 May 2013, Jonathan Holt wrote:

> Hi all,
>
> last question promise. Successfully completed mris_make_surfaces for both 
> hemispheres. in my day-to-day editing I open tkmedit thusly:
>
> tkmedit  brainmask.mgz -aux $SUBJECTS_DIR/subjid/mri/wm.mgz -surface 
> $SUBJECTS_DIR/subjid/surf/lh.white -aux-surface 
> $SUBJECTS_DIR/subjid/surf/rh.white -aparc+aseg
>
> this works for mprage subjects. In evaluating and possibly editing MEMPRAGE 
> subjects, which surfaces should I have opened in tkmedit, as there seem to be 
> many more this time around.
>
> best,
> jon
> On May 11, 2013, at 6:49 PM, Bruce Fischl wrote:
>
>> Hi Kayle
>>
>> it's been a long time since I wrote that code and we've only run it a few
>> times. If you upload your subject directory I'll take a look
>>
>> cheers
>> Bruce
>> On Sat, 11 May
>> 2013, Kayle Sawyer wrote:
>>
>>> Hi all,
>>>
>>> I tried to use the 4-echo MEMPRAGE dura detection for mris_make_surfaces, 
>>> but I'm not sure if it worked. The terminal output, including commands, is 
>>> attached. It was run with version 
>>> freesurfer-Linux-centos6_x86_64-stable-v5.3.0-BETA-20130509.
>>>
>>> On the original recon, in the rh, there is a segment of dura marked as grey 
>>> inside the pial line, at 94 111 169. The surfaces did not appear to change 
>>> substantially after I reran mris_make_surfaces with the -dura flag 
>>> specifying the 4-echo MEMPRAGE, which I placed in the mri directory. You 
>>> can see the before and after for yourself on the attached screenshots, or 
>>> if you have NMR access, here:
>>> /space/ficus/6/users/SNEF_edits/OB01_orig/
>>> /space/ficus/6/users/SNEF_edits/OB01_orig_dura/
>>>
>>> I saw this output from mris_make_surfaces for the rh, so maybe -dura did 
>>> correct a different defect?
>>> 7 non-cortical segments detected
>>> only using segment with 1900 vertices
>>>
>>> Any help would be appreciated, because we have over 130 brains and the 
>>> fewer manual corrections, the better!
>>>
>>> Thanks,
>>> -Kayle
>>>
>>>
>>>
>>>
>>> From: Douglas Greve 
>>> Date: Thu, May 9, 2013 at 8:44 PM
>>> Subject: Re: [Freesurfer] Working with MEMPRAGE
>>> To: freesurfer@nmr.mgh.harvard.edu
>>>
>>>
>>>
>>> the dcmunpack command is right. You should make sure to analyze only the
>>> RMS in recon-all (ie , that is the only volume that goes into mri/orig
>>> doug
>>>
>>>
>>> On 5/9/13 6:48 PM, Bruce Fischl wrote:
 Hi Kayle

 you would run recon-all on the RMS, then run the dura stuff posthoc.

 cheers
 Bruce
 On Thu,
 9 May 2013, Kayle Sawyer wrote:

> Hi all,
>
> Can the MEMPRAGE be specified in recon-all with the -i flag? We have been 
> using the MEMPRAGE RMS scans and discarding the multiecho scans. If we 
> instead specify the multiecho scans for recon-all, do we need to give any 
> additional parameters (e.g. the number of echoes) for it to utilize the 4 
> echoes to detect dura and refine pial surfaces in mris_make_surfaces, as 
> described below? Or would we have to run recon-all with the RMS, then 
> after it finishes re-run mris_make_surfaces manually with the -dura flag 
> to refine the pial surface?
>
> Also, I'd like to make sure we are using dcmunpack properly. We take the
 scan.info file and parse it like this: "-run [MEMPRAGE_4e_p2_1mm_iso run
 number] 3danat mgz 001.mgz" so the multi echo scan gets put into one mgz
 file, and the RMS gets put into a separate mgz file.
> Thanks,
> -Kayle
>
> On May 9, 2013, at 12:00 PM, freesurfer-requ...@nmr.mgh.harvard.edu wrote:
>> Message: 35
>> Date: Thu, 9 May 2013 10:44:23 -0400 (EDT)
>> From: Bruce Fischl 
>> Subject: Re: [Freesurfer] Working with MEMPRAGE
>> To: Jonathan Holt 
>> Cc: freesurfer@nmr.mgh.harvard.edu
>> Message-ID:
>>
>> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>>
>> it needs to be:
>>
>> mris_make_surfaces -dura memprage_echo%d.mgz 4 subjid lh
>>
>> note the "4" which tells it how many echoes to read
>>
>> On Thu, 9 May 2013, Jonathan Holt wrote:
>>
>>> I input:
>>>
>>> mris_make_surfaces -dura memprage_echo%d.mgz subjid lh
>>>
>>> it returns:
>>>
>>> detecting dura using 0 echos from memprage_echo%d.mgz
>>>
>>>
>>> Should I execute the command in the same directory as the mgz's? Should 
>>> they be set up or placed in a specific directory? I also, as with 
>>> recon-all, exported the proper subject directory beforehand.
>>>
>>>
>>> On May 9, 2013, at 10:37 AM, Bruce Fischl wrote:
>>>
 can you send me the full command line? It should say 4 echoes, not 0
 On Thu, 9 May 2013, Jonathan Holt wrote:

> Thanks Bruce,
>
> should the hemisphere's be processed s

Re: [Freesurfer] Restricting ROI Analysis

[Jon Wieser]

it there a way to mask the data before running the Qdec analysis on it?

- Original Message -
From: "Douglas Greve" 
To: freesurfer@nmr.mgh.harvard.edu
Sent: Sunday, May 12, 2013 11:24:12 PM
Subject: Re: [Freesurfer] Restricting ROI Analysis

Hi Skyler, I don't think we have the ability to restrict the analysis to 
an ROI in QDEC. You can do it with mri_glmfit with the --mask or --label 
option.
doug


On 5/12/13 4:25 PM, Skyler Gabriel Shollenbarger wrote:
> Hi everyone,
>
> We are trying to restrict an analysis using Qdec to a region of interest. We 
> have successfully created the ROI mask, however the analysis continues to be 
> run on the entire brain. Any help is greatly appreciated.
>
> Thanks,
> Skyler and Jon
>

___
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.


-- 
Jon Wieser
Research Specialist
UW-Milwaukee
Psychology Department, Pearse Hall Rm 366
2441 East Hartford Ave
Milwaukee, WI 53211
Phone: 414-229-7145
Fax: 414-229-5219
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Working with MEMPRAGE

[Jonathan Holt]

Bruce,

how is it that I might load multiple surfaces, loading lh after having loaded 
rh makes the other disappear. this is loading manually, not from the command 
line 
On May 13, 2013, at 11:14 AM, Jonathan Holt wrote:

> Hi all,
> 
> last question promise. Successfully completed mris_make_surfaces for both 
> hemispheres. in my day-to-day editing I open tkmedit thusly:
> 
> tkmedit  brainmask.mgz -aux $SUBJECTS_DIR/subjid/mri/wm.mgz -surface 
> $SUBJECTS_DIR/subjid/surf/lh.white -aux-surface 
> $SUBJECTS_DIR/subjid/surf/rh.white -aparc+aseg 
> 
> this works for mprage subjects. In evaluating and possibly editing MEMPRAGE 
> subjects, which surfaces should I have opened in tkmedit, as there seem to be 
> many more this time around.
> 
> best,
> jon
> On May 11, 2013, at 6:49 PM, Bruce Fischl wrote:
> 
>> Hi Kayle
>> 
>> it's been a long time since I wrote that code and we've only run it a few 
>> times. If you upload your subject directory I'll take a look
>> 
>> cheers
>> Bruce
>> On Sat, 11 May 
>> 2013, Kayle Sawyer wrote:
>> 
>>> Hi all,
>>> 
>>> I tried to use the 4-echo MEMPRAGE dura detection for mris_make_surfaces, 
>>> but I'm not sure if it worked. The terminal output, including commands, is 
>>> attached. It was run with version 
>>> freesurfer-Linux-centos6_x86_64-stable-v5.3.0-BETA-20130509.
>>> 
>>> On the original recon, in the rh, there is a segment of dura marked as grey 
>>> inside the pial line, at 94 111 169. The surfaces did not appear to change 
>>> substantially after I reran mris_make_surfaces with the -dura flag 
>>> specifying the 4-echo MEMPRAGE, which I placed in the mri directory. You 
>>> can see the before and after for yourself on the attached screenshots, or 
>>> if you have NMR access, here:
>>> /space/ficus/6/users/SNEF_edits/OB01_orig/
>>> /space/ficus/6/users/SNEF_edits/OB01_orig_dura/
>>> 
>>> I saw this output from mris_make_surfaces for the rh, so maybe -dura did 
>>> correct a different defect?
>>> 7 non-cortical segments detected
>>> only using segment with 1900 vertices
>>> 
>>> Any help would be appreciated, because we have over 130 brains and the 
>>> fewer manual corrections, the better!
>>> 
>>> Thanks,
>>> -Kayle
>>> 
>>> 
>>> 
>>> 
>>> From: Douglas Greve 
>>> Date: Thu, May 9, 2013 at 8:44 PM
>>> Subject: Re: [Freesurfer] Working with MEMPRAGE
>>> To: freesurfer@nmr.mgh.harvard.edu
>>> 
>>> 
>>> 
>>> the dcmunpack command is right. You should make sure to analyze only the
>>> RMS in recon-all (ie , that is the only volume that goes into mri/orig
>>> doug
>>> 
>>> 
>>> On 5/9/13 6:48 PM, Bruce Fischl wrote:
 Hi Kayle
 
 you would run recon-all on the RMS, then run the dura stuff posthoc.
 
 cheers
 Bruce
 On Thu,
 9 May 2013, Kayle Sawyer wrote:
 
> Hi all,
> 
> Can the MEMPRAGE be specified in recon-all with the -i flag? We have been 
> using the MEMPRAGE RMS scans and discarding the multiecho scans. If we 
> instead specify the multiecho scans for recon-all, do we need to give any 
> additional parameters (e.g. the number of echoes) for it to utilize the 4 
> echoes to detect dura and refine pial surfaces in mris_make_surfaces, as 
> described below? Or would we have to run recon-all with the RMS, then 
> after it finishes re-run mris_make_surfaces manually with the -dura flag 
> to refine the pial surface?
> 
> Also, I'd like to make sure we are using dcmunpack properly. We take the
 scan.info file and parse it like this: "-run [MEMPRAGE_4e_p2_1mm_iso run
 number] 3danat mgz 001.mgz" so the multi echo scan gets put into one mgz
 file, and the RMS gets put into a separate mgz file.
> Thanks,
> -Kayle
> 
> On May 9, 2013, at 12:00 PM, freesurfer-requ...@nmr.mgh.harvard.edu wrote:
>> Message: 35
>> Date: Thu, 9 May 2013 10:44:23 -0400 (EDT)
>> From: Bruce Fischl 
>> Subject: Re: [Freesurfer] Working with MEMPRAGE
>> To: Jonathan Holt 
>> Cc: freesurfer@nmr.mgh.harvard.edu
>> Message-ID:
>>   
>> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>> 
>> it needs to be:
>> 
>> mris_make_surfaces -dura memprage_echo%d.mgz 4 subjid lh
>> 
>> note the "4" which tells it how many echoes to read
>> 
>> On Thu, 9 May 2013, Jonathan Holt wrote:
>> 
>>> I input:
>>> 
>>> mris_make_surfaces -dura memprage_echo%d.mgz subjid lh
>>> 
>>> it returns:
>>> 
>>> detecting dura using 0 echos from memprage_echo%d.mgz
>>> 
>>> 
>>> Should I execute the command in the same directory as the mgz's? Should 
>>> they be set up or placed in a specific directory? I also, as with 
>>> recon-all, exported the proper subject directory beforehand.
>>> 
>>> 
>>> On May 9, 2013, at 10:37 AM, Bruce Fischl wrote:
>>> 
 can you send me the full command line? It should say 4 echoes, not 0
 On Thu, 9 May 2013, Jonathan Holt wro

Re: [Freesurfer] Working with MEMPRAGE

[Bruce Fischl]

you can use file->aux-surfaces->load aux main surface (or something like 
that). Or use freeview.

cheers
Bruce
On Mon, 13 May 2013, Jonathan Holt wrote:

> Bruce,
>
> how is it that I might load multiple surfaces, loading lh after having loaded 
> rh makes the other disappear. this is loading manually, not from the command 
> line
> On May 13, 2013, at 11:14 AM, Jonathan Holt wrote:
>
>> Hi all,
>>
>> last question promise. Successfully completed mris_make_surfaces for both 
>> hemispheres. in my day-to-day editing I open tkmedit thusly:
>>
>> tkmedit  brainmask.mgz -aux $SUBJECTS_DIR/subjid/mri/wm.mgz -surface 
>> $SUBJECTS_DIR/subjid/surf/lh.white -aux-surface 
>> $SUBJECTS_DIR/subjid/surf/rh.white -aparc+aseg
>>
>> this works for mprage subjects. In evaluating and possibly editing MEMPRAGE 
>> subjects, which surfaces should I have opened in tkmedit, as there seem to 
>> be many more this time around.
>>
>> best,
>> jon
>> On May 11, 2013, at 6:49 PM, Bruce Fischl wrote:
>>
>>> Hi Kayle
>>>
>>> it's been a long time since I wrote that code and we've only run it a few
>>> times. If you upload your subject directory I'll take a look
>>>
>>> cheers
>>> Bruce
>>> On Sat, 11 May
>>> 2013, Kayle Sawyer wrote:
>>>
 Hi all,

 I tried to use the 4-echo MEMPRAGE dura detection for mris_make_surfaces, 
 but I'm not sure if it worked. The terminal output, including commands, is 
 attached. It was run with version 
 freesurfer-Linux-centos6_x86_64-stable-v5.3.0-BETA-20130509.

 On the original recon, in the rh, there is a segment of dura marked as 
 grey inside the pial line, at 94 111 169. The surfaces did not appear to 
 change substantially after I reran mris_make_surfaces with the -dura flag 
 specifying the 4-echo MEMPRAGE, which I placed in the mri directory. You 
 can see the before and after for yourself on the attached screenshots, or 
 if you have NMR access, here:
 /space/ficus/6/users/SNEF_edits/OB01_orig/
 /space/ficus/6/users/SNEF_edits/OB01_orig_dura/

 I saw this output from mris_make_surfaces for the rh, so maybe -dura did 
 correct a different defect?
 7 non-cortical segments detected
 only using segment with 1900 vertices

 Any help would be appreciated, because we have over 130 brains and the 
 fewer manual corrections, the better!

 Thanks,
 -Kayle




 From: Douglas Greve 
 Date: Thu, May 9, 2013 at 8:44 PM
 Subject: Re: [Freesurfer] Working with MEMPRAGE
 To: freesurfer@nmr.mgh.harvard.edu



 the dcmunpack command is right. You should make sure to analyze only the
 RMS in recon-all (ie , that is the only volume that goes into mri/orig
 doug


 On 5/9/13 6:48 PM, Bruce Fischl wrote:
> Hi Kayle
>
> you would run recon-all on the RMS, then run the dura stuff posthoc.
>
> cheers
> Bruce
> On Thu,
> 9 May 2013, Kayle Sawyer wrote:
>
>> Hi all,
>>
>> Can the MEMPRAGE be specified in recon-all with the -i flag? We have 
>> been using the MEMPRAGE RMS scans and discarding the multiecho scans. If 
>> we instead specify the multiecho scans for recon-all, do we need to give 
>> any additional parameters (e.g. the number of echoes) for it to utilize 
>> the 4 echoes to detect dura and refine pial surfaces in 
>> mris_make_surfaces, as described below? Or would we have to run 
>> recon-all with the RMS, then after it finishes re-run mris_make_surfaces 
>> manually with the -dura flag to refine the pial surface?
>>
>> Also, I'd like to make sure we are using dcmunpack properly. We take the
> scan.info file and parse it like this: "-run [MEMPRAGE_4e_p2_1mm_iso run
> number] 3danat mgz 001.mgz" so the multi echo scan gets put into one mgz
> file, and the RMS gets put into a separate mgz file.
>> Thanks,
>> -Kayle
>>
>> On May 9, 2013, at 12:00 PM, freesurfer-requ...@nmr.mgh.harvard.edu 
>> wrote:
>>> Message: 35
>>> Date: Thu, 9 May 2013 10:44:23 -0400 (EDT)
>>> From: Bruce Fischl 
>>> Subject: Re: [Freesurfer] Working with MEMPRAGE
>>> To: Jonathan Holt 
>>> Cc: freesurfer@nmr.mgh.harvard.edu
>>> Message-ID:
>>>   
>>> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>>>
>>> it needs to be:
>>>
>>> mris_make_surfaces -dura memprage_echo%d.mgz 4 subjid lh
>>>
>>> note the "4" which tells it how many echoes to read
>>>
>>> On Thu, 9 May 2013, Jonathan Holt wrote:
>>>
 I input:

 mris_make_surfaces -dura memprage_echo%d.mgz subjid lh

 it returns:

 detecting dura using 0 echos from memprage_echo%d.mgz


 Should I execute the command in the same directory as the mgz's? 
 Should they be set up or placed in a specific directory? I also, as 
 with recon-al

Re: [Freesurfer] smoothing result with larger size FWHM kernel

[Douglas N Greve]

Hi Glen, if it is just a slab, you are probably smoothing in a bunch of 
0s. Try smoothing only the areas within a mask of the slab. You can do 
this by passing a label to mri_surf2surf ( you can also create a mask 
and pass it to mris_fwhm).
doug
On 05/13/2013 10:12 AM, Glen Lee wrote:
> Inline image 3Dear freesurfer expert
>
> I've tried both relatively small and large size of smoothing kernel 
> (i.e., 4mm vs. 10mm) on the surface EPI data using 
> mri_surf2surf function (e.g., mri_surf2surf --hemi lh --s 
> fsaverage_sym --fwhm )
>
> Attached are displays of raw EPI, 4mm, and 10 mm FWHM.
> As can be seen, the areas being smoothed by 10mm FWHM is quite off 
> from those in the raw 2D EPI whereas 4mm result looks reasonable.
>
>
> If anyone has some intuition about why this happened, please help me.
> -Glen
> ps) the area with colors show vertices with non-zeros values (also it 
> was reconstructed from slap EPI)
>
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

-- 
Douglas N. Greve, Ph.D.
MGH-NMR Center
gr...@nmr.mgh.harvard.edu
Phone Number: 617-724-2358
Fax: 617-726-7422

Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

___
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] Correction for multiple comparisons question

[Douglas N Greve]

On 05/13/2013 11:11 AM, Fotiadis, Panagiotis wrote:
> Thanks for the clarifications, Doug!
>
> 1) I am using FS stable version 5.0.0, so I'm assuming that the --2spaces 
> flag has probably been implemented for the more recent FS versions.
>
> 2) Thanks, that makes a lot more sense now.
>
> In addition, since clusters are formed based on the number of neighboring 
> voxels above the set voxel-based threshold, how is it possible to have 
> reported (from the summary) clusters that have a cluster-wise p value higher 
> than the voxel-based one? Isn't the cluster-wise p value of a cluster the 
> maximum p value of all the contiguous voxels in that cluster?
The cluster-wise p-value is independent from the voxel-wise (ie, cluster 
forming) p-value. The clusterwise p-value is not the maximum of the 
p-values inside the cluster.
>
> Thanks again for all your help.
> Panos
>
>
>
>
> 
> From: freesurfer-boun...@nmr.mgh.harvard.edu 
> [freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Douglas Greve 
> [gr...@nmr.mgh.harvard.edu]
> Sent: Monday, May 13, 2013 12:22 AM
> To: freesurfer@nmr.mgh.harvard.edu
> Subject: Re: [Freesurfer] Correction for multiple comparisons question
>
> Hi Panagiotis,
>
> On 5/12/13 9:32 PM, Fotiadis, Panagiotis wrote:
>> Hi Freesurfer experts,
>>
>> I was wondering about three things concerning the use of the mri_glmfit-sim 
>> command:
>>
>> 1) I tried running it with the --2spaces flag in order to Bonferroni correct 
>> over the two hemispheres but it tells me that the specific flag is not 
>> recognized. Is there another way to correct over the two hemispheres?
> What version are you using? You can just adjust the clusterwise
> threshold by dividing by 2 (eg, if you want a clusterwise threshold of
> .05, then set it to .025)
>> 2) I set the cluster-based threshold to 0.999 in order to see all of the 
>> clusters and varied the voxel-based threshold in order to see the 
>> differences that it would make on the results. Specifically, i set it to be 
>> 1.3, 2.0, 2.3, and 3.0. Between the four different occurring cluster 
>> summaries, there was only one common cluster that appeared in all four 
>> summaries. As expected, the number of voxels of the specific cluster was 
>> decreasing as its voxel-wise threshold was increasing.
>>
>> a)  However, the reported cluster-wise threshold  varied between 0.05 to 
>> 0.96 in those four cases. Does this sound reasonable? Shouldn't the cluster 
>> wise p values of the same cluster-between the four cases-be less dispersed?
> I'm not sure what you mean here. At 3.0, the cluster may be very small
> and so could appear to be very insignificant.
>> b)  If there is a cluster reported in only one of the four summaries (i.e. 
>> when the voxel-based threshold is 1.3) that say has a cluster-wise p value 
>> of 0.03, do I consider that significant or not, since it does not appear in 
>> any other summary with such a low cluster wise p value and since the only 
>> published p value is the cluster wise one?
> In principle, it is significant. A lot of reviewers balk at such a
> liberal voxel-wise threshold since gaussian random fields breaks down at
> liberal thresholds. However, this uses simulations and not GRF. You
> should make sure the reviewers know this. There still might be some
> resistance since you could be picking up some low spatial frequency
> trends (ie, stuff that is not spatially gaussian) in addition to your
> true activation.
>
> doug
>> Thank you in advance for your time,
>> Panagiotis Fotiadis
>> ___
>> 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
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>

-- 
Douglas N. Greve, Ph.D.
MGH-NMR Center
gr...@nmr.mgh.harvard.edu
Phone Number: 617-724-2358
Fax: 617-726-7422

Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

___
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 

Re: [Freesurfer] Restricting ROI Analysis

[Douglas N Greve]

no
doug
On 05/13/2013 11:16 AM, Jon Wieser wrote:
> it there a way to mask the data before running the Qdec analysis on it?
>
> - Original Message -
> From: "Douglas Greve" 
> To: freesurfer@nmr.mgh.harvard.edu
> Sent: Sunday, May 12, 2013 11:24:12 PM
> Subject: Re: [Freesurfer] Restricting ROI Analysis
>
> Hi Skyler, I don't think we have the ability to restrict the analysis to
> an ROI in QDEC. You can do it with mri_glmfit with the --mask or --label
> option.
> doug
>
>
> On 5/12/13 4:25 PM, Skyler Gabriel Shollenbarger wrote:
>> Hi everyone,
>>
>> We are trying to restrict an analysis using Qdec to a region of interest. We 
>> have successfully created the ROI mask, however the analysis continues to be 
>> run on the entire brain. Any help is greatly appreciated.
>>
>> Thanks,
>> Skyler and Jon
>>
> ___
> 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.
>
>

-- 
Douglas N. Greve, Ph.D.
MGH-NMR Center
gr...@nmr.mgh.harvard.edu
Phone Number: 617-724-2358
Fax: 617-726-7422

Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

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

Re: [Freesurfer] optseq2 malloc memory / matrix rank-deficient

[Douglas N Greve]

I think you are at the limit of what is possible. You have TR=2 and 
Ntp=255 for a total scan time of 510sec. You have 9 event types, each 
5stim+2null=7sec long, each repeated 8 times. This calls for 504 for 
stimulation and so only 6 sec total left for jitter.
doug




On 05/13/2013 05:28 AM, Koolschijn, Cédric wrote:
> Dear FS-experts,
>
> I've been using optseq for many years without problems, however, I run 
> into a couple now.
> My code is the following:
>
> optseq2 --ntp 255 --tr 2.0 --tprescan 4.0 --psdwin 0.0 16.0 1 --ev 
> Gain2 5.0 8.0 --ev Gain4 5.0 8.0 --ev Gain6 5.0 8.0 --ev Gain8 5.0 8.0 
> --ev Loss2 5.0 8.0 --ev Loss4 5.0 8.0 --ev Loss6 5.0 8.0 --ev Loss8 
> 5.0 8.0 --ev Catch 5.0 8.0 --tnullmin 2.0 --tnullmax 6.0 --tsearch 24 
> --focb 100 --ar1 .37 --evc 1 1 1 1 -1 -1 -1 -1 0 --evc -1.5 -.5 .5 1.5 
> -1.5 -.5 .5 1.5 0 --evc -1.5 -.5 .5 1.5 1.5 .5 -.5 -1.5 0 --cost eff 
> --nkeep 3 --o output_run1
>
> If I run this on a computational cluster (CentOS 5) with more than 
> enough RAM, I get the following message after on screen summary:
> outstem = output_run1
> *** glibc detected *** optseq2: malloc(): memory corruption: 
> 0x03f3e4e0 ***
> *** glibc detected *** optseq2: malloc(): memory corruption: 
> 0x03f3e4e0 ***
>
> And nothing happens after that.
>
> If I run the same code on my iMac Lion 10.7.5, it seems to be working, 
> but I get multiple "warnings":
> /usr/pubsw/packages/vxl/1.13.0/src/core/vnl/algo/vnl_qr.txx: 
> vnl_qr::solve() : matrix is rank-deficient by 112
>
> The number at the end changes each time.
> In addition, the process consumes my RAM (8GB) like it's nothing.
>
> The strange thing is, I do get usable output.
>
>
> Any ideas what might be causing this?
>
> Many thanks!
>
> Cédric
>
> 
> P.C.M.P. Koolschijn (Cédric), PhD
> Dutch Autism & ADHD Research Center
> Brain and Cognition
> Amsterdam, The Netherlands
> /E /p.c.m.p.koolsch...@uva.nl 
> /W /http://www.dutcharc.nl
>
>
>
>
>
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

-- 
Douglas N. Greve, Ph.D.
MGH-NMR Center
gr...@nmr.mgh.harvard.edu
Phone Number: 617-724-2358
Fax: 617-726-7422

Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

___
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] Binary volume to surface label

[Jonathan DuBois]

Sorry, I wasn't adjusting the overlay values so I couldn't see it. Thanks
for your help!

Best,
Jonathan


On Mon, May 13, 2013 at 11:09 AM, Bruce Fischl
wrote:

> you should be able to load it into tksurfer as an overlay.
>
> cheers
> Bruce
>
> On Mon, 13 May 2013, Jonathan DuBois wrote:
>
>  Hi Bruce,
>> Thanks for your help yesterday. I was able to create the .mgh file using
>> the -output_type mgh option, but I am still unable to
>> load it in tksurfer as label or anything else. If you or Doug have any
>> other suggestions, I would really appreciate it. Thanks!
>>
>> Jonathan
>>
>>
>> On Sun, May 12, 2013 at 4:55 PM, Bruce Fischl 
>> wrote:
>>   Hi Jonathan
>>
>>   try -output_type mgh. It should create a "volume" that is nvertices
>> long. Not sure if it can directly create a label
>>   file, maybe Doug knows?
>>
>>   Bruce
>>
>>
>>   On Sun, 12 May 2013, Jonathan DuBois wrote:
>>
>>   I used the following options: mri_vol2surf --hemi lh --regheader
>> subject01
>> --cortex --mov label.mgz --o ./label.mghIt ran without error, but I could
>> not open the resulting file in tksurfer as either a label or an overlay:
>> -
>> /Applications/freesurfer/**tktools/tksurfer.bin: no data in label file
>> /Users/label.mgh
>> tkmedit: Trying to open /Users/label.dat
>> surfer: Interpreting overlay volume /Users/label.mgh as encoded scalar
>> volume
>>
>> Best,
>> Jonathan
>>
>>
>> On Sun, May 12, 2013 at 1:57 PM, Bruce Fischl > >
>> wrote:
>>   try using --regheader
>>
>>   cheers
>>   Bruce
>>   On Sun, 12 May 2013, Jonathan DuBois wrote:
>>
>> Hi Bruce,
>> I would like to convert the .mgz label volume to a
>> surface label for that
>> subject, but mri_vol2surf requires a registration
>> file.
>>
>> Best,
>> Jonathan
>>
>>
>>
>> On Sunday, May 12, 2013, Bruce Fischl wrote:
>>   Hi Jonathan
>>
>>   you don't need to register it if it's shown
>> properly in tkmedit
>>   or freeview. Can you tell us more about what
>> you are trying to
>>   do?
>>   Bruce
>>
>>
>>   On Sun, 12 May 2013, Jonathan DuBois wrote:
>>
>> Hi Bruce,
>> Thanks for the quick response. The label
>> is a
>> manually traced area of the
>> cortex. It is in subject scanner space
>> and has a
>> single value, so it
>> probably would not work with bbregister.
>> I can load
>> it in tkmedit as a
>> segmentation and the alignment is
>> correct. I
>> attached a screenshot. Is there
>> a way to select the values greater than
>> zero in
>> tkmedit and save as a label
>> that could be used in vol2surf? I have
>> other labels
>> that are larger so I
>> would prefer not to retrace them if
>> possible.
>>
>> Inline image 2
>> Best,
>> Jonathan
>>
>>
>> On Sun, May 12, 2013 at 10:11 AM, Bruce
>> Fischl
>> 
>> wrote:
>>   Hi Jonathan
>>
>>   what is the label? What space is
>> it in? If it
>> has gray/white
>>   contrast you could try bbregister.
>>
>>   cheers
>>   Bruce
>>   On Sat, 11 May 2013, Jonathan
>> DuBois wrote:
>>
>> Hi Freesurfer Experts,
>> I have a binary volume label
>> in subject
>> space that I
>> converted from MINC to MGZ.
>> I would like
>> to register
>> it to
>> the surface of that subject
>> as a flat
>> label. I
>> thought I would be able to
>> do so with
>> mri_vol2surf
>> but I am not
>> sure how to generate the
>> required
>> registration file.
>> Is that the correct command,
>> and if so,
>> which
>> registration
>> 

Re: [Freesurfer] Binary volume to surface label

[Bruce Fischl]

sure, glad it's working
Bruce
On Mon, 13 May 2013, Jonathan DuBois wrote:


Sorry, I wasn't adjusting the overlay values so I couldn't see it. Thanks for 
your help!
Best, 
Jonathan


On Mon, May 13, 2013 at 11:09 AM, Bruce Fischl  
wrote:
  you should be able to load it into tksurfer as an overlay.

  cheers
  Bruce
  On Mon, 13 May 2013, Jonathan DuBois wrote:

Hi Bruce, 
Thanks for your help yesterday. I was able to create the .mgh file 
using the -output_type mgh option,
but I am still unable to
load it in tksurfer as label or anything else. If you or Doug have 
any other suggestions, I would really
appreciate it. Thanks!

Jonathan


On Sun, May 12, 2013 at 4:55 PM, Bruce Fischl 
 wrote:
      Hi Jonathan

      try -output_type mgh. It should create a "volume" that is 
nvertices long. Not sure if it can
directly create a label
      file, maybe Doug knows?

      Bruce


      On Sun, 12 May 2013, Jonathan DuBois wrote:

      I used the following options: mri_vol2surf --hemi lh 
--regheader subject01
--cortex --mov label.mgz --o ./label.mghIt ran without error, but I 
could
not open the resulting file in tksurfer as either a label or an 
overlay:
-
/Applications/freesurfer/tktools/tksurfer.bin: no data in label file
/Users/label.mgh
tkmedit: Trying to open /Users/label.dat
surfer: Interpreting overlay volume /Users/label.mgh as encoded 
scalar
volume

Best, 
Jonathan


On Sun, May 12, 2013 at 1:57 PM, Bruce Fischl 

wrote:
      try using --regheader

      cheers
      Bruce
      On Sun, 12 May 2013, Jonathan DuBois wrote:

            Hi Bruce, 
            I would like to convert the .mgz label volume to a
            surface label for that
            subject, but mri_vol2surf requires a registration
            file.

            Best, 
            Jonathan



            On Sunday, May 12, 2013, Bruce Fischl wrote:
                  Hi Jonathan

                  you don't need to register it if it's shown
            properly in tkmedit
                  or freeview. Can you tell us more about what
            you are trying to
                  do?
                  Bruce


                  On Sun, 12 May 2013, Jonathan DuBois wrote:

                        Hi Bruce, 
                        Thanks for the quick response. The label
            is a
                        manually traced area of the
                        cortex. It is in subject scanner space
            and has a
                        single value, so it
                        probably would not work with bbregister.
            I can load
                        it in tkmedit as a
                        segmentation and the alignment is
            correct. I
                        attached a screenshot. Is there
                        a way to select the values greater than
            zero in
                        tkmedit and save as a label
                        that could be used in vol2surf? I have
            other labels
                        that are larger so I
                        would prefer not to retrace them if
            possible.

                        Inline image 2
                        Best, 
                        Jonathan


                        On Sun, May 12, 2013 at 10:11 AM, Bruce
            Fischl
                        
                        wrote:
                              Hi Jonathan

                              what is the label? What space is
            it in? If it
                        has gray/white
                              contrast you could try bbregister.

                              cheers
                              Bruce
                              On Sat, 11 May 2013, Jonathan
            DuBois wrote:

                                    Hi Freesurfer Experts, 
                                    I have a binary volume label
            in subject
                        space that 

[Freesurfer] Different freesurfer version

[Oya, Hiroyuki (UI Health Care)]

Hello
Is it fine to process the anatomical data in v4.5 and analyze the results in 
v5.1?

Thanks,
Hiroyuki



Notice: This UI Health Care e-mail (including attachments) is covered by the 
Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and 
may be legally privileged.  If you are not the intended recipient, you are 
hereby notified that any retention, dissemination, distribution, or copying of 
this communication is strictly prohibited.  Please reply to the sender that you 
have received the message in error, then delete it.  Thank you.

___
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] Different freesurfer version

[Douglas N Greve]

yes, that is fine.
doug

On 05/13/2013 12:25 PM, Oya, Hiroyuki (UI Health Care) wrote:
>
> Hello
>
> Is it fine to process the anatomical data in v4.5 and analyze the 
> results in v5.1?
>
> Thanks,
>
> Hiroyuki
>
>
>
> 
> Notice: This UI Health Care e-mail (including attachments) is covered 
> by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is 
> confidential and may be legally privileged.  If you are not the 
> intended recipient, you are hereby notified that any retention, 
> dissemination, distribution, or copying of this communication is 
> strictly prohibited.  Please reply to the sender that you have 
> received the message in error, then delete it. Thank you.
> 
>
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

-- 
Douglas N. Greve, Ph.D.
MGH-NMR Center
gr...@nmr.mgh.harvard.edu
Phone Number: 617-724-2358
Fax: 617-726-7422

Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

___
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] Correction for multiple comparisons question

[Fotiadis, Panagiotis]

Great, thank you for your time!

Panos

From: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Douglas N Greve 
[gr...@nmr.mgh.harvard.edu]
Sent: Monday, May 13, 2013 11:56 AM
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] Correction for multiple comparisons question

On 05/13/2013 11:11 AM, Fotiadis, Panagiotis wrote:
> Thanks for the clarifications, Doug!
>
> 1) I am using FS stable version 5.0.0, so I'm assuming that the --2spaces 
> flag has probably been implemented for the more recent FS versions.
>
> 2) Thanks, that makes a lot more sense now.
>
> In addition, since clusters are formed based on the number of neighboring 
> voxels above the set voxel-based threshold, how is it possible to have 
> reported (from the summary) clusters that have a cluster-wise p value higher 
> than the voxel-based one? Isn't the cluster-wise p value of a cluster the 
> maximum p value of all the contiguous voxels in that cluster?
The cluster-wise p-value is independent from the voxel-wise (ie, cluster
forming) p-value. The clusterwise p-value is not the maximum of the
p-values inside the cluster.
>
> Thanks again for all your help.
> Panos
>
>
>
>
> 
> From: freesurfer-boun...@nmr.mgh.harvard.edu 
> [freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Douglas Greve 
> [gr...@nmr.mgh.harvard.edu]
> Sent: Monday, May 13, 2013 12:22 AM
> To: freesurfer@nmr.mgh.harvard.edu
> Subject: Re: [Freesurfer] Correction for multiple comparisons question
>
> Hi Panagiotis,
>
> On 5/12/13 9:32 PM, Fotiadis, Panagiotis wrote:
>> Hi Freesurfer experts,
>>
>> I was wondering about three things concerning the use of the mri_glmfit-sim 
>> command:
>>
>> 1) I tried running it with the --2spaces flag in order to Bonferroni correct 
>> over the two hemispheres but it tells me that the specific flag is not 
>> recognized. Is there another way to correct over the two hemispheres?
> What version are you using? You can just adjust the clusterwise
> threshold by dividing by 2 (eg, if you want a clusterwise threshold of
> .05, then set it to .025)
>> 2) I set the cluster-based threshold to 0.999 in order to see all of the 
>> clusters and varied the voxel-based threshold in order to see the 
>> differences that it would make on the results. Specifically, i set it to be 
>> 1.3, 2.0, 2.3, and 3.0. Between the four different occurring cluster 
>> summaries, there was only one common cluster that appeared in all four 
>> summaries. As expected, the number of voxels of the specific cluster was 
>> decreasing as its voxel-wise threshold was increasing.
>>
>> a)  However, the reported cluster-wise threshold  varied between 0.05 to 
>> 0.96 in those four cases. Does this sound reasonable? Shouldn't the cluster 
>> wise p values of the same cluster-between the four cases-be less dispersed?
> I'm not sure what you mean here. At 3.0, the cluster may be very small
> and so could appear to be very insignificant.
>> b)  If there is a cluster reported in only one of the four summaries (i.e. 
>> when the voxel-based threshold is 1.3) that say has a cluster-wise p value 
>> of 0.03, do I consider that significant or not, since it does not appear in 
>> any other summary with such a low cluster wise p value and since the only 
>> published p value is the cluster wise one?
> In principle, it is significant. A lot of reviewers balk at such a
> liberal voxel-wise threshold since gaussian random fields breaks down at
> liberal thresholds. However, this uses simulations and not GRF. You
> should make sure the reviewers know this. There still might be some
> resistance since you could be picking up some low spatial frequency
> trends (ie, stuff that is not spatially gaussian) in addition to your
> true activation.
>
> doug
>> Thank you in advance for your time,
>> Panagiotis Fotiadis
>> ___
>> 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
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>

--
Douglas N. Greve, Ph.D.
MGH-NMR Center
gr...@nmr.mgh.harvard.edu
Phone Number: 617-724-2358
Fax: 617-726-7422

Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

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

_

Re: [Freesurfer] beta v5.3 for fedora 18 and ubuntu 13

[Daniel Haehn]

Hi Nick,

I installed it on Ubuntu 13.04 and all tools seem to work. I didn't test
recon-all yet.

Cheers,
Daniel


On Sun, May 12, 2013 at 10:41 PM, Nick Schmansky
wrote:

> Fedora 18, Ubuntu 13 and Gentoo 64 users,
>
> another beta of the upcoming v5.3 is available here:
>
>
> ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/5.3.0-BETA/freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0-BETA.tar.gz
>
> this one is just intended for the Fedora 18, Ubuntu 13, Gentoo 64 users
> who wished to test that the segfault problem in v5.2 and the prior beta
> v5.3 is fixed.  Your help in testing this release is appreciated.
>
> Thanks,
>
> Nick
>
>
> ___
> 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.
>
>


-- 
Daniel Haehn
FNNDSC / BCH
+1.857.218.5140
___
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] Usage of --area option in estimating the vertex-wise maps of surface area

[Anderson M. Winkler]

Hi Xi-Nian,

As Doug said, they don't do the same thing. The method in the paper uses a
different kind of interpolation to allows the preservation of the amount of
area, whereas mris_preproc achieves the same globally using a Jacobian
correction. The results aren't expected to be identical at the vertex level
or for small regions.

An implementation of the method we proposed in the paper is available for
Octave and/or Matlab at http://brainder.org/download/areal
It works fine, but beware that it's quite slow.

All the best,

Anderson



2013/5/13 Douglas Greve 

>
> Hi Xi-Nian, it does not do the same thing, but it does something similar.
> Anderson found that it gave similar results in a lot of cases, but he has
> found some differences. If he's still following the FS list, maybe he can
> comment.
>
> doug
>
>
>
>
>
> On 5/11/13 9:53 PM, Xinian Zuo wrote:
>
> Hello Doug,
>
>  I am doing some association studies between functional measures and
> surface area. In using  mris_preproc, there is an option --area. Does this
> do sth similar to that as Winkler et al. (2012)?
>
>  Winkler et al., 2012. Measureing and comparing brain cortical
> surfacearea and other areal quantities.
>
>  Thank you very much.
> --
> Xi-Nian Zuo, Ph.D of Applied Mathematics (http://lfcd.psych.ac.cn)
> Google Scholar Citations:
> http://scholar.google.com/citations?user=a3-gVGMJ&hl=en
>
>
>
>
> ___
> Freesurfer mailing 
> listfreesur...@nmr.mgh.harvard.eduhttps://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.

[Freesurfer] parcellation boundaries freesurfer atlas

[Oort-4, J. van]

Dear freesurfer mailing list, I have got a question with regard to the 
freesurfer parcellation. I'm using the atlas with 68 cortical areas. I would 
like to determine where to locate anatomical and functional areas in this 
atlas. In this way I would like to locate the areas that are involved in 
processing auditory and visual information. I can't find any article that 
describes the anatomical boundaries that are used in the parcellation, or which 
Bradmann area is included in which parcel. Could You recommend an article or 
other resource where I could find this information?
greetings, Jasper van Oort

--

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct
te informeren door het bericht te retourneren. Het Universitair Medisch
Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de W.H.W.
(Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd bij
de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.

Denk s.v.p aan het milieu voor u deze e-mail afdrukt.

--

This message may contain confidential information and is intended exclusively
for the addressee. If you receive this message unintentionally, please do not
use the contents but notify the sender immediately by return e-mail. University
Medical Center Utrecht is a legal person by public law and is registered at
the Chamber of Commerce for Midden-Nederland under no. 30244197.

Please consider the environment before printing this 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] parcellation boundaries freesurfer atlas

[Bruce Fischl]

Hi Jasper

you can look in:
https://surfer.nmr.mgh.harvard.edu/pub/articles/HBM09-Destrieux-Sulcal.pdf

or if you have specific questions ask Christophe (ccd). The Brodmann area 
and functional boundaries generally don't simply follow the anatomy (except 
for V1). We also explictly label some of these:

https://surfer.nmr.mgh.harvard.edu/ftp/articles/fischl_cerebralcortex2008.pdf
http://surfer.nmr.mgh.harvard.edu/pub/articles/YNIMG6159.pdf
http://surfer.nmr.mgh.harvard.edu/pub/articles/Augustinack_predicting_perirhinal_2013.pdf
https://surfer.nmr.mgh.harvard.edu/ftp/articles/hinds2008accurate.pdf

cheers
Bruce

On 
Mon, 13 May 2013, Oort-4, J. van wrote:

> 
> Dear freesurfer mailing list, I have got a question with regard to the 
> freesurfer
> parcellation. I?m using the atlas with 68 cortical areas. I would like to 
> determine where to
> locate anatomical and functional areas in this atlas. In this way I would 
> like to locate the
> areas that are involved in processing auditory and visual information. I 
> can?t find any
> article that describes the anatomical boundaries that are used in the 
> parcellation, or which
> Bradmann area is included in which parcel. Could You recommend an article or 
> other resource
> where I could find this information?
> greetings, Jasper van Oort
> 
> __
> 
> De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is 
> uitsluitend bestemd voor
> de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht 
> de inhoud niet te
> gebruiken en de afzender direct te informeren door het bericht te 
> retourneren. Het
> Universitair Medisch Centrum Utrecht is een publiekrechtelijke rechtspersoon 
> in de zin van de
> W.H.W. (Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat 
> geregistreerd bij de Kamer
> van Koophandel voor Midden-Nederland onder nr. 30244197.
> 
> Denk s.v.p aan het milieu voor u deze e-mail afdrukt.
> 
> __
> 
> This message may contain confidential information and is intended exclusively 
> for the
> addressee. If you receive this message unintentionally, please do not use the 
> contents but
> notify the sender immediately by return e-mail. University Medical Center 
> Utrecht is a legal
> person by public law and is registered at the Chamber of Commerce for 
> Midden-Nederland under
> no. 30244197.
> 
> Please consider the environment before printing this 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] using T2* weighted scans to assist with dura stripping in a GE scanner?

[Inati, Souheil (NIH/NIMH) [E]]

Hi Matt,

Thanks for the link.

Reading on pages 29-31, I am struck by the complexity of the procedure.  Not to 
say that it doesn't work, or that the single T1w image free-surfer stuff is 
simple :-), on the contrary, it's just that I was expecting to see something 
about an optimization that used both images, rather than something based on the 
T1w image followed by an exclusion criterion based on the T2w image.  Anyway, 
works better than without.

Minor question on the acquisition of the anatomicals:
- Why are you using partial fourier in the read direction?  You're throwing 
away a lot of SNR at the high spatial frequencies, seems a shame to go to 0.7mm 
and then do that.

Cheers,
Souheil

On May 12, 2013, at 10:54 PM, Matt Glasser  wrote:

> This is available online now:
> 
> http://authors.elsevier.com/sd/article/S1053811913005053
> 
> 
> On 5/7/13 3:10 PM, "Bruce Fischl"  wrote:
> 
>> actually Matt Glasser points out that a brief description is in his paper
>> that is coming out soon, and there is also some description in Andre's
>> multi-echo mprage paper
>> Bruce
>> On Tue, 7 May 2013, Inati, Souheil (NIH/NIMH) [E]
>> wrote:
>> 
>>> thanks :-)
>>> 
>>> On May 7, 2013, at 3:28 PM, Bruce Fischl 
>>> wrote:
>>> 
 no, of course not :)
 
 On Tue, 7 May 2013, Inati, Souheil (NIH/NIMH) [E]
 wrote:
 
> Hi Bruce,
> 
> Out of curiosity and for reference for my users, do you have a paper
> on the T2 or FLAIR assisted segmentation?
> 
> Cheers,
> Souheil
> 
> -
> 
> Souheil Inati, PhD
> Staff Scientist
> FMRI Facility
> NIMH/NIH/DHHS
> souheil.in...@nih.gov
> 
> 
> 
> 
> On May 7, 2013, at 2:24 PM, Bruce Fischl
> mailto:fis...@nmr.mgh.harvard.edu>> wrote:
> 
> Hi Katie
> 
> I'm really not sure. These days I would recommend a highres (e.g. 1mm
> isotropic) FLAIR if you can get one, or T2 if not. The T2* can help,
> but
> it's pretty noisy in brain.
> 
> cheers
> Bruce
> 
> On Tue, 7 May 2013, Katie Surrence wrote:
> 
> Dear Freesurfer gurus,
> 
> At the course, André van der Kouwe mentioned in his morphometry
> methods talk that T2* weighted contrast from
> MEMPRAGE could be used to further seperate dura from cortex, as also
> discussed in this paper:
> http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2408694/.  We have a GE
> scanner in our lab.  The internet suggests
> that a Multi-echo FSPGR/FGRE exists.  Would this be the analog?
> Would it work the same way?  Could you also
> use these images with the mris_make_surfaces command?
> 
> Thanks very much for your insight -- and I enjoyed the course!
> 
> /Katie Surrence
> 
> --
> Research Coordinator
> Social Cognition Laboratory
> New York State Psychiatric Institute
> 
> ___
> 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.
> 
> 


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

[Freesurfer] Resting state analysis

[Efrat Kliper]

Dear freeSurfer expert,

I am trying to perform whole brain functional connectivity analysis

Is there a wiki for resting state analysis? I have only found this wiki page
https://surfer.nmr.mgh.harvard.edu/fswiki/FsFastTutorialV5.1/FsFastPreProc

So far I have run the following commands:

preproc-sess -s TB_482 -fsd Rest -stc odd -surface fsaverage lhrh -mni305
-fwhm 5 -per-run

What is the next step?

Should I use the mkanalysis-sess command?

(mkanalysis-sess -TR 3 -fsd Rest -stc odd -surface fsaverage lh -mni305
2  -fwhm 5 -analysis TB_482_lh -notask)?

Running this command it seems to create only an output file with a list of
information and nothing more, what am i doing wrong?



In addition for resting state analysis, band filter of 0.01-0.08Hz needs to
be done.  How do i do that and to which of the output files? I don’t find
any record about that either.


Thanks in advance,

Efrat
___
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] LGI radius on outer surface ?

[Gregory Kirk]

Hello

Im preparing an LGI(local gyrification index) manuscript and seems i don't
know the default radius that is used for the circular region defined on the 
outer surface
that the boundary of is then projected onto the pial surface to get the 
corresponding pial region ?

hope im clear, not the radius of the closing operator.

thank you

Greg
___
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] LGI radius on outer surface ?

[Marie Schaer]

Hello Gregory,

The radius of the circular region is 25 mm by default. If you want you can 
change it, but I will not advise radii below 20 mm or above 30 mm.

Best,

Marie

On May 13, 2013, at 11:44 AM, Gregory Kirk 
 wrote:

> 
> Hello
> 
> Im preparing an LGI(local gyrification index) manuscript and seems i don't
> know the default radius that is used for the circular region defined on the 
> outer surface
> that the boundary of is then projected onto the pial surface to get the 
> corresponding pial region ?
> 
> hope im clear, not the radius of the closing operator.
> 
> thank you
> 
> Greg
> ___
> 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

Re: [Freesurfer] Resting state analysis

[Douglas N Greve]

Hi Efrat, you've done the preproc-sess correctly, but you'll need to 
modify the mkanalysis-sess. See

http://surfer.nmr.mgh.harvard.edu/fswiki/FsFastFunctionalConnectivityWalkthrough

dpug


On 05/13/2013 02:26 PM, Efrat Kliper wrote:
>
> Dear freeSurfer expert,
>
> I am trying to perform whole brain functional connectivity analysis
>
> Is there a wiki for resting state analysis? I have only found this 
> wiki 
> pagehttps://surfer.nmr.mgh.harvard.edu/fswiki/FsFastTutorialV5.1/FsFastPreProc
>
> So far I have run the following commands:
>
> preproc-sess -s TB_482 -fsd Rest -stc odd -surface fsaverage lhrh 
> -mni305 -fwhm 5 -per-run
>
> What is the next step?
>
> Should I use the mkanalysis-sess command?
>
> (mkanalysis-sess -TR 3 -fsd Rest -stc odd -surface fsaverage lh 
> -mni305 2 -fwhm 5 -analysis TB_482_lh -notask)?
>
> Running this command it seems to create only an output file with a 
> list of information and nothing more, what am i doing wrong?
>
> In addition for resting state analysis,band filter of 0.01-0.08Hz 
> needs to be done.How do i do that and to which of the output files? I 
> don’t find any record about that either.
>
>
> Thanks in advance,
>
> Efrat
>
>
>
>
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

-- 
Douglas N. Greve, Ph.D.
MGH-NMR Center
gr...@nmr.mgh.harvard.edu
Phone Number: 617-724-2358
Fax: 617-726-7422

Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

___
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] Working with MEMPRAGE

[Bruce Fischl]

p.s. make sure that the echoes are in float format, not uchar/int/short 
(you need to use -odt float in the mri_convert command line)
On Mon, 13 May 
2013, Bruce Fischl wrote:

> you can use file->aux-surfaces->load aux main surface (or something like
> that). Or use freeview.
>
> cheers
> Bruce
> On Mon, 13 May 2013, Jonathan Holt wrote:
>
>> Bruce,
>>
>> how is it that I might load multiple surfaces, loading lh after having 
>> loaded rh makes the other disappear. this is loading manually, not from the 
>> command line
>> On May 13, 2013, at 11:14 AM, Jonathan Holt wrote:
>>
>>> Hi all,
>>>
>>> last question promise. Successfully completed mris_make_surfaces for both 
>>> hemispheres. in my day-to-day editing I open tkmedit thusly:
>>>
>>> tkmedit  brainmask.mgz -aux $SUBJECTS_DIR/subjid/mri/wm.mgz 
>>> -surface $SUBJECTS_DIR/subjid/surf/lh.white -aux-surface 
>>> $SUBJECTS_DIR/subjid/surf/rh.white -aparc+aseg
>>>
>>> this works for mprage subjects. In evaluating and possibly editing MEMPRAGE 
>>> subjects, which surfaces should I have opened in tkmedit, as there seem to 
>>> be many more this time around.
>>>
>>> best,
>>> jon
>>> On May 11, 2013, at 6:49 PM, Bruce Fischl wrote:
>>>
 Hi Kayle

 it's been a long time since I wrote that code and we've only run it a few
 times. If you upload your subject directory I'll take a look

 cheers
 Bruce
 On Sat, 11 May
 2013, Kayle Sawyer wrote:

> Hi all,
>
> I tried to use the 4-echo MEMPRAGE dura detection for mris_make_surfaces, 
> but I'm not sure if it worked. The terminal output, including commands, 
> is attached. It was run with version 
> freesurfer-Linux-centos6_x86_64-stable-v5.3.0-BETA-20130509.
>
> On the original recon, in the rh, there is a segment of dura marked as 
> grey inside the pial line, at 94 111 169. The surfaces did not appear to 
> change substantially after I reran mris_make_surfaces with the -dura flag 
> specifying the 4-echo MEMPRAGE, which I placed in the mri directory. You 
> can see the before and after for yourself on the attached screenshots, or 
> if you have NMR access, here:
> /space/ficus/6/users/SNEF_edits/OB01_orig/
> /space/ficus/6/users/SNEF_edits/OB01_orig_dura/
>
> I saw this output from mris_make_surfaces for the rh, so maybe -dura did 
> correct a different defect?
> 7 non-cortical segments detected
> only using segment with 1900 vertices
>
> Any help would be appreciated, because we have over 130 brains and the 
> fewer manual corrections, the better!
>
> Thanks,
> -Kayle
>
>
>
>
> From: Douglas Greve 
> Date: Thu, May 9, 2013 at 8:44 PM
> Subject: Re: [Freesurfer] Working with MEMPRAGE
> To: freesurfer@nmr.mgh.harvard.edu
>
>
>
> the dcmunpack command is right. You should make sure to analyze only the
> RMS in recon-all (ie , that is the only volume that goes into mri/orig
> doug
>
>
> On 5/9/13 6:48 PM, Bruce Fischl wrote:
>> Hi Kayle
>>
>> you would run recon-all on the RMS, then run the dura stuff posthoc.
>>
>> cheers
>> Bruce
>> On Thu,
>> 9 May 2013, Kayle Sawyer wrote:
>>
>>> Hi all,
>>>
>>> Can the MEMPRAGE be specified in recon-all with the -i flag? We have 
>>> been using the MEMPRAGE RMS scans and discarding the multiecho scans. 
>>> If we instead specify the multiecho scans for recon-all, do we need to 
>>> give any additional parameters (e.g. the number of echoes) for it to 
>>> utilize the 4 echoes to detect dura and refine pial surfaces in 
>>> mris_make_surfaces, as described below? Or would we have to run 
>>> recon-all with the RMS, then after it finishes re-run 
>>> mris_make_surfaces manually with the -dura flag to refine the pial 
>>> surface?
>>>
>>> Also, I'd like to make sure we are using dcmunpack properly. We take the
>> scan.info file and parse it like this: "-run [MEMPRAGE_4e_p2_1mm_iso run
>> number] 3danat mgz 001.mgz" so the multi echo scan gets put into one mgz
>> file, and the RMS gets put into a separate mgz file.
>>> Thanks,
>>> -Kayle
>>>
>>> On May 9, 2013, at 12:00 PM, freesurfer-requ...@nmr.mgh.harvard.edu 
>>> wrote:
 Message: 35
 Date: Thu, 9 May 2013 10:44:23 -0400 (EDT)
 From: Bruce Fischl 
 Subject: Re: [Freesurfer] Working with MEMPRAGE
 To: Jonathan Holt 
 Cc: freesurfer@nmr.mgh.harvard.edu
 Message-ID:
   
 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

 it needs to be:

 mris_make_surfaces -dura memprage_echo%d.mgz 4 subjid lh

 note the "4" which tells it how many echoes to read

 On Thu, 9 May 2013, Jonathan Holt wrote:

> I input:
>
> mris_make_surfaces -dura m

Re: [Freesurfer] Working with MEMPRAGE

[Jonathan Holt]

I'll definitely do that next time... 

although it didn't seem to pose any noticeable issues this time around? 

jon
On May 13, 2013, at 3:52 PM, Bruce Fischl wrote:

> p.s. make sure that the echoes are in float format, not uchar/int/short (you 
> need to use -odt float in the mri_convert command line)
> On Mon, 13 May 2013, Bruce Fischl wrote:
> 
>> you can use file->aux-surfaces->load aux main surface (or something like
>> that). Or use freeview.
>> 
>> cheers
>> Bruce
>> On Mon, 13 May 2013, Jonathan Holt wrote:
>> 
>>> Bruce,
>>> 
>>> how is it that I might load multiple surfaces, loading lh after having 
>>> loaded rh makes the other disappear. this is loading manually, not from the 
>>> command line
>>> On May 13, 2013, at 11:14 AM, Jonathan Holt wrote:
>>> 
 Hi all,
 
 last question promise. Successfully completed mris_make_surfaces for both 
 hemispheres. in my day-to-day editing I open tkmedit thusly:
 
 tkmedit  brainmask.mgz -aux $SUBJECTS_DIR/subjid/mri/wm.mgz 
 -surface $SUBJECTS_DIR/subjid/surf/lh.white -aux-surface 
 $SUBJECTS_DIR/subjid/surf/rh.white -aparc+aseg
 
 this works for mprage subjects. In evaluating and possibly editing 
 MEMPRAGE subjects, which surfaces should I have opened in tkmedit, as 
 there seem to be many more this time around.
 
 best,
 jon
 On May 11, 2013, at 6:49 PM, Bruce Fischl wrote:
 
> Hi Kayle
> 
> it's been a long time since I wrote that code and we've only run it a few
> times. If you upload your subject directory I'll take a look
> 
> cheers
> Bruce
> On Sat, 11 May
> 2013, Kayle Sawyer wrote:
> 
>> Hi all,
>> 
>> I tried to use the 4-echo MEMPRAGE dura detection for 
>> mris_make_surfaces, but I'm not sure if it worked. The terminal output, 
>> including commands, is attached. It was run with version 
>> freesurfer-Linux-centos6_x86_64-stable-v5.3.0-BETA-20130509.
>> 
>> On the original recon, in the rh, there is a segment of dura marked as 
>> grey inside the pial line, at 94 111 169. The surfaces did not appear to 
>> change substantially after I reran mris_make_surfaces with the -dura 
>> flag specifying the 4-echo MEMPRAGE, which I placed in the mri 
>> directory. You can see the before and after for yourself on the attached 
>> screenshots, or if you have NMR access, here:
>> /space/ficus/6/users/SNEF_edits/OB01_orig/
>> /space/ficus/6/users/SNEF_edits/OB01_orig_dura/
>> 
>> I saw this output from mris_make_surfaces for the rh, so maybe -dura did 
>> correct a different defect?
>> 7 non-cortical segments detected
>> only using segment with 1900 vertices
>> 
>> Any help would be appreciated, because we have over 130 brains and the 
>> fewer manual corrections, the better!
>> 
>> Thanks,
>> -Kayle
>> 
>> 
>> 
>> 
>> From: Douglas Greve 
>> Date: Thu, May 9, 2013 at 8:44 PM
>> Subject: Re: [Freesurfer] Working with MEMPRAGE
>> To: freesurfer@nmr.mgh.harvard.edu
>> 
>> 
>> 
>> the dcmunpack command is right. You should make sure to analyze only the
>> RMS in recon-all (ie , that is the only volume that goes into mri/orig
>> doug
>> 
>> 
>> On 5/9/13 6:48 PM, Bruce Fischl wrote:
>>> Hi Kayle
>>> 
>>> you would run recon-all on the RMS, then run the dura stuff posthoc.
>>> 
>>> cheers
>>> Bruce
>>> On Thu,
>>> 9 May 2013, Kayle Sawyer wrote:
>>> 
 Hi all,
 
 Can the MEMPRAGE be specified in recon-all with the -i flag? We have 
 been using the MEMPRAGE RMS scans and discarding the multiecho scans. 
 If we instead specify the multiecho scans for recon-all, do we need to 
 give any additional parameters (e.g. the number of echoes) for it to 
 utilize the 4 echoes to detect dura and refine pial surfaces in 
 mris_make_surfaces, as described below? Or would we have to run 
 recon-all with the RMS, then after it finishes re-run 
 mris_make_surfaces manually with the -dura flag to refine the pial 
 surface?
 
 Also, I'd like to make sure we are using dcmunpack properly. We take 
 the
>>> scan.info file and parse it like this: "-run [MEMPRAGE_4e_p2_1mm_iso run
>>> number] 3danat mgz 001.mgz" so the multi echo scan gets put into one mgz
>>> file, and the RMS gets put into a separate mgz file.
 Thanks,
 -Kayle
 
 On May 9, 2013, at 12:00 PM, freesurfer-requ...@nmr.mgh.harvard.edu 
 wrote:
> Message: 35
> Date: Thu, 9 May 2013 10:44:23 -0400 (EDT)
> From: Bruce Fischl 
> Subject: Re: [Freesurfer] Working with MEMPRAGE
> To: Jonathan Holt 
> Cc: freesurfer@nmr.mgh.harvard.edu
> Message-ID:
>  
> Content-Type: TEXT/PLAIN; format

Re: [Freesurfer] Working with MEMPRAGE

[Bruce Fischl]

I'm surprised it would work well if they are not float. You'll lose a lot 
of precision
On Mon, 13 May 2013, Jonathan Holt wrote:

> I'll definitely do that next time...
>
> although it didn't seem to pose any noticeable issues this time around?
>
> jon
> On May 13, 2013, at 3:52 PM, Bruce Fischl wrote:
>
>> p.s. make sure that the echoes are in float format, not uchar/int/short (you 
>> need to use -odt float in the mri_convert command line)
>> On Mon, 13 May 2013, Bruce Fischl wrote:
>>
>>> you can use file->aux-surfaces->load aux main surface (or something like
>>> that). Or use freeview.
>>>
>>> cheers
>>> Bruce
>>> On Mon, 13 May 2013, Jonathan Holt wrote:
>>>
 Bruce,

 how is it that I might load multiple surfaces, loading lh after having 
 loaded rh makes the other disappear. this is loading manually, not from 
 the command line
 On May 13, 2013, at 11:14 AM, Jonathan Holt wrote:

> Hi all,
>
> last question promise. Successfully completed mris_make_surfaces for both 
> hemispheres. in my day-to-day editing I open tkmedit thusly:
>
> tkmedit  brainmask.mgz -aux $SUBJECTS_DIR/subjid/mri/wm.mgz 
> -surface $SUBJECTS_DIR/subjid/surf/lh.white -aux-surface 
> $SUBJECTS_DIR/subjid/surf/rh.white -aparc+aseg
>
> this works for mprage subjects. In evaluating and possibly editing 
> MEMPRAGE subjects, which surfaces should I have opened in tkmedit, as 
> there seem to be many more this time around.
>
> best,
> jon
> On May 11, 2013, at 6:49 PM, Bruce Fischl wrote:
>
>> Hi Kayle
>>
>> it's been a long time since I wrote that code and we've only run it a few
>> times. If you upload your subject directory I'll take a look
>>
>> cheers
>> Bruce
>> On Sat, 11 May
>> 2013, Kayle Sawyer wrote:
>>
>>> Hi all,
>>>
>>> I tried to use the 4-echo MEMPRAGE dura detection for 
>>> mris_make_surfaces, but I'm not sure if it worked. The terminal output, 
>>> including commands, is attached. It was run with version 
>>> freesurfer-Linux-centos6_x86_64-stable-v5.3.0-BETA-20130509.
>>>
>>> On the original recon, in the rh, there is a segment of dura marked as 
>>> grey inside the pial line, at 94 111 169. The surfaces did not appear 
>>> to change substantially after I reran mris_make_surfaces with the -dura 
>>> flag specifying the 4-echo MEMPRAGE, which I placed in the mri 
>>> directory. You can see the before and after for yourself on the 
>>> attached screenshots, or if you have NMR access, here:
>>> /space/ficus/6/users/SNEF_edits/OB01_orig/
>>> /space/ficus/6/users/SNEF_edits/OB01_orig_dura/
>>>
>>> I saw this output from mris_make_surfaces for the rh, so maybe -dura 
>>> did correct a different defect?
>>> 7 non-cortical segments detected
>>> only using segment with 1900 vertices
>>>
>>> Any help would be appreciated, because we have over 130 brains and the 
>>> fewer manual corrections, the better!
>>>
>>> Thanks,
>>> -Kayle
>>>
>>>
>>>
>>>
>>> From: Douglas Greve 
>>> Date: Thu, May 9, 2013 at 8:44 PM
>>> Subject: Re: [Freesurfer] Working with MEMPRAGE
>>> To: freesurfer@nmr.mgh.harvard.edu
>>>
>>>
>>>
>>> the dcmunpack command is right. You should make sure to analyze only the
>>> RMS in recon-all (ie , that is the only volume that goes into mri/orig
>>> doug
>>>
>>>
>>> On 5/9/13 6:48 PM, Bruce Fischl wrote:
 Hi Kayle

 you would run recon-all on the RMS, then run the dura stuff posthoc.

 cheers
 Bruce
 On Thu,
 9 May 2013, Kayle Sawyer wrote:

> Hi all,
>
> Can the MEMPRAGE be specified in recon-all with the -i flag? We have 
> been using the MEMPRAGE RMS scans and discarding the multiecho scans. 
> If we instead specify the multiecho scans for recon-all, do we need 
> to give any additional parameters (e.g. the number of echoes) for it 
> to utilize the 4 echoes to detect dura and refine pial surfaces in 
> mris_make_surfaces, as described below? Or would we have to run 
> recon-all with the RMS, then after it finishes re-run 
> mris_make_surfaces manually with the -dura flag to refine the pial 
> surface?
>
> Also, I'd like to make sure we are using dcmunpack properly. We take 
> the
 scan.info file and parse it like this: "-run [MEMPRAGE_4e_p2_1mm_iso 
 run
 number] 3danat mgz 001.mgz" so the multi echo scan gets put into one 
 mgz
 file, and the RMS gets put into a separate mgz file.
> Thanks,
> -Kayle
>
> On May 9, 2013, at 12:00 PM, freesurfer-requ...@nmr.mgh.harvard.edu 
> wrote:
>> Message: 35
>> Date: Thu, 9 May 2013 10:44:23 -0

Re: [Freesurfer] Working with MEMPRAGE

[Jonathan Holt]

I wont question it, but this is my first multi echo brain and it's the most 
beautiful i've ever seen. so crisp. 

On May 13, 2013, at 3:55 PM, Bruce Fischl wrote:


> I'm surprised it would work well if they are not float. You'll lose a lot of 
> precision
> On Mon, 13 May 2013, Jonathan Holt wrote:
> 
>> I'll definitely do that next time...
>> 
>> although it didn't seem to pose any noticeable issues this time around?
>> 
>> jon
>> On May 13, 2013, at 3:52 PM, Bruce Fischl wrote:
>> 
>>> p.s. make sure that the echoes are in float format, not uchar/int/short 
>>> (you need to use -odt float in the mri_convert command line)
>>> On Mon, 13 May 2013, Bruce Fischl wrote:
>>> 
 you can use file->aux-surfaces->load aux main surface (or something like
 that). Or use freeview.
 
 cheers
 Bruce
 On Mon, 13 May 2013, Jonathan Holt wrote:
 
> Bruce,
> 
> how is it that I might load multiple surfaces, loading lh after having 
> loaded rh makes the other disappear. this is loading manually, not from 
> the command line
> On May 13, 2013, at 11:14 AM, Jonathan Holt wrote:
> 
>> Hi all,
>> 
>> last question promise. Successfully completed mris_make_surfaces for 
>> both hemispheres. in my day-to-day editing I open tkmedit thusly:
>> 
>> tkmedit  brainmask.mgz -aux $SUBJECTS_DIR/subjid/mri/wm.mgz 
>> -surface $SUBJECTS_DIR/subjid/surf/lh.white -aux-surface 
>> $SUBJECTS_DIR/subjid/surf/rh.white -aparc+aseg
>> 
>> this works for mprage subjects. In evaluating and possibly editing 
>> MEMPRAGE subjects, which surfaces should I have opened in tkmedit, as 
>> there seem to be many more this time around.
>> 
>> best,
>> jon
>> On May 11, 2013, at 6:49 PM, Bruce Fischl wrote:
>> 
>>> Hi Kayle
>>> 
>>> it's been a long time since I wrote that code and we've only run it a 
>>> few
>>> times. If you upload your subject directory I'll take a look
>>> 
>>> cheers
>>> Bruce
>>> On Sat, 11 May
>>> 2013, Kayle Sawyer wrote:
>>> 
 Hi all,
 
 I tried to use the 4-echo MEMPRAGE dura detection for 
 mris_make_surfaces, but I'm not sure if it worked. The terminal 
 output, including commands, is attached. It was run with version 
 freesurfer-Linux-centos6_x86_64-stable-v5.3.0-BETA-20130509.
 
 On the original recon, in the rh, there is a segment of dura marked as 
 grey inside the pial line, at 94 111 169. The surfaces did not appear 
 to change substantially after I reran mris_make_surfaces with the 
 -dura flag specifying the 4-echo MEMPRAGE, which I placed in the mri 
 directory. You can see the before and after for yourself on the 
 attached screenshots, or if you have NMR access, here:
 /space/ficus/6/users/SNEF_edits/OB01_orig/
 /space/ficus/6/users/SNEF_edits/OB01_orig_dura/
 
 I saw this output from mris_make_surfaces for the rh, so maybe -dura 
 did correct a different defect?
 7 non-cortical segments detected
 only using segment with 1900 vertices
 
 Any help would be appreciated, because we have over 130 brains and the 
 fewer manual corrections, the better!
 
 Thanks,
 -Kayle
 
 
 
 
 From: Douglas Greve 
 Date: Thu, May 9, 2013 at 8:44 PM
 Subject: Re: [Freesurfer] Working with MEMPRAGE
 To: freesurfer@nmr.mgh.harvard.edu
 
 
 
 the dcmunpack command is right. You should make sure to analyze only 
 the
 RMS in recon-all (ie , that is the only volume that goes into mri/orig
 doug
 
 
 On 5/9/13 6:48 PM, Bruce Fischl wrote:
> Hi Kayle
> 
> you would run recon-all on the RMS, then run the dura stuff posthoc.
> 
> cheers
> Bruce
> On Thu,
> 9 May 2013, Kayle Sawyer wrote:
> 
>> Hi all,
>> 
>> Can the MEMPRAGE be specified in recon-all with the -i flag? We have 
>> been using the MEMPRAGE RMS scans and discarding the multiecho 
>> scans. If we instead specify the multiecho scans for recon-all, do 
>> we need to give any additional parameters (e.g. the number of 
>> echoes) for it to utilize the 4 echoes to detect dura and refine 
>> pial surfaces in mris_make_surfaces, as described below? Or would we 
>> have to run recon-all with the RMS, then after it finishes re-run 
>> mris_make_surfaces manually with the -dura flag to refine the pial 
>> surface?
>> 
>> Also, I'd like to make sure we are using dcmunpack properly. We take 
>> the
> scan.info file and parse it like this: "-run [MEMPRAGE_4e_p2_1mm_iso 
> run
> numb

Re: [Freesurfer] Very simple question about Paired Analysis

[Douglas N Greve]

Hi Jamie, did you look at the help for mri_glmfit? Run it with --help.
doug
ps. Please post questions to the list so that others can benefit. thanks!


On 05/13/2013 04:12 PM, Jaime Ide wrote:
> Dear Douglas,
>
> Thanks for your helpful page at
> https://surfer.nmr.mgh.harvard.edu/fswiki/PairedAnalysis
>
> I am having problems in the last step running mri_glmfit.
> It should be a very simple bug to fix...
> *"ERROR: you must use '--surface subject hemi' with surface data"*
> (the complete message is at the bottom of this email..)
>
> I wonder to know if you could help me on this.
> Thanks very much in advance,
> Jaime
>
>
> *
> cmdline mri_glmfit --glmdir lh.paired-diff --y 
> lh.paired-diff.thickness.sm05.mgh --fsgd paired-diff.fsgd --C mean.mtx
> sysname  Linux
> hostname unifesp-monkey3
> machine  x86_64
> user jaime
> FixVertexAreaFlag = 1
> UseMaskWithSmoothing 1
> OneSampleGroupMean 0
> y  /home/jaime/ji_freesurfer/ji_scripts/lh.paired-diff.thickness.sm05.mgh
> logyflag 0
> usedti  0
> FSGD paired-diff.fsgd
> glmdir lh.paired-diff
> IllCondOK 0
> ReScaleX 1
> DoFFx 0
> Creating output directory lh.paired-diff
> Loading y from 
> /home/jaime/ji_freesurfer/ji_scripts/lh.paired-diff.thickness.sm05.mgh
> *ERROR: you must use '--surface subject hemi' with surface data*
>

-- 
Douglas N. Greve, Ph.D.
MGH-NMR Center
gr...@nmr.mgh.harvard.edu
Phone Number: 617-724-2358
Fax: 617-726-7422

Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

___
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] using T2* weighted scans to assist with dura stripping in a GE scanner?

[Matt Glasser]

Gordon Xu who helped us set up the protocol reminded me of the following:

"The main benefit of the readout PF is to reduce echo spacing, hence less
blurring in the slice direction. The side benefit is that it also reduces
the minimum TE, hence less dropout. However, you do give up some SNR at
the high spatial frequency as Souheil mentioned. There are two senarios of
this, a) the SNR is adequate, you only lose some SNR due to less sampling,
b) if the SNR is borderline or worse, in addition to losing SNR you also
lose some spatial resolution in the readout direction as the other side of
the high spatial frequency k-space is less reliable.

I remember we did pilot acquisition with and without "asymmetric echo" in
two subjects. You looked at the images and you either liked the one with
asymmetric echo because of less blurring or at least indifferent between
the two. So I assume with the Siemens 32ch coil we are in senario a)
above."


If I had to guess, we probably went with the readout partial fourier to
reduce the dropout regions in the gradient echo MPRAGE and didn't see an
obvious loss in resolution.

Peace,

Matt.

On 5/13/13 1:03 PM, "Inati, Souheil (NIH/NIMH) [E]"
 wrote:

>Hi Matt,
>
>Thanks for the link.
>
>Reading on pages 29-31, I am struck by the complexity of the procedure.
>Not to say that it doesn't work, or that the single T1w image free-surfer
>stuff is simple :-), on the contrary, it's just that I was expecting to
>see something about an optimization that used both images, rather than
>something based on the T1w image followed by an exclusion criterion based
>on the T2w image.  Anyway, works better than without.
>
>Minor question on the acquisition of the anatomicals:
>- Why are you using partial fourier in the read direction?  You're
>throwing away a lot of SNR at the high spatial frequencies, seems a shame
>to go to 0.7mm and then do that.
>
>Cheers,
>Souheil
>
>On May 12, 2013, at 10:54 PM, Matt Glasser  wrote:
>
>> This is available online now:
>> 
>> http://authors.elsevier.com/sd/article/S1053811913005053
>> 
>> 
>> On 5/7/13 3:10 PM, "Bruce Fischl"  wrote:
>> 
>>> actually Matt Glasser points out that a brief description is in his
>>>paper
>>> that is coming out soon, and there is also some description in Andre's
>>> multi-echo mprage paper
>>> Bruce
>>> On Tue, 7 May 2013, Inati, Souheil (NIH/NIMH) [E]
>>> wrote:
>>> 
 thanks :-)
 
 On May 7, 2013, at 3:28 PM, Bruce Fischl 
 wrote:
 
> no, of course not :)
> 
> On Tue, 7 May 2013, Inati, Souheil (NIH/NIMH) [E]
> wrote:
> 
>> Hi Bruce,
>> 
>> Out of curiosity and for reference for my users, do you have a paper
>> on the T2 or FLAIR assisted segmentation?
>> 
>> Cheers,
>> Souheil
>> 
>> -
>> 
>> Souheil Inati, PhD
>> Staff Scientist
>> FMRI Facility
>> NIMH/NIH/DHHS
>> souheil.in...@nih.gov
>> 
>> 
>> 
>> 
>> On May 7, 2013, at 2:24 PM, Bruce Fischl
>> mailto:fis...@nmr.mgh.harvard.edu>>
>>wrote:
>> 
>> Hi Katie
>> 
>> I'm really not sure. These days I would recommend a highres (e.g.
>>1mm
>> isotropic) FLAIR if you can get one, or T2 if not. The T2* can help,
>> but
>> it's pretty noisy in brain.
>> 
>> cheers
>> Bruce
>> 
>> On Tue, 7 May 2013, Katie Surrence wrote:
>> 
>> Dear Freesurfer gurus,
>> 
>> At the course, André van der Kouwe mentioned in his morphometry
>> methods talk that T2* weighted contrast from
>> MEMPRAGE could be used to further seperate dura from cortex, as also
>> discussed in this paper:
>> http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2408694/.  We have a GE
>> scanner in our lab.  The internet suggests
>> that a Multi-echo FSPGR/FGRE exists.  Would this be the analog?
>> Would it work the same way?  Could you also
>> use these images with the mris_make_surfaces command?
>> 
>> Thanks very much for your insight -- and I enjoyed the course!
>> 
>> /Katie Surrence
>> 
>> --
>> Research Coordinator
>> Social Cognition Laboratory
>> New York State Psychiatric Institute
>> 
>> ___
>> 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 t

Re: [Freesurfer] beta v5.3 for fedora 18 and ubuntu 13

[Joerg Pfannmoeller]

Tested recon-all tonight on lubuntu 13.04. I did not encounter any problems. 
Also freeview runs without an error for the subject bert.



On Mon, 13 May 2013 14:40:10 +0200
Jörg Pfannmöller  wrote:

> Just for completeness, I refer to my first contribution:
> 
> http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg28267.html
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, 13 May 2013 13:58:30 +0200
> Joerg Pfannmoeller  wrote:
> 
> > Hello Nick,
> > 
> > just installed and tested the BETA version. Up to now no problem 
> > encountered. Recon-all is just running as a test (using -use-gpu). OS is 
> > Lubuntu 13.04. I report on the segmentation as soon as it is finished.
> > 
> > So long Joerg
> > 
> > On Sun, 12 May 2013 22:41:25 -0400 (EDT)
> > "Nick Schmansky"  wrote:
> > 
> > > Fedora 18, Ubuntu 13 and Gentoo 64 users,
> > > 
> > > another beta of the upcoming v5.3 is available here:
> > > 
> > > ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/5.3.0-BETA/freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0-BETA.tar.gz
> > > 
> > > this one is just intended for the Fedora 18, Ubuntu 13, Gentoo 64 users
> > > who wished to test that the segfault problem in v5.2 and the prior beta
> > > v5.3 is fixed.  Your help in testing this release is appreciated.
> > > 
> > > Thanks,
> > > 
> > > Nick
> > > 
> > > 
> > > 
> > > 
> > > 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.
> > > 
> > 
> > 
> > -- 
> > Joerg Pfannmoeller 
> > ___
> > 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


-- 
Joerg Pfannmoeller 

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