Re: [Freesurfer] mri_nu_correct.mni and mri_convert with odd matrix dimensions and "-cm" flag

[Falk Lüsebrink]

Hi Natalia,

I had the same issue in some cases. This is happens if you native data is not 
perfectly isotropic and seems to be related to a rounding error. The only the 
solution I found is to fix the resolution of your data prior to mri_nu_correct 
manually.

Check your voxel size with mri_info. Then use mri_convert -cs  to 
adjust the voxel size to get the number of voxels of mri_nu_convert. In this 
case something like mri_convert -cs 0.4429.

Hope this helps.
Best,
Falk

-Ursprüngliche Nachricht-
Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Natalia 
Zaretskaya
Gesendet: Montag, 9. Februar 2015 18:44
An: freesurfer@nmr.mgh.harvard.edu
Betreff: [Freesurfer] mri_nu_correct.mni and mri_convert with odd matrix 
dimensions and "-cm" flag


Dear FreeSurfer experts,

when I run e.g.:

mri_nu_correct.mni --i orig.mgz --mask brainmask.mgz --o nu.mgz --n 1 
--proto-iters 1000 --uchar transforms/talairach.xfm -cm

where orig.mgz and brainmask.mgz have 577 x 577 x 577 voxels, there is an error:

$Id: mri_segstats.c,v 1.109 2014/10/17 19:31:46 greve Exp $ cwd cmdline 
mri_segstats --id 1 --seg ./tmp.mri_nu_correct.mni.15003/ones.mgz --i orig.mgz 
--sum ./tmp.mri_nu_correct.mni.15003/sum.junk --avgwf 
./tmp.mri_nu_correct.mni.15003/input.mean.dat
sysname  Linux
hostname shuki
machine  x86_64
user nzaretsk
UseRobust  0
Loading ./tmp.mri_nu_correct.mni.15003/ones.mgz
Loading orig.mgz
ERROR: dimension mismatch between input volume and seg input 577 577 577
seg   578 578 578


I have checkt and it appears that
mri_convert orig.mgz orig_out.mgz -cm
results in orig_out.mgz having one voxel more, e.g. 578 x 578 x 578, instead of 
 577 x 577 x 577

This does not happen when one omits the "-cm" flag, or when the input volume is 
578 x 578 x 578.

Is this a bug, or do the image dimensions have to be even for some reason?

Thanks!
Natalia






___
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] freesurfer pipeline for sub mm voxel resolution

[Falk Lüsebrink]

Hi Ri,

you can process data with higher resolution than 1mm^3 if you follow the 
HiResRecon (https://surfer.nmr.mgh.harvard.edu/fswiki/HiResRecon). The changes 
to the pipeline were done using v5.1, however, this should still work fine.

Best,
Falk

-Ursprüngliche Nachricht-
Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Ritobrato Datta
Gesendet: Mittwoch, 1. April 2015 16:23
An: Freesurfer support list
Betreff: [Freesurfer] freesurfer pipeline for sub mm voxel resolution

Hi All,

I am working with some 7T data with 0.7 mm isotropic voxels and wanted to know 
if free surfer pipeline (version 5.3) can work these images ? 

I also have FLAIR images and wanted to know if I can use the two to create 
myelin maps ?

Please suggest.

Thanks

Ri
___
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] recon-all pipeline for (sub-millimeter) 7T data

[Falk Lüsebrink]

Hi Thomas,

this looks like a really nice script and a lot better than my own. In the 
upcoming release of FreeSurfer v.6 my work-around probably is not needed 
anymore. However, I haven’t been able to have a look at the dev release yet and 
whether the standard recon-all features a flag to process high resolution data.

Best,
Falk

P.S. Following your instructions one will definitely become a coffee junkie. :D

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Emmerling Thomas 
(PSYCHOLOGY)
Gesendet: Mittwoch, 24. Juni 2015 14:35
An: freesurfer@nmr.mgh.harvard.edu
Betreff: [Freesurfer] recon-all pipeline for (sub-millimeter) 7T data

Hello!

I wrote a bash script some time ago to process data acquired at a 
sub-millimeter resolution following the nice wiki entry of Falk Lüsebrink 
(https://surfer.nmr.mgh.harvard.edu/fswiki/HiResRecon). I thought it might be 
helpful for others, too, as there are some questions about it in the mailing 
list archives, so here it is: 
https://github.com/thomastweets/freesurfer-7t-pipeline. I am happy about any 
comments!

Best,
Thomas
___
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 field dishomogeneity

[Falk Lüsebrink]

Hi Clelia,

I think the reviewer might refer to the -3T flag of recon-all which enables 
3T-specific NU intensity correction parameters and usage of a special atlas for 
Talairach alignment.

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von clelia pellicano
Gesendet: Freitag, 3. Juli 2015 18:55
An: Freesurfer support list
Betreff: Re: [Freesurfer] correction for field dishomogeneity


I did it. Thank you very much.

C
Il giorno 03/lug/2015 18:51, "Bruce Fischl" 
mailto:fis...@nmr.mgh.harvard.edu>> ha scritto:
not sure. Did you use recon-all? If so, then you did use
"the appropriate pipeline provided by freesurfer"
On Fri, 3 Jul
2015, clelia pellicano wrote:

>
> Hi Bruce,
>
> thank you for your reply. Do you have any idea about what they could mean
> saying "without using the appropriate pipeline provided by freesurfer"?
> Thanks
>
> BW
>
> C
>
> Il giorno 03/lug/2015 15:32, "Bruce Fischl" 
> mailto:fis...@nmr.mgh.harvard.edu>> ha
> scritto:
>   Hi Clelia
>
>   yes, we correct for field inhomogeneity. Presumably they mean
>   the B1
>   receive field, which is what is typically meant in structurals.
>   If they
>   mean B0, we don't typically correct (nor do most people for
>   structural
>   imaging - this is more of an issue for diffusion and functional
>   MRI).
>
>   cheers
>   Bruce
>
>   On Fri, 3 Jul 2015, clelia
>   pellicano wrote:
>
>   > Dear experts,
>   >
>   > I was wondering how freesurfer corrects for field
>   dishomogeneity.
>   > As long as I know, it's automatically done by the software .
>   > My concern is because a reviewer has made this comment (please
>   find it
>   > below):
>   >
>   > "Authors used an old 3 T MRI without using the appropriate
>   pipeline provided
>   > by freesurfer to correct for field dysomogeneity"
>   >
>   > We have run the standard pipeline provided to derive measures
>   of cortical
>   > thickness and deep grey matter nuclei volume (FreeSurfer
>   version 5.3.0 ).
>   >
>   > Here the MRI protocol used:
>   > All participants were scanned on a 3-Tesla Philips Intera
>   whole-body MRI
>   > scanner. A T1-weighted three-dimensional
>   magnetization-prepared rapid
>   > acquisition gradient-echo (MPRAGE; time echo: 4.6 ms; time
>   repetition:
>   > 9.7ms; field of view: 240 ms; voxel size= 1 x1 x 1 mm) was
>   acquired.
>   >
>   > Any clue about?
>   >
>   > Thank you in advance.
>   >
>   > BW
>   >
>   > Clelia
>   >
>   >
>   > . Clelia Pellicano, MDPhD Student in Clinical and Experimental
>   Neurosciences
>   > and Psychiatry,
>   > Department of Neuroscience, Mental Health and Sensory Organs,
>   NESMOS,
>   > Sapienza University
>   > Via di Grottarossa 1035, 00189 Rome, Italy
>   > phone +390633775579
>   > fax +390633775900
>   >
>   > Research Neurologist
>   > Department of Clinical and Experimental Neurology
>   > Santa Lucia Foundation IRCSS
>   > Via Ardeatina 306, 00179, Rome, Italy
>   >
>   >
>   ___
>   Freesurfer mailing list
>   Freesurfer@nmr.mgh.harvard.edu
>   https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
>   The information in this e-mail is intended only for the person
>   to whom it is
>   addressed. If you believe this e-mail was sent to you in error
>   and the e-mail
>   contains patient information, please contact the Partners
>   Compliance HelpLine at
>   http://www.partners.org/complianceline . If the e-mail was sent
>   to you in error
>   but does not contain patient information, please contact the
>   sender and properly
>   dispose of the e-mail.
>
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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] options for 7T images...

[Falk Lüsebrink]

Me too.

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Andrea Grant
Gesendet: Montag, 10. August 2015 16:23
An: Freesurfer support list
Cc: Kyoko Fujimoto; Jonathan Polimeni
Betreff: Re: [Freesurfer] options for 7T images...

I would be interested in details on a 7T stream also!
Thank you,
Andrea

-
Andrea Grant
Visual Neuroimaging Technologist
Center for Magnetic Resonance Research, University of Minnesota
2021 6th St. SE, Minneapolis, MN 55455, 612-626-4948
gran0...@umn.edu
umn.edu/~gran0260

On Sun, Aug 9, 2015 at 9:33 AM, Bruce Fischl 
mailto:fis...@nmr.mgh.harvard.edu>> wrote:
sorry, had an old address for Kyoko


On Sun, 9 Aug 2015, Bruce Fischl wrote:
Hi Gonzalo

Jon and Kyoko (both ccd) have put together a 7T stream, and should be able to 
help you out

cheers
Bruce
On Sat, 8 Aug 2015, Gonzalo Rojas Costa wrote:
 Hi:

   Must I use any recon-all option for 7T images ?...

   Sincerely,


 Gonzalo Rojas Costa

 --
 Gonzalo Rojas Costa
 Laboratory for Advanced Medical Image Processing
 Department of Radiology
 Clínica las Condes
 Lo Fontecilla 441, Las Condes, Santiago, Chile.
 Tel: 56-2-2105170
 Cel: 56-9-97771785
 www.clc.cl


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


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

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


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

Re: [Freesurfer] Freesurfer program for 7 Tesla

[Falk Lüsebrink]

Hi Prasad,

for me FreeSurfer worked pretty nicely with 7T data. Most critical parts are 
skull-stripping and surface alignment if intensities of the cortex vary a lot 
(e.g. darker cortex in temporal lobes). However, I haven’t tried the 
hippocampal subfields yet and have usually processed small cohorts of young 
healthy subjects only.

You have to deal with B1 inhomogeneities for obvious reasons, though. In that 
regard I got good results either using MP2RAGE (or MPRAGE with acquisition of a 
reference GRE), post processing correction by SPM and/or adjustments of the 
parameters of the N3 within FreeSurfer.

Best,
Falk


Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von konasale prasad
Gesendet: Dienstag, 7. Juni 2016 17:32
An: 'Alan Francis'; 'Freesurfer'
Betreff: Re: [Freesurfer] Freesurfer program for 7 Tesla

No. not really. This paper should be useful. Thanks for sending this along.

From: Alan Francis [mailto:alandarkene...@gmail.com]
Sent: Tuesday, May 24, 2016 9:47 AM
To: Freesurfer 
mailto:freesurfer@nmr.mgh.harvard.edu>>; 
pnucl...@gmail.com
Subject: Re: [Freesurfer] Freesurfer program for 7 Tesla

Hi Prasad:
Hope all is well. Has someone replied to you on this question? I have enclosed 
an interesting article that compares 3T vs 7T that might be useful in guiding 
your analysis.
best,
Alan

On Mon, May 16, 2016 at 12:01 PM, konasale prasad 
mailto:pnucl...@gmail.com>> wrote:

Dear FSL experts,

We are trying to run freesurfer volume measurements, primarily subcortical 
regions along with cortical surface area and thickness. We are also interested 
in hippocampal subfields and shape analysis. I was wondering whether the 
program would be reliable compared to 3T (that we have done quite a few). Are 
there any known problems? If there are, please let me know the work arounds.

Thanks,

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



--
|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|

Alan N. Francis PhD
Instructor - Imaging Neuroscience
Brain Imaging Center
McLean Hospital
Harvard Medical School
115 Mill Street, Belmont, MA 02478
al...@bwh.harvard.edu
afran...@mclean.harvard.edu

|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|
___
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_ca_label with high resolution data

[Falk Lüsebrink]

Hi all,

I'm currently processing a 250 µm MPRAGE with a dev build from mid of May. 
Running recon-all with default parameters ran flawlessly. Afterwards I added 
the -hires flag to process the data without conformation. However, since 
Saturday morning it is kind of stuck at mri_ca_label stating:

saving sequentially combined intensity scales to 
aseg.auto_noCCseg.label_intensities.txt

while  consuming around 30 GB of memory. I ran something similar before and 
processing works, it's just terribly slow. Maybe this particular stage is just 
not very efficient as it does take a few minutes on 1 mm data only? Would it 
help to add the openmp flag in that case?

Best,
Falk

----
Falk Lüsebrink, M. Sc.

Otto-von-Guericke-Universität Magdeburg
Forschungscampus STIMULATE
http://www.forschungscampus-stimulate.de/

Universitätsplatz 2
39106 Magdeburg

Raum:ExFa - 4.06
Telefon: 0391-67-19366
Fax:   0391-67-19347

___
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_ca_label with high resolution data

[Falk Lüsebrink]

Hi Bruce,

thanks for the quick reply. I'll try it out once I have a bit of memory 
available and let you know if it helped.

Best,
Falk

-Ursprüngliche Nachricht-
Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Bruce Fischl
Gesendet: Dienstag, 19. Juli 2016 15:37
An: Freesurfer support list
Betreff: Re: [Freesurfer] mri_ca_label with high resolution data

Hi Falk

I think openmp will help with this in V6, but probably not before Bruce

On Tue, 19
Jul 2016, Falk Lüsebrink wrote:

> 
> Hi all,
> 
>  
> 
> I’m currently processing a 250 µm MPRAGE with a dev build from mid of May.
> Running recon-all with default parameters ran flawlessly. Afterwards I 
> added the -hires flag to process the data without conformation. 
> However, since Saturday morning it is kind of stuck at mri_ca_label stating:
> 
>  
> 
> saving sequentially combined intensity scales to 
> aseg.auto_noCCseg.label_intensities.txt
> 
>  
> 
> while  consuming around 30 GB of memory. I ran something similar 
> before and processing works, it’s just terribly slow. Maybe this 
> particular stage is just not very efficient as it does take a few minutes on 
> 1 mm data only?
> Would it help to add the openmp flag in that case?
> 
>  
> 
> Best,
> 
> Falk
> 
>  
> 
> 
> 
> Falk Lüsebrink, M. Sc.
> 
>  
> 
> Otto-von-Guericke-Universität Magdeburg
> 
> Forschungscampus STIMULATE
> 
> http://www.forschungscampus-stimulate.de/
> 
>  
> 
> Universitätsplatz 2
> 
> 39106 Magdeburg
> 
>  
> 
> Raum:    ExFa - 4.06
> 
> Telefon: 0391-67-19366
> 
> Fax:   0391-67-19347
> 
>  
> 
> 
>

___
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] question about voxel size

[Falk Lüsebrink]

Hi Dorsa,

until version 6 of FreeSurfer is released you could try to follow the 
HiResRecon (https://surfer.nmr.mgh.harvard.edu/fswiki/HiResRecon) which should 
enable you to process the data in its native resolution. With FreeSurfer v6 
this workaround will not be necessary anymore, as the processing pipeline has 
been updated. If you want to, you could also try out a recent developer build. 
However, it is still under development.

Best,
Falk


Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Dorsa Haji 
Ghaffari
Gesendet: Dienstag, 19. Juli 2016 18:06
An: Freesurfer support list
Betreff: [Freesurfer] question about voxel size

Hi,

I have a T1 weighted MRI which I want to segment using Freesurfer. The voxel 
sizes are 0.48*0.48*0.48. I read that the ideal voxel size for freesurfer is 
1mm^3. Is there any manual adjustments that I can make to get good results with 
my 0.48 voxel size images?

Thank you

Dorsa Ghaffari
___
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] question about voxel size

[Falk Lüsebrink]

Hi Dorsa,

well visual inspection is always a good indicator. Also you could have a look 
at the QA Tools (https://surfer.nmr.mgh.harvard.edu/fswiki/QATools). I haven’t 
tested them though.

Other than that, I wouldn’t know of any objective method to validate your 
results. Probably someone else can jump in on that.

Best,
Falk

P.S. Be sure to also reply to the list also.

Von: Dorsa Haji Ghaffari [mailto:gh...@umich.edu]
Gesendet: Dienstag, 19. Juli 2016 18:21
An: Falk Lüsebrink
Betreff: Re: [Freesurfer] question about voxel size

Thank you. I was actually able to get results using my high resolution images 
without changing their resolution. Is there any way to validate my results to 
see if I have good results?

On Tue, Jul 19, 2016 at 12:10 PM, Falk Lüsebrink 
mailto:falk.luesebr...@ovgu.de>> wrote:
Hi Dorsa,

until version 6 of FreeSurfer is released you could try to follow the 
HiResRecon (https://surfer.nmr.mgh.harvard.edu/fswiki/HiResRecon) which should 
enable you to process the data in its native resolution. With FreeSurfer v6 
this workaround will not be necessary anymore, as the processing pipeline has 
been updated. If you want to, you could also try out a recent developer build. 
However, it is still under development.

Best,
Falk


Von: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>]
 Im Auftrag von Dorsa Haji Ghaffari
Gesendet: Dienstag, 19. Juli 2016 18:06
An: Freesurfer support list
Betreff: [Freesurfer] question about voxel size

Hi,

I have a T1 weighted MRI which I want to segment using Freesurfer. The voxel 
sizes are 0.48*0.48*0.48. I read that the ideal voxel size for freesurfer is 
1mm^3. Is there any manual adjustments that I can make to get good results with 
my 0.48 voxel size images?

Thank you

Dorsa Ghaffari

___
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_ca_label with high resolution data

[Falk Lüsebrink]

Hi Bruce,

I started the process again with openmp set to 12 using the dev build from 12th 
July. However, mri_ca_label uses only 1 thread at that point. So I don't assume 
any faster processing.

Best,
Falk


-Ursprüngliche Nachricht-
Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Bruce Fischl
Gesendet: Dienstag, 19. Juli 2016 15:37
An: Freesurfer support list
Betreff: Re: [Freesurfer] mri_ca_label with high resolution data

Hi Falk

I think openmp will help with this in V6, but probably not before Bruce

On Tue, 19
Jul 2016, Falk Lüsebrink wrote:

> 
> Hi all,
> 
>  
> 
> I’m currently processing a 250 µm MPRAGE with a dev build from mid of May.
> Running recon-all with default parameters ran flawlessly. Afterwards I 
> added the -hires flag to process the data without conformation. 
> However, since Saturday morning it is kind of stuck at mri_ca_label stating:
> 
>  
> 
> saving sequentially combined intensity scales to 
> aseg.auto_noCCseg.label_intensities.txt
> 
>  
> 
> while  consuming around 30 GB of memory. I ran something similar 
> before and processing works, it’s just terribly slow. Maybe this 
> particular stage is just not very efficient as it does take a few minutes on 
> 1 mm data only?
> Would it help to add the openmp flag in that case?
> 
>  
> 
> Best,
> 
> Falk
> 
>  
> 
> 
> 
> Falk Lüsebrink, M. Sc.
> 
>  
> 
> Otto-von-Guericke-Universität Magdeburg
> 
> Forschungscampus STIMULATE
> 
> http://www.forschungscampus-stimulate.de/
> 
>  
> 
> Universitätsplatz 2
> 
> 39106 Magdeburg
> 
>  
> 
> Raum:    ExFa - 4.06
> 
> Telefon: 0391-67-19366
> 
> Fax:   0391-67-19347
> 
>  
> 
> 
>

___
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_ca_label with high resolution data

[Falk Lüsebrink]

Hi Bruce,

I'm using the current dev build:

ProgramName: mri_ca_label  ProgramArguments: --all-info  ProgramVersion: $Name: 
 $  TimeStamp: 2016/07/21-13:42:39-GMT  BuildTimeStamp: Jul 12 2016 13:31:56  
CVS: $Id: mri_ca_label.c,v 1.113 2016/05/13 18:02:49 fischl Exp $  User: 
luesebrink  Machine: reco  Platform: Linux  PlatformVersion: 3.16.0-4-amd64  
CompilerName: GCC  CompilerVersion: 40400

and in the log it says to use 12 threads

== Number of threads available to mri_ca_label for OpenMP = 12 == 

however, at least while saving the intensity scale

saving intensity scales to aseg.auto_noCCseg.label_intensities.txt
saving sequentially combined intensity scales to 
aseg.auto_noCCseg.label_intensities.txt

it doesn't seem to help.

Best,
Falk


Von: Bruce Fischl [fis...@nmr.mgh.harvard.edu]
Gesendet: Donnerstag, 21. Juli 2016 15:30
An: Falk Lüsebrink
Cc: Freesurfer support list
Betreff: Re: AW: [Freesurfer] mri_ca_label with high resolution data

Hi Falk

the dev version of mri_ca_label does use openmp, so should be faster.

cheers
Bruce
On
Thu, 21 Jul 2016, Falk Lüsebrink wrote:

> Hi Bruce,
>
> I started the process again with openmp set to 12 using the dev build from 
> 12th July. However, mri_ca_label uses only 1 thread at that point. So I don't 
> assume any faster processing.
>
> Best,
> Falk
>
>
> -Ursprüngliche Nachricht-
> Von: freesurfer-boun...@nmr.mgh.harvard.edu 
> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Bruce Fischl
> Gesendet: Dienstag, 19. Juli 2016 15:37
> An: Freesurfer support list
> Betreff: Re: [Freesurfer] mri_ca_label with high resolution data
>
> Hi Falk
>
> I think openmp will help with this in V6, but probably not before Bruce
>
> On Tue, 19
> Jul 2016, Falk Lüsebrink wrote:
>
>>
>> Hi all,
>>
>>
>>
>> I’m currently processing a 250 µm MPRAGE with a dev build from mid of May.
>> Running recon-all with default parameters ran flawlessly. Afterwards I
>> added the -hires flag to process the data without conformation.
>> However, since Saturday morning it is kind of stuck at mri_ca_label stating:
>>
>>
>>
>> saving sequentially combined intensity scales to
>> aseg.auto_noCCseg.label_intensities.txt
>>
>>
>>
>> while  consuming around 30 GB of memory. I ran something similar
>> before and processing works, it’s just terribly slow. Maybe this
>> particular stage is just not very efficient as it does take a few minutes on 
>> 1 mm data only?
>> Would it help to add the openmp flag in that case?
>>
>>
>>
>> Best,
>>
>> Falk
>>
>>
>>
>> 
>>
>> Falk Lüsebrink, M. Sc.
>>
>>
>>
>> Otto-von-Guericke-Universität Magdeburg
>>
>> Forschungscampus STIMULATE
>>
>> http://www.forschungscampus-stimulate.de/
>>
>>
>>
>> Universitätsplatz 2
>>
>> 39106 Magdeburg
>>
>>
>>
>> Raum:ExFa - 4.06
>>
>> Telefon: 0391-67-19366
>>
>> Fax:   0391-67-19347
>>
>>
>>
>>
>>
>
>
>


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] mri_ca_label with high resolution data

[Falk Lüsebrink]

Hi Bruce,

I thought so. Are there any other means to accelerate this procedure (in the 
future)? 

Best,
Falk

-Ursprüngliche Nachricht-
Von: Bruce Fischl [mailto:fis...@nmr.mgh.harvard.edu] 
Gesendet: Donnerstag, 21. Juli 2016 15:52
An: Falk Lüsebrink
Cc: Freesurfer support list
Betreff: Re: AW: AW: [Freesurfer] mri_ca_label with high resolution data

Hi Falk

not every part of it is accelerated, but some are

cheers
Bruce


On Thu, 21 Jul 2016, Falk Lüsebrink wrote:

> Hi Bruce,
>
> I'm using the current dev build:
>
> ProgramName: mri_ca_label  ProgramArguments: --all-info  
> ProgramVersion: $Name:  $  TimeStamp: 2016/07/21-13:42:39-GMT  
> BuildTimeStamp: Jul 12 2016 13:31:56  CVS: $Id: mri_ca_label.c,v 1.113 
> 2016/05/13 18:02:49 fischl Exp $  User: luesebrink  Machine: reco  
> Platform: Linux  PlatformVersion: 3.16.0-4-amd64  CompilerName: GCC  
> CompilerVersion: 40400
>
> and in the log it says to use 12 threads
>
> == Number of threads available to mri_ca_label for OpenMP = 12 ==
>
> however, at least while saving the intensity scale
>
> saving intensity scales to aseg.auto_noCCseg.label_intensities.txt
> saving sequentially combined intensity scales to 
> aseg.auto_noCCseg.label_intensities.txt
>
> it doesn't seem to help.
>
> Best,
> Falk
>
> 
> Von: Bruce Fischl [fis...@nmr.mgh.harvard.edu]
> Gesendet: Donnerstag, 21. Juli 2016 15:30
> An: Falk Lüsebrink
> Cc: Freesurfer support list
> Betreff: Re: AW: [Freesurfer] mri_ca_label with high resolution data
>
> Hi Falk
>
> the dev version of mri_ca_label does use openmp, so should be faster.
>
> cheers
> Bruce
> On
> Thu, 21 Jul 2016, Falk Lüsebrink wrote:
>
>> Hi Bruce,
>>
>> I started the process again with openmp set to 12 using the dev build from 
>> 12th July. However, mri_ca_label uses only 1 thread at that point. So I 
>> don't assume any faster processing.
>>
>> Best,
>> Falk
>>
>>
>> -Ursprüngliche Nachricht-
>> Von: freesurfer-boun...@nmr.mgh.harvard.edu 
>> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Bruce 
>> Fischl
>> Gesendet: Dienstag, 19. Juli 2016 15:37
>> An: Freesurfer support list
>> Betreff: Re: [Freesurfer] mri_ca_label with high resolution data
>>
>> Hi Falk
>>
>> I think openmp will help with this in V6, but probably not before 
>> Bruce
>>
>> On Tue, 19
>> Jul 2016, Falk Lüsebrink wrote:
>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> I'm currently processing a 250 µm MPRAGE with a dev build from mid of May.
>>> Running recon-all with default parameters ran flawlessly. Afterwards 
>>> I added the -hires flag to process the data without conformation.
>>> However, since Saturday morning it is kind of stuck at mri_ca_label stating:
>>>
>>>
>>>
>>> saving sequentially combined intensity scales to 
>>> aseg.auto_noCCseg.label_intensities.txt
>>>
>>>
>>>
>>> while  consuming around 30 GB of memory. I ran something similar 
>>> before and processing works, it's just terribly slow. Maybe this 
>>> particular stage is just not very efficient as it does take a few minutes 
>>> on 1 mm data only?
>>> Would it help to add the openmp flag in that case?
>>>
>>>
>>>
>>> Best,
>>>
>>> Falk
>>>
>>>
>>>
>>> 
>>>
>>> Falk Lüsebrink, M. Sc.
>>>
>>>
>>>
>>> Otto-von-Guericke-Universität Magdeburg
>>>
>>> Forschungscampus STIMULATE
>>>
>>> http://www.forschungscampus-stimulate.de/
>>>
>>>
>>>
>>> Universitätsplatz 2
>>>
>>> 39106 Magdeburg
>>>
>>>
>>>
>>> Raum:ExFa - 4.06
>>>
>>> Telefon: 0391-67-19366
>>>
>>> Fax:   0391-67-19347
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> 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] mri_ca_label with high resolution data

[Falk Lüsebrink]

Hi Bruce,

thanks. Keep up the fantastic work!

Best,
Falk

-Ursprüngliche Nachricht-
Von: Bruce Fischl [mailto:fis...@nmr.mgh.harvard.edu] 
Gesendet: Donnerstag, 21. Juli 2016 16:44
An: Falk Lüsebrink
Cc: Freesurfer support list
Betreff: Re: AW: AW: AW: [Freesurfer] mri_ca_label with high resolution data

Hi Falk

yes, it's an active area of devlopment for us cheers Bruce

On Thu, 21 Jul 2016, Falk
Lüsebrink wrote:

> Hi Bruce,
>
> I thought so. Are there any other means to accelerate this procedure (in the 
> future)?
>
> Best,
> Falk
>
> -Ursprüngliche Nachricht-
> Von: Bruce Fischl [mailto:fis...@nmr.mgh.harvard.edu]
> Gesendet: Donnerstag, 21. Juli 2016 15:52
> An: Falk Lüsebrink
> Cc: Freesurfer support list
> Betreff: Re: AW: AW: [Freesurfer] mri_ca_label with high resolution 
> data
>
> Hi Falk
>
> not every part of it is accelerated, but some are
>
> cheers
> Bruce
>
>
> On Thu, 21 Jul 2016, Falk Lüsebrink wrote:
>
>> Hi Bruce,
>>
>> I'm using the current dev build:
>>
>> ProgramName: mri_ca_label  ProgramArguments: --all-info
>> ProgramVersion: $Name:  $  TimeStamp: 2016/07/21-13:42:39-GMT
>> BuildTimeStamp: Jul 12 2016 13:31:56  CVS: $Id: mri_ca_label.c,v 
>> 1.113
>> 2016/05/13 18:02:49 fischl Exp $  User: luesebrink  Machine: reco
>> Platform: Linux  PlatformVersion: 3.16.0-4-amd64  CompilerName: GCC
>> CompilerVersion: 40400
>>
>> and in the log it says to use 12 threads
>>
>> == Number of threads available to mri_ca_label for OpenMP = 12 ==
>>
>> however, at least while saving the intensity scale
>>
>> saving intensity scales to aseg.auto_noCCseg.label_intensities.txt
>> saving sequentially combined intensity scales to 
>> aseg.auto_noCCseg.label_intensities.txt
>>
>> it doesn't seem to help.
>>
>> Best,
>> Falk
>>
>> 
>> Von: Bruce Fischl [fis...@nmr.mgh.harvard.edu]
>> Gesendet: Donnerstag, 21. Juli 2016 15:30
>> An: Falk Lüsebrink
>> Cc: Freesurfer support list
>> Betreff: Re: AW: [Freesurfer] mri_ca_label with high resolution data
>>
>> Hi Falk
>>
>> the dev version of mri_ca_label does use openmp, so should be faster.
>>
>> cheers
>> Bruce
>> On
>> Thu, 21 Jul 2016, Falk Lüsebrink wrote:
>>
>>> Hi Bruce,
>>>
>>> I started the process again with openmp set to 12 using the dev build from 
>>> 12th July. However, mri_ca_label uses only 1 thread at that point. So I 
>>> don't assume any faster processing.
>>>
>>> Best,
>>> Falk
>>>
>>>
>>> -Ursprüngliche Nachricht-
>>> Von: freesurfer-boun...@nmr.mgh.harvard.edu
>>> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Bruce 
>>> Fischl
>>> Gesendet: Dienstag, 19. Juli 2016 15:37
>>> An: Freesurfer support list
>>> Betreff: Re: [Freesurfer] mri_ca_label with high resolution data
>>>
>>> Hi Falk
>>>
>>> I think openmp will help with this in V6, but probably not before 
>>> Bruce
>>>
>>> On Tue, 19
>>> Jul 2016, Falk Lüsebrink wrote:
>>>
>>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> I'm currently processing a 250 µm MPRAGE with a dev build from mid of May.
>>>> Running recon-all with default parameters ran flawlessly. 
>>>> Afterwards I added the -hires flag to process the data without 
>>>> conformation.
>>>> However, since Saturday morning it is kind of stuck at mri_ca_label 
>>>> stating:
>>>>
>>>>
>>>>
>>>> saving sequentially combined intensity scales to 
>>>> aseg.auto_noCCseg.label_intensities.txt
>>>>
>>>>
>>>>
>>>> while  consuming around 30 GB of memory. I ran something similar 
>>>> before and processing works, it's just terribly slow. Maybe this 
>>>> particular stage is just not very efficient as it does take a few minutes 
>>>> on 1 mm data only?
>>>> Would it help to add the openmp flag in that case?
>>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>> Falk
>>>>
>>>>
>>>>
>>>> 
>>>>
>>>> Falk Lüsebrink, M. Sc.
>>>>
>>>>
>>>>
>>>> Otto-von-Guericke-Universität Magdeburg
>>>>
>>>> Forschungscampus STIMULATE
>>>>
>>>> http://www.forschungscampus-stimulate.de/
>>>>
>>>>
>>>>
>>>> Universitätsplatz 2
>>>>
>>>> 39106 Magdeburg
>>>>
>>>>
>>>>
>>>> Raum:ExFa - 4.06
>>>>
>>>> Telefon: 0391-67-19366
>>>>
>>>> Fax:   0391-67-19347
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> 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] Recon hires 7T {Disarmed}

[Falk Lüsebrink]

Hi Theresa,

first, if you use the -hires flag in version 5.3 the processing pipeline will 
not start to downsample your data at some point (if I remember correctly during 
the normalization stage). As you stated that you were expecting the automatic 
downsampling you should either omit the hires flag or you could follow the 
HiResRecon (https://surfer.nmr.mgh.harvard.edu/fswiki/HiResRecon) to process 
your data in your native resolution. You may need to change or add a few flags 
to process your data with hippocampal subfield segmentation and changes to 
version 5.3 (compared to 5.1). In case you want your data to be downsampled you 
should at least use the -3T flag additionally to correct for inhomogeneities in 
regards to your 7T data.

Second, the hippocampal subfield segmentation was, as far I read in the mailing 
list, vastly improved in version 6. As is it still in development, data 
processing should be done for testing only and not publication. Version 6 
additionally has full support for high resolution data (using the -hires flag 
should avoid downsampling to 1 mm). It can be downloaded as a developmental 
version.

Lastly, in regards to your issue, this usually happened to me if the resolution 
is not exactly 0.7 mm, but something like 0.69998. This results in a rounding 
conflict between conversion with mri_convert and mri_nu_intensity.mni. To 
resolve the issue you have two options: You can either use mri_convert -cs 
 on your dataset prior to feeding it to the recon-all script, this 
will result in resampling your dataset (using the size of actual voxel size 
should avoid interpolation). Otherwise you can use mri_convert --cropsize 
 to remove one voxel in every dimension prior to the inhomogeneity 
correction stage.

Best,
Falk


Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Köbe, Theresa
Gesendet: Mittwoch, 21. September 2016 13:51
An: freesurfer@nmr.mgh.harvard.edu
Betreff: [Freesurfer] Recon hires 7T {Disarmed}


Dear FreeSurfer Developers,

I am attempting to run recon-all on 7T MP2RAGE images (resolution 
0.7x0.7x0.7mm³) with hippocampus subfield segmentation. I use the freesurfer 
version 5.3 so that I expect an automatic down-sampling to 1x1x1mm³.

I used the data directly from the scanner (without reorientation to standard 
etc.) and used the following command:

recon-all -s $subject.freesurfer -hires -i $subject.mp2rage.nii -expert 
/media/NeuroMet_Project/scripts/expert.opts -all -hippo-subfields"

As expert option I used only: mris_inflate -n 15

The processing starts fine but ends with the following error:

 ERROR: dimension mismatch between input volume and seg
  input 321 321 321
  seg   322 322 322
Could you please help me dealing with this problem?
I attached also the log-file

Thank you so much.

Best Theresa

-
Charité - Universitätsmedizin Berlin
NeuroCure Clinical Research Center NCRC
Dipl.-Biol. Theresa Köbe
AG Kognitive Neurologie
Wiss. Mitarbeiter
Charitéplatz 1, D-10117 Berlin
Tel  +49 30 450 560 185
Fax +49 30 450 7 560 280
Interne Besuchsadresse: CCM, Sauerbruchweg 5, E2
MailScanner has detected a possible fraud attempt from "redir.aspx" claiming to 
be 
http://www.charite.de/service/lageplan/plan/map/ccm_sauerbruchweg_5/

___
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] Processing 7T data

[Falk Lüsebrink]

Hi Damien,

depending on what you want to do you are forced to use the stable release. The 
developmental version of FreeSurfer should be used for testing only, not 
publishing results.

Following the notes of the HiResRecon 
(https://surfer.nmr.mgh.harvard.edu/fswiki/HiResRecon) you should be able to 
process your data with version 5.1 and above at native resolution. However, 
this affects the surfaces based processing only as the aseg.mgz is simply 
upsampled from previously downsampled data. There are also a few methods to 
make use of the native resolution which I haven't tested in recent past, e.g. 
using the surface of the downsampled data on the native data. Otherwise you 
will have to downsample you data to 1mm using v5.3.

Version 6 will be able to handle high resolution data at native resolution 
using the -hires flag, making the workaround of the HiResRecon obsolete. Having 
tested the developmental version (from mid September) on several high 
resolution 7T datasets it seems to work nicely and is less laborious than 
before. I haven't compared results between v5.3 and v6 though.

Best,
Falk

-Ursprüngliche Nachricht-
Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Damien MARIE
Gesendet: Donnerstag, 6. Oktober 2016 14:01
An: freesurfer@nmr.mgh.harvard.edu
Betreff: [Freesurfer] Processing 7T data

Dear experts,

I plan to process some MRI 7T data, 0.6 mm^3 isotropic voxel size. The aim is 
to look a R1 maps.

I was wondering what was your opinion concerning the downsampling to 1 mm^3 
(performed by the current FreeSurfer version if I am correct). What do you 
think would be the best: FreeSurfer 5.3 , FreeSurfer 5.3-HCP or FreeSurfer beta 
6.0?

Thank You and Best,

Damien

___
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] [Dev Build] Processing very high resolution dataset

[Falk Lüsebrink]

Dear all,

using mris_topo_fixer instead of mris_fix_topology also results in a 
segmentation fault. The command line used was:
mris_topo_fixer -mgz -warning -seed 1234  lh

INFO: assuming .mgz format
setting seed for random number genererator to 1234
reading input surface /surf/lh.orig...
Before topology correction, eno=-2042 (nv=2743306, nf=5490696, ne=8236044, 
g=1022)
Surface Diagnostics:
   eno=-2042 (nv=2743306, nf=5490696, ne=8236044)
   # of border vertices [ #v ~ #f ] 0
   # of edges with single face  0
   # of edges with more than 2 faces0
   # of corner configurations   0
   The original surface is a valid manifold
   Counting the number of connected components
   The original surface has one component
   The original surface does not self-intersect

The surface has 1022 loops (X=-2042)

Finding true center and radius of Spherical Surface...done
Surface centered at (0,0,0) with radius 100.0 in 15 iterations
identify defects...
marking ambiguous vertices...
1475515 ambiguous faces found in tessellation
segmenting defects...
Segmentation fault

Any suggestions or tips are highly appreciated.

Best,
Falk

Von: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Falk Lüsebrink
Gesendet: Donnerstag, 6. Oktober 2016 17:51
An: Freesurfer support list
Betreff: [Freesurfer] [Dev Build] Processing very high resolution dataset

Dear all,

I am currently trying to process a MPRAGE with an isotropic resolution of 250 
µm acquired in vivo. Downsampling the data to .5 and 1 mm resulted in no errors 
and surfaces look good.

However, while processing the data at native resolution I receive a 
segmentation fault during topology fixation. May this be related to the number 
of vertices / faces? Surfaces look okay and not totally corrupted. Memory and 
disk space are available plentiful.

INFO: assuming .mgz format
$Id: mris_fix_topology.c,v 1.50 2016/01/20 23:42:15 greve Exp $
  $Id: mrisurf.c,v 1.781 2016/06/13 21:20:50 fischl Exp $
before topology correction, eno=-2042 (nv=2743306, nf=5490696, ne=8236044, 
g=1022)
using quasi-homeomorphic spherical map to tessellate cortical surface...

Correction of the Topology
Finding true center and radius of Spherical Surface...done
Surface centered at (0,0,0) with radius 100.0 in 11 iterations
marking ambiguous vertices...
1461809 ambiguous faces found in tessellation
segmenting defects...
Segmentation fault

Uploading of the dataset is currently not possible.

Best,
Falk
___
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] high resolution data using recon-all

[Falk Lüsebrink]

Hi Yun,

if it is for some reason impractical to use a beta version of FreeSurfer you 
can also try to follow the HiResRecon (http://freesurfer.net/fswiki/HiResRecon) 
I put together some time ago. This solves the issues related to high resolution 
data and will circumvent conformation to 1 mm^3.

However, if the subcortical segmentation is of interest or if you want to have 
a look at a future-proof processing pipeline you should aim for the beta 
version of FreeSurfer. Several improvements have been made to v6.0 so it's 
definitely worth checking out, especially for high resolution data.

Best,
Falk

-Ursprüngliche Nachricht-
Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Bruce Fischl
Gesendet: Samstag, 10. Oktober 2015 19:23
An: Freesurfer support list
Cc: Kyoko Fujimoto
Betreff: Re: [Freesurfer] high resolution data using recon-all

Hi Yun

you should probably get a beta version of 6.0 - it has much improved highres 
support. 7T can be hard though. Kyoko Fujimoto (ccd) put together a pipeline 
for 7T that worked pretty well. You might check in with her Bruce


On Sat, 10 Oct 2015, Yun Wang wrote:

> Hi All,
>
> I have 7T high resolution data 0.625mm.  Is it  appropriate to process the 
> data using recon-all ? If not, any idea?
>
> Thanks!
>
>
> Yun Wang
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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


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

Re: [Freesurfer] high resolution data using recon-all

[Falk Lüsebrink]

Hi Kevin,

yes, FS 6.0 will make my workaround redundant. Changes have been done to 
mri_normalize, mri_em_register and mri_watershed enabling high resolution 
processing without constraints. However, as 7T data is always a bit tricky to 
process it does not run as smoothly as the standard recon-all. At least as far 
as I can tell.

Best,
Falk

P.S. Glad to hear the workaround is doing well! :)

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Kevin Aquino
Gesendet: Montag, 12. Oktober 2015 11:40
An: Freesurfer support list
Cc: cloud87...@gmail.com
Betreff: Re: [Freesurfer] high resolution data using recon-all

Hi Falk,

Just to jump on this as well – does FS 6.0 make HiResRecon redundant?

– I've been using HiResRecon [working like a charm :) ] and wondering if FS 6.0 
will cut the need for that workaround.

Cheers,


Dr Kevin Aquino
Research fellow,
Sir Peter Mansfield Magnetic Resonance Center, The University of Nottingham.

Honorary Research Fellow
School of Physics, Faculty of Science, University of Sydney

E kevin.aqu...@nottingham.ac.uk<mailto:kevin.aqu...@nottingham.ac.uk>, 
aqu...@physics.usyd.edu.au<mailto:aqu...@physics.usyd.edu.au> | W 
www.physics.usyd.edu.au/~aquino/<http://www.physics.usyd.edu.au/~aquino/>

--

The brain is a wonderful organ. It starts working the moment you get up and 
does not stop until you get into the office.
-
Robert Frost

CRICOS 00026A
This email plus any attachments to it are confidential. Any unauthorised use is 
strictly prohibited. If you receive this email in error, please delete it and 
any attachments.

Please think of our environment and only print this e-mail if necessary.


On Mon, Oct 12, 2015 at 9:24 AM, Falk Lüsebrink 
mailto:falk.luesebr...@ovgu.de>> wrote:
Hi Yun,

if it is for some reason impractical to use a beta version of FreeSurfer you 
can also try to follow the HiResRecon (http://freesurfer.net/fswiki/HiResRecon) 
I put together some time ago. This solves the issues related to high resolution 
data and will circumvent conformation to 1 mm^3.

However, if the subcortical segmentation is of interest or if you want to have 
a look at a future-proof processing pipeline you should aim for the beta 
version of FreeSurfer. Several improvements have been made to v6.0 so it's 
definitely worth checking out, especially for high resolution data.

Best,
Falk

-Ursprüngliche Nachricht-
Von: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>]
 Im Auftrag von Bruce Fischl
Gesendet: Samstag, 10. Oktober 2015 19:23
An: Freesurfer support list
Cc: Kyoko Fujimoto
Betreff: Re: [Freesurfer] high resolution data using recon-all

Hi Yun

you should probably get a beta version of 6.0 - it has much improved highres 
support. 7T can be hard though. Kyoko Fujimoto (ccd) put together a pipeline 
for 7T that worked pretty well. You might check in with her Bruce


On Sat, 10 Oct 2015, Yun Wang wrote:

> Hi All,
>
> I have 7T high resolution data 0.625mm.  Is it  appropriate to process the 
> data using recon-all ? If not, any idea?
>
> Thanks!
>
>
> Yun Wang
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu>
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu<mailto: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<mailto: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] Freesurfer 6.0 - Autorecon2 failure (mris_euler_number) using high res (0.5mm isotropic) T1 image

[Falk Lüsebrink]

Hi Ajay,

I ran into the same error processing hires data a while ago using a nightly 
build of centos 6 with the hires flag only. Disk space or alike wasn't an 
issue. I ran mris_topo_fixer instead of mris_fix_topology to get working 
surfaces.

Best,
Falk

-Ursprüngliche Nachricht-
Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Bruce Fischl
Gesendet: Sonntag, 29. November 2015 22:48
An: Freesurfer support list
Betreff: Re: [Freesurfer] Freesurfer 6.0 - Autorecon2 failure 
(mris_euler_number) using high res (0.5mm isotropic) T1 image

Hi Ajay

are you sure you didn't run out of disk space? That error is a sanity check on 
the surfaces that should never occur

cheers
Bruce
On Sun, 29 Nov 2015, Ajay
Kurani wrote:

> Hello Freesurfer experts,
>    I am trying to run Freesurfer 6.0 beta (downloaded 10/15/15 
> version) with the -hires flag to process an MNI template image which 
> is 0.5mm isotropic.  Stage 1 ran well and on stage 2 there is an error 
> during
> pocessing:
> 
> Command run:
> recon-all -s ICBM -autorecon2 -openmp 8 -3T -hires -expert expert.opts
> 
> I supplied a skull stripped brain which was nu corrected and so I used 
> the T1.mgz and copied it to brainmask.mgz and nu.mgz in autorecon1 
> stage.  I then ran autorecon2 and it was working well until I was at 
> the -fix stage and ran into the following error:
> 
> 
> Error:
> mris_euler_number ./surf/lh.orig
> mrisFindNeighbors: ./surf/lh.orig: face[46196].v[0] = 24215, but face 
> 46196 not in vertex 24215 face list
> 
> 
> 
> I am not sure if this is due to the fact that we have a very high 
> resolution image (template) and if there are any modifications needed 
> aside from the hires flag.  Are there any suggestions you have?
> 
> Thanks,
> Ajay
> 
>

___
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] Freesurfer 6.0 - Autorecon2 failure (mris_euler_number) using high res (0.5mm isotropic) T1 image

[Falk Lüsebrink]

Hi Ajay,

you should

cp ?h.orig.nofix ?h.orig
cp ?h.inflated.nofix ?h.inflated

with ? being l or r depending your hemisphere. After the fixing stage the 
surfaces got damaged somehow, therefore you have to recreate it them. I’m not 
entirely sure about the qsphere. Probably you have to run the -qsphere stage 
again also.

Best,
Falk


Von: Ajay Kurani [mailto:dr.ajay.kur...@gmail.com]
Gesendet: Montag, 30. November 2015 21:50
An: Falk Lüsebrink
Cc: Freesurfer support list; Bruce Fischl
Betreff: Re: [Freesurfer] Freesurfer 6.0 - Autorecon2 failure 
(mris_euler_number) using high res (0.5mm isotropic) T1 image

Hi Falk,
   I used the command and got the following error:

Command: ris_topo_fixer -mgz -warning -seed 1234 ICBM lh
mris_topo_fixer -mgz -warning -seed 1234 ICBM lh
INFO: assuming .mgz format
setting seed for random number genererator to 1234
reading input surface 
/home/imuser/Downloads/mni_icbm152_nlin_sym_09b_nifti/mni_icbm152_nlin_sym_09b/ICBM/surf/lh.orig...
mrisFindNeighbors: 
/home/imuser/Downloads/mni_icbm152_nlin_sym_09b_nifti/mni_icbm152_nlin_sym_09b/ICBM/surf/lh.orig:
 face[46196].v[0] = 24215, but face 46196 not in vertex 24215 face list

mris_topo_fixer -mgz -warning -seed 1234 ICBM rh
INFO: assuming .mgz format
setting seed for random number genererator to 1234
reading input surface 
/home/imuser/Downloads/mni_icbm152_nlin_sym_09b_nifti/mni_icbm152_nlin_sym_09b/ICBM/surf/rh.orig...
mrisFindNeighbors: 
/home/imuser/Downloads/mni_icbm152_nlin_sym_09b_nifti/mni_icbm152_nlin_sym_09b/ICBM/surf/rh.orig:
 face[35822].v[2] = 18903, but face 35822 not in vertex 18903 face list
Any suggestions would be appreciated.
Thanks,
Ajay

On Mon, Nov 30, 2015 at 2:41 AM, Falk Lüsebrink 
mailto:falk.luesebr...@ovgu.de>> wrote:
Hi Ajay,

I ran into the same error processing hires data a while ago using a nightly 
build of centos 6 with the hires flag only. Disk space or alike wasn't an 
issue. I ran mris_topo_fixer instead of mris_fix_topology to get working 
surfaces.

Best,
Falk

-Ursprüngliche Nachricht-
Von: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>]
 Im Auftrag von Bruce Fischl
Gesendet: Sonntag, 29. November 2015 22:48
An: Freesurfer support list
Betreff: Re: [Freesurfer] Freesurfer 6.0 - Autorecon2 failure 
(mris_euler_number) using high res (0.5mm isotropic) T1 image

Hi Ajay

are you sure you didn't run out of disk space? That error is a sanity check on 
the surfaces that should never occur

cheers
Bruce
On Sun, 29 Nov 2015, Ajay
Kurani wrote:

> Hello Freesurfer experts,
>I am trying to run Freesurfer 6.0 beta (downloaded 10/15/15
> version) with the -hires flag to process an MNI template image which
> is 0.5mm isotropic.  Stage 1 ran well and on stage 2 there is an error
> during
> pocessing:
>
> Command run:
> recon-all -s ICBM -autorecon2 -openmp 8 -3T -hires -expert expert.opts
>
> I supplied a skull stripped brain which was nu corrected and so I used
> the T1.mgz and copied it to brainmask.mgz and nu.mgz in autorecon1
> stage.  I then ran autorecon2 and it was working well until I was at
> the -fix stage and ran into the following error:
>
>
> Error:
> mris_euler_number ./surf/lh.orig
> mrisFindNeighbors: ./surf/lh.orig: face[46196].v[0] = 24215, but face
> 46196 not in vertex 24215 face list
>
>
>
> I am not sure if this is due to the fact that we have a very high
> resolution image (template) and if there are any modifications needed
> aside from the hires flag.  Are there any suggestions you have?
>
> Thanks,
> Ajay
>
>

___
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] Replacing / turning off denoising filter

[Falk Lüsebrink]

Hi Bruce,



I have applied one of his denoising algorithms on my high resolution datasets 
and also got very nice results. I used it on a single subject only, however, 
this could be beneficial for the upcoming hires pipeline to account for lower 
SNR.



You can find his algorithms and publications here:



https://sites.google.com/site/pierrickcoupe/softwares/denoising-for-medical-imaging/mri-denoising/mri-denoising-software



Best,

Falk



Von: Bruce Fischl
Gesendet: Freitag, 18. März 2016 19:43
An: Freesurfer support list
Betreff: Re: [Freesurfer] Replacing / turning off denoising filter



that's interesting. Is it open source? If so, can you point us at it? Maybe
someone should compare it to the version I wrote 20 years ago :)

On Fri, 18 Mar 2016, Mojmír Vinkler wrote:

> Thanks!
> Just FYI - we applied newer version of NLME from Pierrick Coupé before
> running freesurfer and it greatly improved segmentation results.
>
> On Wed, Mar 16, 2016 at 3:47 PM Bruce Fischl 
> wrote:
>   Hi Mojmir
>
>   we don't apply mri_nlfilter by default so there is no need to
>   turn it
>   off. You are welcome to try it out. It implement some nonlinear
>   filters
>   including what is now called nonlocal means as described in this
>   paper:
>
> http://ieeexplore.ieee.org/xpl/abstractAuthors.jsp?reload=true&arnumber=745
>   732
>
>
>   cheers
>   Bruce
>
>   On
>   Wed, 16 Mar 2016, Mojmír Vinkler wrote:
>
>   > Hi,
>   > I was wondering if it's possible to replace or turn off your
>   denoising
>   > algorithm `mri_nlfilter`. We'd like to try different denoising
>   filters and
>   > compare how they influence segmentation performance. Right now
>   we're
>   > applying filter before running recon-all, but I fear that
>   applying your
>   > filter on already filtered image might degrade our analysis.
>   >
>   > I couldn't find any mention of mri_nlfilter besides this one
>   on 
> mailinglisthttps://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2011-October/020
>   762.
>   > html. I hope I didn't miss something anything.
>   >
>   > Thanks!
>   > Mojmir
>   >
>   >___
>   Freesurfer mailing list
>   Freesurfer@nmr.mgh.harvard.edu
>   https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
>   The information in this e-mail is intended only for the person
>   to whom it is
>   addressed. If you believe this e-mail was sent to you in error
>   and the e-mail
>   contains patient information, please contact the Partners
>   Compliance HelpLine at
>   http://www.partners.org/complianceline . If the e-mail was sent
>   to you in error
>   but does not contain patient information, please contact the
>   sender and properly
>   dispose of the e-mail.
>
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

Re: [Freesurfer] temporal lobe pial surface problem

[Falk Lüsebrink]

Hi Xiaomin,

currently I don't have access to my notes, however, if I remember correctly, 
you can specify thresholds in mris_make_surfaces for consideration in the 
surface placement. This obviously works well only if the contrast between 
WM/GM/CSF is high enough.

If you are interested and nobody jumps in giving you the according flags, let 
me know.

Best,
Falk


Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu]" im Auftrag von "Xiaomin Yue 
[yu...@hotmail.com]
Gesendet: Dienstag, 19. April 2016 01:13
An: Freesurfer support list
Cc: macar...@libero.it
Betreff: Re: [Freesurfer] temporal lobe pial surface problem

Hi Jon,

Thanks for your answers.   There is gray-white contrast in the temporal lobe, 
but same as you said that the gray-csf is low.  Attached is a screenshot.  
let's me know if you need more information.

Xiaomin

> Date: Mon, 18 Apr 2016 17:43:47 -0400
> From: j...@nmr.mgh.harvard.edu
> To: yu...@hotmail.com
> CC: freesurfer@nmr.mgh.harvard.edu; macar...@libero.it
> Subject: Re: [Freesurfer] temporal lobe pial surface problem
>
>
> hi Xiaomin,
>
> it is tough to say what might be causing the problem since a lot can go
> wrong in the anterior temporal lobes at 7T. you say that your contrast is
> low there? it is possible to have OK gray-white contrast but low overall
> signal levels (so poor gray-CSF contrast) due to dielectric effects as
> bruce mentioned, which can make the MP2RAGE ratio images noisy in that
> region. also some adiabatic inversion pulses break down around the
> temporal poles due to the B0 inhomogeneity around the ear canals. if you
> could send a screenshot we'd have a better chance at diagnosing the
> problem.
>
>
> -jon
>
>
>
>
> On Mon, 18 Apr 2016, Xiaomin Yue wrote:
>
> > Hi Jon Polimeni,
> > Do you have any suggestions on the following questions?
> > Thanks,Xiaomin
> >
> > Date: Fri, 15 Apr 2016 12:07:48 -0400
> > From: fis...@nmr.mgh.harvard.edu
> > To: freesurfer@nmr.mgh.harvard.edu
> > CC: macar...@libero.it; j...@nmr.mgh.harvard.edu
> > Subject: Re: [Freesurfer] temporal lobe pial surface problem
> >
> > Hi Xiaomin
> >
> > it's really hard to say without seeing more detail in your images. Do you
> > have contrast in the temporal lobe? Frequently it goes away at 7T due to
> > dielectric effects. I'll cc Jon Polimeni who is our 7T (among other
> > things!) expert.
> >
> > cheers
> > Bruce
> >
> >
> > On Fri, 15 Apr 2016, Xiaomin Yue wrote:
> >
> > > Hi Bruce,
> > > I have done the recon-all (fs5.3) with the data collected from a 7T 
> > > scanner
> > > using MP2Rage. The recon went well without problem. But the the temporal
> > > reconstruction looks clearly not correct (see attached). I tried to push
> > > the pial surface outside by editing the white matter evidenced in the
> > > attached figures, but has no effect to genera correct pial surface. I do
> > > realize that the contrast is low in the anterior temporal lobes. However, 
> > > I
> > > am wondering if there are expert parameters I can use to push the pial
> > > surface into the right place. If that isn't a option, can I use some other
> > > images collected during the MP2rage scan to help the segmentation in the
> > > anterior temporal lobe? Those extract scans are: inv1_nd, inv1_phs_nd, ,
> > > t1, inv2_nd, invs_phas_nd,
> > >
> > > thanks very much.
> > >
> > > Xiaomin
> > >
> > >
> >
> > ___
> > Freesurfer mailing list
> > Freesurfer@nmr.mgh.harvard.edu
> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> >
> >
> > The information in this e-mail is intended only for the person to whom it is
> > addressed. If you believe this e-mail was sent to you in error and the 
> > e-mail
> > contains patient information, please contact the Partners Compliance 
> > HelpLine at
> > http://www.partners.org/complianceline . If the e-mail was sent to you in 
> > error
> > but does not contain patient information, please contact the sender and 
> > properly
> > dispose of the e-mail.
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

Re: [Freesurfer] recon-all on 0.5mm scan?

[Falk Lüsebrink]

Hi Trisanna,

you can find instructions on how to process data with an isotropic resolution 
other than 1mm^3 with FreeSurfer v5.1 and above here:
https://surfer.nmr.mgh.harvard.edu/fswiki/HiResRecon

For v5.3 the pipeline should be slightly adapted, however, can easily be done. 
If you need assistance, just let me know. In the upcoming release of v6 this 
workaround will not necessary anymore.

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Trisanna 
Sprung-Much
Gesendet: Mittwoch, 25. Mai 2016 17:35
An: Freesurfer support list
Betreff: [Freesurfer] recon-all on 0.5mm scan?

Hi Freesurfer
I would like to know if it is possible to create surfaces from a scan that is 
0.5mm isotropic. I tried to run recon-all on our MNI 2009b atlas which is 0.5mm 
cubed and it crashed quite quickly afterwards. I wonder if this has to do with 
the fact that Freesurfer tried to conform it to 1mm isotropic?
When I ran recon-all on the 1mm atlas it created some nice surfaces.
Let me know if you would like the .log as I cannot seem to make much sense of 
it.
best wishes
Trisanna
--
Ph.D. Candidate
McGill University
Integrated Program in Neuroscience
Psychology


___
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] Two questions regarding mri_fill and mris_fix_topology

[Falk Lüsebrink]

Dear FreeSurfers,

 

I am processing some T1-weighted images of the human brain with an isotropic resolution of .5 mm using version 5.1.

 

After mri_fill my hemispheres are separated nicely and the cerebellum is completely removed. However, looking at the filled.mgz, posterior and superior of the corpus callosum some residual of white matter can be found in the longitudinal fissure. It does not remain if I look at the conformed data, altough these leftovers are found in the wm.mgz of both datasets. As this does not happen using conformed data I assume that the cutting plane is not "broad" enough in case of higher resolution data or something related. Is there some way to tweak this?

 

Secondly, I currently skip the -fix stage of recon-all completely while processing this data, but I would like to correct at least some of its defects. I already I have seen in the help of mris_fix_topology that it is possible to fix just one defect and I extracted the defects and their number of vertices using the defect-seg script. Is it possible to save the resulting surface, so I am able to correct the defects I want to consecutively?

 

Best,

Falk
___
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] Speeding up mris_fix_topology

[Falk Lüsebrink]

Hello all,

I'm processing some high resolution data with an isotropic resolution of 0.5mm 
and I was wondering if it would be possible to speed up mris_fix_topology 
somehow. Due to the increased number of vertices and also increased number of 
defects this stage takes incredibly long (e.g. lots of days). 

It would be nice if the defects are handled separately of each other to 
parallize the process. Maybe by first estimating and specifying the number of 
defects. Then by being able to run multiple instances of mris_fix_topology for 
the same subjects correcting one or a range of defects each.

Best,
Falk
___
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] Speeding up mris_fix_topology

[Falk Lüsebrink]

Hi Bruce,

so you use the conformed and fixed ?h.orig during mris_make_surfaces on the 
.5mm data? Never thought of that.

Best,
Falk


 Original-Nachricht 
> Datum: Wed, 16 Jan 2013 11:16:45 -0500 (EST)
> Von: Bruce Fischl 
> An: "Falk Lüsebrink" 
> CC: freesurfer@nmr.mgh.harvard.edu
> Betreff: Re: [Freesurfer] Speeding up mris_fix_topology

> Hi Falk
> 
> we usually don't process the .5mm data directly. Instead we "conform" it
> to 
> 1mm iso, recon it, then run mris_make_surfaces posthoc directly on the
> .5mm 
> data to nudge the surfaces around to agree with it.
> 
> Parallelizing mris_fix_topology is certainly possible if only we had an 
> extra engineer to work on it....
> 
> cheers
> Bruce
> 
> 
>   On Wed, 16 Jan 2013, "Falk Lüsebrink" wrote:
> 
> > Hello all,
> >
> > I'm processing some high resolution data with an isotropic resolution of
> 0.5mm and I was wondering if it would be possible to speed up
> mris_fix_topology somehow. Due to the increased number of vertices and also 
> increased
> number of defects this stage takes incredibly long (e.g. lots of days).
> >
> > It would be nice if the defects are handled separately of each other to
> parallize the process. Maybe by first estimating and specifying the number
> of defects. Then by being able to run multiple instances of
> mris_fix_topology for the same subjects correcting one or a range of defects 
> each.
> >
> > Best,
> > Falk
> > ___
> > 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] beta

[Falk Lüsebrink]

Hi Colin,

actually there is no hard limit for the size of your input data, except for the 
subcortical segmentation which behaves quite strange.

What I currently do is to run recon-all on the hires data normally conforming 
the data. Then I use the upsampled brainmask as a mask to skullstrip my hires 
data and the upsampled aseg stuff to feed the upcoming stages of the recon-all 
pipeline. The -fix stage takes incredibly long that is why I'm trying to find a 
suitable work-around here. All other stages are being run normally.

Although isotropic data and the -noconform flag are mandatory.

Best,
Falk

 
 Original-Nachricht 
> Datum: Mon, 21 Jan 2013 19:19:25 -0500 (EST)
> Von: Bruce Fischl 
> An: Colin Reveley 
> CC: Joshua Lee , freesurfer@nmr.mgh.harvard.edu, Nick 
> Schmansky 
> Betreff: Re: [Freesurfer] beta

> Hi Colin
> 
> yes, but we simply don't have the person power to do it at the moment. Our
> FS support grant ends in a month and is not going to get renewed, so it's 
> going to be hard to do anytime soon.
> 
> sorry
> Bruce
> 
> 
> On 
> Mon, 21 Jan 2013, Colin Reveley wrote:
> 
> > do you plan to support data that is more that 256^3, ever?
> >  
> > just, do you plan to support that
> > 
> > On 21 January 2013 22:17, Bruce Fischl 
> wrote:
> >   no, it won't change anything on the subcortical side yet
> >   On Mon, 21 Jan 2013, Joshua Lee wrote:
> > 
> >
> > Thanks Bruce. That sounds great. Will subcortical
> segmentations also benefit yet. I remember that you once
> > told me that there were
> > some problems with it.
> > -
> > Josh
> > 
> >
> > On Mon, Jan 21, 2013 at 12:39 PM, Bruce Fischl
>  wrote:
> >       Hi Josh
> >
> >       the way we are handling sub-mm data is to run it
> through the standard recon-all, then run a
> > postprocessing surface
> >       deformation on the higher res data. Our preliminary
> results are pretty encouraging on T1s, T2s and
> > FLAIRs.
> >
> >       cheers
> >       Bruce
> > 
> >
> >       On Mon, 21 Jan 2013, Joshua Lee wrote:
> >
> >             Does this mean that using Freesurfer at
> sub-1mm isotropic resolutions will not be possible next
> > version?
> >             Josh
> > 
> >
> >             On Sun, Jan 20, 2013 at 8:07 AM, Nick
> Schmansky  wrote:
> >                   Colin,
> >
> >                   It will still error if any
> dimension is greater than 256, which then means
> >                   the flag -cw256 must be added to
> recon-all.  This flag chops dimensions
> >                   greater than 256 down to 256.
>  The reason it doesnt do it automatically is
> >                   that with this chopping, its not
> certain that it isnt removing into the
> >                   head, so the user needs to be
> aware of this, so that they can inspect
> >                   orig.mgz with freeview to make
> sure the head is fully visible.
> >
> >                   Nick
> >
> >                   > Does the beta permit volumes
> bigger than 256^3 voxels? just askingand
> >                   > just asking about raw
> dimensions in unit-voxels at the start of pipeline
> >                   >
> >                   > cheers
> >                   >
> >                   > Colin
> >                   >
> >                   > On 18 January 2013 17:00,
>  wrote:
> >                   >
> >                   >> Send Freesurfer mailing list
> submissions to
> >                   >>        
> freesurfer@nmr.mgh.harvard.edu
> >                   >>
> >                   >> To subscribe or unsubscribe
> via the World Wide Web, visit
> >                   >>        
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> >                   >> or, via email, send a message
> with subject or body 'help' to
> >                   >>        
> freesurfer-requ...@nmr.mgh.harvard.edu
> >                   >>
> >                   >> You can reach the person
> managing the list at
> >                   >>        
> freesurfer-ow...@nmr.mgh.harvard.edu
> >                   >>
> >                   >> When replying, please edit
> your Subject line so it is more specific
> >                   >> than "Re: Contents of
> Freesurfer digest..."
> >                   >>
> >                   >> Today's Topics:
> >                   >>
> >                   >>    1. v5.2.0 beta, round two
> (Nick Schmansky)
> > 

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

[Falk Lüsebrink]

Dear Chris and Antonin,

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

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

Best,
Falk


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

Dear Chris,

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

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

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

Antonin


Hi all,

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

Thanks,
Chris Markiewicz



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


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

Re: [Freesurfer] FS v6.0 recon-all freezes

[Falk Lüsebrink]

Dear Andrius,

You can load the ?h.inflated.nofix in freeview and the overlay ?h.defect_labels 
to see what's going on. It may be that a chunk of skull or the cerebellum is 
still attached, in which case you'll want to correct the brainmask.mgz or 
wm.mgz, respectively, to remove the non-brain tissue.

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Andrius
Gesendet: Freitag, 10. März 2017 10:06
An: freesurfer@nmr.mgh.harvard.edu
Betreff: [Freesurfer] FS v6.0 recon-all freezes

Hi,
Maybe some could give advice regarding my problem with FS v6.0.
Now I am running recon-all for my patients cohort on Linux Centos 6, FS v6.0. 
It is PC with i5 intel, 4 Core, 8 Gb RAM. 80% of my subjects finished recon-all 
process without errors pretty fast (it takes about 11-14 hours per subject). 
But about 20% subjects hang at the same point of recon all :

#@# Fix Topology Copy lh Wed Mar  8 11:22:47 EET 2017
#@# Fix Topology Copy rh Wed Mar  8 11:22:47 EET 2017
#@# Fix Topology lh Wed Mar  8 11:22:47 EET 2017
#@# Fix Topology rh Wed Mar  8 11:22:47 EET 2017
It hangs for infinity at this point. Tried to do it on other PC with same 
parameters but it stucks at the same point.
Any ideas what is wrong?
Thank you very much
Andrius
___
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] Improving the brainmask.mgz using aseg.mgz for getting rid of dura

[Falk Lüsebrink]

Hi Karteek,

as for higher resolution (>0.7mm) the brainmask often includes lots of 
residual, I changed my pre-processing slightly.

Currently I do bias field correct my 7T data with SPM and create a mask of the 
WM, GM and CSF segmentation you get along with it. Then I recon-all -autorecon1 
the bias field corrected volume and mask the T1.mgz with the SPM mask and 
additionally run mri_gcut. This does seem to work fine on my data. Afterwards I 
continue with -autorecon2 and -autorecon3.

Best,
Falk


Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu]" im Auftrag von "Karteek 
Popuri [kpop...@sfu.ca]
Gesendet: Donnerstag, 18. Mai 2017 16:42
An: freesurfer@nmr.mgh.harvard.edu
Betreff: [Freesurfer] Improving the brainmask.mgz using aseg.mgz for getting
rid of dura

Hi,
My goal is to use the best possible skull-stripped version of the input MRI. Is 
brainmask.mgz the one? or I was wondering if anyone has tried improving the 
brainmask.mgz further by masking it out using the aseg.mgz. Will that help with 
regards to getting rid of the dura in the brainmask.mgz. My intuition is 
because the generation of aseg.mgz includes a surface-based algorithm, the 
smoothing constraints of the surface evolution should minimize the "leakage" of 
the GM surface into the dura, hence the aseg might have some dura but not as 
much as the brainmask. Will be thankful for any suggestions/comments.
Karteek
___
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] FreeSurfer on Windows 10 64-bit

[Falk Lüsebrink]

Dear Peter,

I haven't tried myself, but have a look at:  
https://github.com/stnava/ANTsR/wiki/Installing-ANTsR-in-Windows-10-(along-with-FSL,-Rstudio,-Freesurfer,-etc).
 It gives an overview of several neuroscientific tools to be installed using 
the Windows 10 bash.

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Peter Stanwell
Gesendet: Mittwoch, 12. Juli 2017 09:11
An: freesurfer@nmr.mgh.harvard.edu
Betreff: [Freesurfer] FreeSurfer on Windows 10 64-bit

Dear all,
I'm looking to set up FreeSurfer on a Windows 10, 64-bit OS. Has anyone tried 
this using the Linux BASH shell on the latest (anniversary) version of Windows 
10? If so, any tricks to to watch out for?
Best, Peter
___
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] Switch FreeSurfer Desikan-Killiany atlas to Civet

[Falk Lüsebrink]

Dear Antonin,

I haven’t used CIVET myself, however, if I remember correctly it employs 
several metrics to estimate cortical thickness, referred to “Link”, “Laplace”, 
and “Average Near”. The latter one is a re-implementation of the one used in 
FreeSurfer. They are described and compared here: 
https://www.ncbi.nlm.nih.gov/pubmed/15588607.

Regarding differences between the pipelines it may be easiest to have a look 
here: 
http://www.bic.mni.mcgill.ca/ServicesSoftware/CIVET-2-1-0-Table-of-Contents and 
especially at the references.

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Antonin Skoch
Gesendet: Samstag, 15. Juli 2017 00:24
An: freesurfer@nmr.mgh.harvard.edu
Betreff: Re: [Freesurfer] Switch FreeSurfer Desikan-Killiany atlas to Civet


Dear Trisanna,

thank you for the reference. However, I did not find any specific information 
in this paper what specific methods are used in CIVET and what is the 
difference in implementation between CIVET and FreeSurfer.

Antonin



I believe the cortical thickness measures are taken slightly differently.

This paper might offer some insights.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4408913/



Trisanna



--

Ph.D. Candidate

McGill University

Integrated Program in Neuroscience

Psychology





On Fri, Jul 14, 2017 at 8:29 AM, Antonin Skoch 
mailto:a...@ikem.cz>> wrote:



> Dear Zhiquiang,

>

> as a regular user of FreeSurfer I am wondering, what is the advantage of

> using Civet instead of FreeSurfer?

>

> Are there some functionalities in Civet which are not available in

> FreeSurfer?

> Or does Civet offer better performance/accuracy/precision in estimation of

> surface models for some situations/datasets?

>

> Antonin Skoch

>

>

> Hello FreeSurfer Developers,

>

> I am attempting to switch the Desikan-Killiany atlas of FreeSurfer to Civet.

> But I have no idea to solve the problem. Would you like to give me some

> suggestions or some detailed steps to help me accomplish the tasks ?

>

>

> Best wishes,

> Zhiqiang Sha

>
___
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] -nuiterations and -norm3diters under FreeSurfer 6.0

[Falk Lüsebrink]

Dear Antonio,

“-norm3diters“ are the iterations of mri_normalize, whereas “-nuiterations” 
refers to the number of cycles of mri_nu_correct.mni. I suppose they both work 
in v6. If not you can simply create a file with expert options.

Hope this helps!

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Antonio Algaze 
Beato
Gesendet: Donnerstag, 17. August 2017 19:08
An: freesurfer@nmr.mgh.harvard.edu
Betreff: [Freesurfer] -nuiterations and -norm3diters under FreeSurfer 6.0

Hi,

I have a question regarding -nuiterations and -norm3diters. I would like to get 
a feel for the options available for fine-tuning the intensity normalization in 
FreeSurfer 6.0.

I've seen mention of -nuiterations on some posts. Is this still an option in 
FreeSurfer 6.0?

The reason I ask is because under the "Expert Preferences" section of recon-all 
-help there's only mention of "-norm3diters". However, further down, under the 
second "Expert Preferences" section, there's a description of -nuiterations as 
well as -norm3diters.

Thanks!

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


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

Re: [Freesurfer] recon-all with multiple images with different voxel sizes

[Falk Lüsebrink]

Dear Gustav,


1.   If they have been acquired in the same session with the same protocol, 
you will increase your SNR by the square root of the number of volumes you use. 
This can potentially also help in case of minor motions artifacts. However, if 
your SNR is already high, it's probably better to stick to the better single 
volume, than to use an averaged volume.

2.   I think the general recommendation is to not mix protocols. If you 
want to use both scans you can conform them prior to using them as an input for 
recon-all, e.g. mri_convert -c  .

3.   If all images were acquired with the same protocol I would use the 
better volume and omit the other. Otherwise, I would stick to the volumes 
acquired with the same protocol.

The effect of intrasession averaging has for example been investigated here: 
https://www.ncbi.nlm.nih.gov/pubmed/23668971

"It can be seen how for several structures averaging does not change the 
relative power to the cross-sectional analysis (hippocampus, putamen, 
thalamus), for a few structures averaging increases errors (amygdala, right 
hemisphere entorhinal and pallidum) and for a few other structures averaging 
reduces errors (right hemisphere caudate, left hemisphere entorhinal)."

and

"In agreement with two multi-site 1.5 T reproducibility studies, one focused on 
cortical thickness reproducibility (Han et al., 2006) and one focused on 
subcortical, ventricular and intracranial volume reproducibility (Jovicich et 
al., 2009), we found that averaging two MPRAGE acquisitions acquired within a 
session made relatively minor contributions to improvement in the 
across-session reproducibility. The acquisition of two MPRAGE volumes is still 
recommended mainly for practical reasons: if one volume is bad (e.g. due to 
motion artifacts) then the other can still be used for segmentation without 
averaging."

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Gustav Mårtensson
Gesendet: Donnerstag, 17. August 2017 22:43
An: Freesurfer support list
Betreff: [Freesurfer] recon-all with multiple images with different voxel sizes


Hi!

We are processing images using

recon-all  -all -3T -mprage -qcache -hippocampal-subfields-T1 
-brainstem-structures

We've encountered an issue when we're trying to use multiple inputs (acquired 
at the same timepoint and with comparable quality). The issue is due to the two 
images having slightly different voxel sizes:

ERROR: MultiRegistration::

loadMovables: images have different voxel sizes.
  Currently not supported, maybe first make conform?
  Debug info: size(1) = 1, 1, 1.2   size(0) = 1.05469, 1.05469, 1.2
MultiRegistration::loadMovables: voxel size is different 
/tmp/adni/freesurfer/6.0.0/0a9cfea9-7668-4a2c-927c-378ff5109fe1/mri/orig/002.mgz.
which we can see confirm from the DICOMs in the PixelSpacing tag.

So, we have three questions:

1. In general, should using multiple images jointly for processing yield better 
results?
2. If so, what would you suggest for our case with images of two different 
protocols? Any flags that could help? Or perform coregistration pre-run?
3. Let's say we have a cohort where all subjects have two T1-images but where 
some subjects have two images acquired with slightly different protocols (e.g. 
different voxel sizes) and jointly processing can't be done. Do you think it is 
better to combine images in as many cases we can (and use only a single image 
for the remaining cases) or only use one image per case for all cases? In other 
words, we are wondering if it could bias our data set if the subset of that has 
been multi-image processed is "better" than those processed with only a single 
image.

We're running on FS6 (freesurfer-Linux-centos6_x86_
64-stable-pub-v6.0.0-2beb96c) and I've attached a log file from one of the 
failing cases.

Thank you for your help!

Best regards,

--
Gustav Mårtensson | PhD student
Division of Clinical Geriatrics
Department of Neurobiology, Care Sciences and Society
Karolinska Institutet
___
Karolinska Institutet - a medical university
___
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] QA tools for FS vs 6.0

[Falk Lüsebrink]

Dear Antonietta,

I don’t know of any official statement in that regard, however, Yong Li (CC’ed) 
seems to have updated the QA tools working with FS 6 in April. He may share his 
code.

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Antonietta Pepe
Gesendet: Mittwoch, 23. August 2017 16:47
An: freesurfer@nmr.mgh.harvard.edu
Betreff: [Freesurfer] QA tools for FS vs 6.0

Dear FreeSurfer list,

is any of you aware of a new version of the QA (quality assessment) tools 
 working for FS vs 6.0? 
Should I expect a new release in the near feature?



Kind regards,



Antonietta

ANTONIETTA PEPE
IMN, Institut des Maladies Neurodégénératives, UMR 5293
Equipe 5 : GIN, Groupe d’Imagerie Neurofonctionnelle, CEA - CNRS - Université 
de Bordeaux
Université de Bordeaux
146 rue Léo Saignat - CS 61292 - Case 28
33 076 Bordeaux cedex
http://www.imn-bordeaux.org/


___
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] R: mris_anatomical_stats output

[Falk Lüsebrink]

Hi Stefano,

never have done this myself, however, have you tried using the -f flag? The 
helps says this should output the stats to a tablefile.

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von 
std...@virgilio.it
Gesendet: Mittwoch, 30. August 2017 18:54
An: freesurfer@nmr.mgh.harvard.edu
Betreff: [Freesurfer] R: mris_anatomical_stats output

I have more that 5 clusters (from over 100 subjects, 12 different 
conditions). Manual extraction is impossible!
Any suggestions?
Thanks
Stefano
Messaggio originale
Da: std...@virgilio.it
Data: 19-ago-2017 2.38
A: mailto:freesurfer@nmr.mgh.harvard.edu>>
Ogg: [Freesurfer] mris_anatomical_stats output
Hi list,
how can I save the outputs of mris_anatomical_stats in xls file?
Thanks
Stefano


___
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] How would one run N4 bias corrected T1 and T2 images through FreeSurfer v6.0 REPOST

[Falk Lüsebrink]

Hi Eric,

I think the easiest way to avoid N3 is to simply add the -nonuintensitycor flag 
to recon-all and create a symbolic link from nu.mgz to orig.mgz it as otherwise 
recon-all will end with an error. I'm not sure about the nomenclature of the T2 
file, but you should do the same.

Best,
Falk


-Ursprüngliche Nachricht-
Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Bruce Fischl
Gesendet: Dienstag, 20. Februar 2018 17:17
An: Freesurfer support list
Betreff: Re: [Freesurfer] How would one run N4 bias corrected T1 and T2 images 
through FreeSurfer v6.0 REPOST

Hi Eric

the easiest thing would be to give your n4-corrected image to recon-all and let 
it run n3 on it. N3 is pretty gentle so I would think this would be fine. The 
alternative would be harder I think

cheers
Bruce


On Tue, 20 Feb 2018, Axelson, Eric D wrote:

> 
>  
> 
> We are using N4 to correct some large inhomogeneities in some samples 
> and wanted to insert these images into the v6.0 pipeline and bypass 
> the N3 bias correction done within.  What would be the correct 
> sequence of freesurfer commands to achieve this?  Thanks
> 
>  
> 
> Eric
> 
>  
> 
> 
> 
> __
> __
> Notice: This UI Health Care e-mail (including attachments) is covered 
> by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521 and 
> is intended only for the use of the individual or entity to which it 
> is addressed, and may contain information that is privileged, 
> confidential, and exempt from disclosure under applicable law. If you 
> are not the intended recipient, any dissemination, distribution or 
> copying of this communication is strictly prohibited. If you have 
> received this communication in error, please notify the sender immediately 
> and delete or destroy all copies of the original message and attachments 
> thereto. Email sent to or from UI Health Care may be retained as required by 
> law or regulation. 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] denoising and recon-all {Disarmed}

[Falk Lüsebrink]

External Email - Use Caution

Dear Lisa,

what you potentially can do is to use the denoised surface (*h.white) as a 
starting point (instead of *h.orig) in the unfiltered stream. This should 
remove any bias introduced by the denoising, however, you should gain the 
advantages of denoised surfaces, e.g. less need for manual intervention, less 
topological defects, etc.

I had a poster presentation for this method at last ISMRM.

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Lisa Crystal 
Krishnamurthy
Gesendet: Donnerstag, 11. Oktober 2018 19:07
An: Freesurfer support list 
Betreff: Re: [Freesurfer] denoising and recon-all {Disarmed}


External Email - Use Caution
The ONLM denoising algorithm in the following package: (MailScanner has 
detected a possible fraud attempt from "na01.safelinks.protection.outlook.com" 
claiming to be 
https://sites.google.com/site/pierrickcoupe/softwares/denoising-for-medical-imaging)

Best,
-Lisa

From: 
freesurfer-boun...@nmr.mgh.harvard.edu
 [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Glasser, Matthew
Sent: Thursday, October 11, 2018 12:39 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] denoising and recon-all


External Email - Use Caution
What are you using for denoising?

Matt.

From: 
mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
 on behalf of Lisa Crystal Krishnamurthy 
mailto:lkrishnamur...@gsu.edu>>
Reply-To: Freesurfer support list 
mailto:freesurfer@nmr.mgh.harvard.edu>>
Date: Thursday, October 11, 2018 at 11:05 AM
To: "freesurfer@nmr.mgh.harvard.edu" 
mailto:freesurfer@nmr.mgh.harvard.edu>>
Subject: [Freesurfer] denoising and recon-all


External Email - Use Caution
Hi,

I have found that denoising the MPRAGE prior to FS recon-all seems to improve 
the segmentation (see attached pdf). However, it is not clear if the denoising 
algorithm may cause some signal intensity changes (especially in voxels with 
partial voluming at the edge of the brain) that violate assumptions of 
recon-all. Could you help me understand what the assumptions of your algorithm 
are, and what I need to do to make sure my images conform to those assumptions?

Your help is greatly appreciated.
Best,
-Lisa


The materials in this message are private and may contain Protected Healthcare 
Information or other information of a sensitive nature. If you are not the 
intended recipient, be advised that any unauthorized use, disclosure, copying 
or the taking of any action in reliance on the contents of this information is 
strictly prohibited. If you have received this email in error, please 
immediately notify the sender via telephone or return mail.
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] denoising and recon-all {Disarmed}

[Falk Lüsebrink]

External Email - Use Caution

Dear Miguel,

sorry that I forgot to attach the link to the abstract. You can find it here: 
http://archive.ismrm.org/2018/2834.html

Best,
Falk


Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Miguel Ángel 
Rivas Fernández
Gesendet: Freitag, 12. Oktober 2018 14:18
An: Freesurfer support list 
Betreff: Re: [Freesurfer] denoising and recon-all {Disarmed}


External Email - Use Caution
Dear Falk,

I tried to search your poster presentation in the 2018 ISMRM web but 
unfortunately I did not find it. Can you attach the link? I would be interested 
in this information and how to proceed.

Thanks in advance,

Best,

El vie., 12 oct. 2018 a las 13:59, Falk Lüsebrink 
(mailto:falk.luesebr...@ovgu.de>>) escribió:

External Email - Use Caution
Dear Lisa,

what you potentially can do is to use the denoised surface (*h.white) as a 
starting point (instead of *h.orig) in the unfiltered stream. This should 
remove any bias introduced by the denoising, however, you should gain the 
advantages of denoised surfaces, e.g. less need for manual intervention, less 
topological defects, etc.

I had a poster presentation for this method at last ISMRM.

Best,
Falk

Von: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>]
 Im Auftrag von Lisa Crystal Krishnamurthy
Gesendet: Donnerstag, 11. Oktober 2018 19:07
An: Freesurfer support list 
mailto:freesurfer@nmr.mgh.harvard.edu>>
Betreff: Re: [Freesurfer] denoising and recon-all {Disarmed}


External Email - Use Caution
The ONLM denoising algorithm in the following package: (MailScanner has 
detected a possible fraud attempt from "na01.safelinks.protection.outlook.com" 
claiming to be 
https://sites.google.com/site/pierrickcoupe/softwares/denoising-for-medical-imaging<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsites.google.com%2Fsite%2Fpierrickcoupe%2Fsoftwares%2Fdenoising-for-medical-imaging&data=02%7C01%7Clkrishnamurthy%40gsu.edu%7Cadf6338b011843f3549d08d62f89e5d0%7C515ad73d8d5e4169895c9789dc742a70%7C0%7C0%7C63674876225518&sdata=F0mfd%2B63mdYPHplRq4jcjz9FuSvE2nUxMxqDlFfIZB4%3D&reserved=0>)

Best,
-Lisa

From: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Glasser, Matthew
Sent: Thursday, October 11, 2018 12:39 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] denoising and recon-all


External Email - Use Caution
What are you using for denoising?

Matt.

From: 
mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
 on behalf of Lisa Crystal Krishnamurthy 
mailto:lkrishnamur...@gsu.edu>>
Reply-To: Freesurfer support list 
mailto:freesurfer@nmr.mgh.harvard.edu>>
Date: Thursday, October 11, 2018 at 11:05 AM
To: "freesurfer@nmr.mgh.harvard.edu<mailto:freesurfer@nmr.mgh.harvard.edu>" 
mailto:freesurfer@nmr.mgh.harvard.edu>>
Subject: [Freesurfer] denoising and recon-all


External Email - Use Caution
Hi,

I have found that denoising the MPRAGE prior to FS recon-all seems to improve 
the segmentation (see attached pdf). However, it is not clear if the denoising 
algorithm may cause some signal intensity changes (especially in voxels with 
partial voluming at the edge of the brain) that violate assumptions of 
recon-all. Could you help me understand what the assumptions of your algorithm 
are, and what I need to do to make sure my images conform to those assumptions?

Your help is greatly appreciated.
Best,
-Lisa


The materials in this message are private and may contain Protected Healthcare 
Information or other information of a sensitive nature. If you are not the 
intended recipient, be advised that any unauthorized use, disclosure, copying 
or the taking of any action in reliance on the contents of this information is 
strictly prohibited. If you have received this email in error, please 
immediately notify the sender via telephone or return mail.
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu>
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


--
Miguel Ángel Rivas Fernández
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] autorecon1 with skull stripped image

[Falk Lüsebrink]

External Email - Use Caution

Dear Rosalia,

I’d suggest you run recon-all –autorecon1 with you native data. Then you use 
mri_mask to mask the T1.mgz with your skull stripped volume to get your desired 
skull stripping. Name the result brainmask.mgz and continue with recon-all 
–autorecon2 –autorecon3.

Remember that FreeSurfer requires to have the cerebellum attached to the brain. 
Also inputting the already skull stripped volume in autorecon1 may fail during 
talairach registration and potentially cause errors during skull stripping (if 
not skipped anyways).

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Rosalia Dacosta 
Aguayo
Gesendet: Donnerstag, 18. Oktober 2018 06:30
An: Freesurfer support list 
Betreff: [Freesurfer] autorecon1 with skull stripped image


External Email - Use Caution
Dear Free Surfer's team,

I have a doubt. I have a sample of patients in which I already have done the 
skull stripping using specific options with bet, so the skull stripping has 
been successful. I wonder if I could feed autorecon1 with the skull stripped 
image instead of the T1 image with skull.
Thank you very much for your time,
Rosalia
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Ask for your help about freesurfer submillimeter reconstruction!

[Falk Lüsebrink]

External Email - Use Caution

Dear Rui,

there is no hard limit to resolution. Your data should have a decent quality 
(no motion artifacts, high SNR, high contrast, isotropic resolution) and the 
suggestions of the submillimeter reconstruction should give good results. I 
have run FreeSurfer on 250 µm human data with reasonable, but improvable 
results. Still working on it.

>From my experience skull stripping seems to fail using data with higher 
>resolution than 0.7 mm. Therefore, I suggest you to follow the first steps of 
>the guideline: https://surfer.nmr.mgh.harvard.edu/fswiki/HiResRecon to create 
>a low resolution brainmask, upsampling, and applying it on your high 
>resolution data. Apart from that everything should run smoothly.

Expect it to run for a few weeks, especially the topological fixation and 
autorecon3 will take time.

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Nian Rui
Gesendet: Donnerstag, 18. Oktober 2018 00:50
An: freesurfer@nmr.mgh.harvard.edu
Betreff: [Freesurfer] Ask for your help about freesurfer submillimeter 
reconstruction!
Priorität: Hoch


External Email - Use Caution
Dear FreeSurfer Developers,


I am now working on the analysis of MRI images with the voxel resolution less 
than 0.2mm3.
I read your webpage about submillimeter reconstruction, 
https://urldefense.proofpoint.com/v2/url?u=https-3A__surfer.nmr.mgh.harvard.edu_fswiki_SubmillimeterRecon&d=DwIFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=NtVAAoNRuurWjiGc9gF6zmjCj-yhJX2FiqIQWantaTc&m=HTIr5eeTbJbG9K4SRzOVI_oGR2mBLs0SJ7kNktw_Jls&s=G5pESXnip5oTcvgA30e0qjSVsAcnKGo1DekVAyP1VaY&e=,
 which said Freesurfer 6.0 works well for voxel sizes 0.75 mm3, and inputs with 
0.5 mm3 voxels or below will have a brainmask failure (we are working on it!).
So I am writing to ask for your help about the reconstruction with freesurfer.
I would like to know, have you solved the higher resolution problem in the new 
version v6.0?
Could I use it to analyze the cortical thickness of these MRI images now?
If not, is there any other way to help processing these MRI images and we could 
run freesurfer step by step for evaluation?
Look forward to your timely help!
Thanks a lot in advance!
yours sincerely,
Rui
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] autorecon1 with skull stripped image

[Falk Lüsebrink]

External Email - Use Caution

Dear Rosalina,

yes, it is. FreeSurfer can handle all formats given in the help of mri_convert.

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Rosalia Dacosta 
Aguayo
Gesendet: Donnerstag, 18. Oktober 2018 08:48
An: Freesurfer support list 
Betreff: Re: [Freesurfer] autorecon1 with skull stripped image


External Email - Use Caution
Dear Falk,

Thank you very much for your explanation. One more thing: nii.gz format is also 
good for FreeSurfer, right?

Best regards,
Rosalia


El jue., 18 oct. 2018 8:26, Falk Lüsebrink 
mailto:falk.luesebr...@ovgu.de>> escribió:

External Email - Use Caution
Dear Rosalia,

I’d suggest you run recon-all –autorecon1 with you native data. Then you use 
mri_mask to mask the T1.mgz with your skull stripped volume to get your desired 
skull stripping. Name the result brainmask.mgz and continue with recon-all 
–autorecon2 –autorecon3.

Remember that FreeSurfer requires to have the cerebellum attached to the brain. 
Also inputting the already skull stripped volume in autorecon1 may fail during 
talairach registration and potentially cause errors during skull stripping (if 
not skipped anyways).

Best,
Falk

Von: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>]
 Im Auftrag von Rosalia Dacosta Aguayo
Gesendet: Donnerstag, 18. Oktober 2018 06:30
An: Freesurfer support list 
mailto:freesurfer@nmr.mgh.harvard.edu>>
Betreff: [Freesurfer] autorecon1 with skull stripped image


External Email - Use Caution
Dear Free Surfer's team,

I have a doubt. I have a sample of patients in which I already have done the 
skull stripping using specific options with bet, so the skull stripping has 
been successful. I wonder if I could feed autorecon1 with the skull stripped 
image instead of the T1 image with skull.
Thank you very much for your time,
Rosalia
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu<mailto: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] Problems to run -autorecon2

[Falk Lüsebrink]

External Email - Use Caution

Dear Rosalina,

you should run recon-all -sd ~/Desktop/MS_STUDY/subjects -s 001 -autorecon2 and 
everything will run nicely. You should not include the -i flag again if you 
want to continue processing your data, as this flag tells FreeSurfer to create 
a new subject folder (which already exists and therefore give an error).

Best,
Falk


Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Rosalia Dacosta 
Aguayo
Gesendet: Freitag, 19. Oktober 2018 11:11
An: Freesurfer support list 
Betreff: [Freesurfer] Problems to run -autorecon2


External Email - Use Caution
Dear FreeSurfer team,

I am trying to run recon -all -autorecon2 using the following command line:  
recon-all -sd ~/Desktop/MS_STUDY/subjects -s 001 -i 
/home/rosalia/Desktop/MS_STUDY/subjects/001 -autorecon2

 It is the same command I used yesterday to run -autorecon1 without problems. 
However, maybe now it is different. Should I point to another sub folder? I do 
not know which -i I should point out now. My directory for this subject is as 
follows:
rosalia@rosalia-Lenovo-Y520-15IKBN ~/Desktop/MS_STUDY/subjects/001/mri $ ls
brainmask.auto.mgz  nu.mgz   rawavg.mgz
brainmask.mgz   orig T1.mgz
mri_nu_correct.mni.log  orig.mgz talairach_with_skull.log
mri_nu_correct.mni.log.bak  orig_nu.mgz  transforms
rosalia@rosalia-Lenovo-Y520-15IKBN ~/Desktop/MS_STUDY/subjects/001/mri $
Best regards,
Rosalia


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

Re: [Freesurfer] Problems to run -autorecon2

[Falk Lüsebrink]

External Email - Use Caution

Dear Rosalia,

You can specify all flags in every call of recon-all. If this flags does not 
change any commands, they will simply be ignored.

In your case, to first run autorecon1, overwrite the brainmask and continue 
with autorecon2 and 3, you can do the following:

1.  Run ‘recon-all -autorecon1 -i  -s  -qcache 
-openmp 8’

2.  Delete brainmaskmgz and use your brain mask created in BET with 
mri_mask on the T1.mgz and name the output brainmask.mgz

3.  Run ‘recon-all -autorecon2 -autorecon3 -s  -qcache 
-openmp 8’


Best,
Falk



Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Rosalia Dacosta 
Aguayo
Gesendet: Freitag, 19. Oktober 2018 14:10
An: Freesurfer support list 
Betreff: Re: [Freesurfer] Problems to run -autorecon2


External Email - Use Caution
Dear Falk,

Thank you very much for your email and explanation. It is working now.
I wonder how I could set the smoothing for autorecon3 as to run recon -all -all 
I had the options: -qcache -openmp 8

Kind regards,
Rosalia


On Fri, Oct 19, 2018 at 2:06 PM Falk Lüsebrink 
mailto:falk.luesebr...@ovgu.de>> wrote:

External Email - Use Caution
Dear Rosalina,

you should run recon-all -sd ~/Desktop/MS_STUDY/subjects -s 001 -autorecon2 and 
everything will run nicely. You should not include the -i flag again if you 
want to continue processing your data, as this flag tells FreeSurfer to create 
a new subject folder (which already exists and therefore give an error).

Best,
Falk


Von: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>]
 Im Auftrag von Rosalia Dacosta Aguayo
Gesendet: Freitag, 19. Oktober 2018 11:11
An: Freesurfer support list 
mailto:freesurfer@nmr.mgh.harvard.edu>>
Betreff: [Freesurfer] Problems to run -autorecon2


External Email - Use Caution
Dear FreeSurfer team,

I am trying to run recon -all -autorecon2 using the following command line:  
recon-all -sd ~/Desktop/MS_STUDY/subjects -s 001 -i 
/home/rosalia/Desktop/MS_STUDY/subjects/001 -autorecon2

 It is the same command I used yesterday to run -autorecon1 without problems. 
However, maybe now it is different. Should I point to another sub folder? I do 
not know which -i I should point out now. My directory for this subject is as 
follows:
rosalia@rosalia-Lenovo-Y520-15IKBN ~/Desktop/MS_STUDY/subjects/001/mri $ ls
brainmask.auto.mgz  nu.mgz   rawavg.mgz
brainmask.mgz   orig T1.mgz
mri_nu_correct.mni.log  orig.mgz talairach_with_skull.log
mri_nu_correct.mni.log.bak  orig_nu.mgz  transforms
rosalia@rosalia-Lenovo-Y520-15IKBN ~/Desktop/MS_STUDY/subjects/001/mri $
Best regards,
Rosalia


___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu<mailto: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] Problems to run -autorecon2

[Falk Lüsebrink]

External Email - Use Caution

Dear Rosalia,

When you use the openmp flag, you should make sure to use it always in the same 
for all subjects in your study, as otherwise you may introduce a bias (in your 
case either use it for autorecon1, autorecon2, and autorecon3 or use it for 
autorecon2 and autorecon3 only). With regards to the qcache flag, it is of no 
concern, as it does not affect anything in autorecon1 (as far as I know).

Best,
Falk

Von: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Rosalia Dacosta 
Aguayo
Gesendet: Freitag, 19. Oktober 2018 14:40
An: Freesurfer support list 
Betreff: Re: [Freesurfer] Problems to run -autorecon2


External Email - Use Caution
Dear Falk,

Thank you very much.
Once last question: what would happen if I did run -autorecon1 without the 
flags: -qcache -openmp 8’ and I use them in autorecon2 or 3?

Best regards,
Rosalia

On Fri, Oct 19, 2018 at 2:34 PM Falk Lüsebrink 
mailto:falk.luesebr...@ovgu.de>> wrote:

External Email - Use Caution
Dear Rosalia,

You can specify all flags in every call of recon-all. If this flags does not 
change any commands, they will simply be ignored.

In your case, to first run autorecon1, overwrite the brainmask and continue 
with autorecon2 and 3, you can do the following:

1.  Run ‘recon-all -autorecon1 -i  -s  -qcache 
-openmp 8’

2.  Delete brainmaskmgz and use your brain mask created in BET with 
mri_mask on the T1.mgz and name the output brainmask.mgz

3.  Run ‘recon-all -autorecon2 -autorecon3 -s  -qcache 
-openmp 8’


Best,
Falk



Von: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>]
 Im Auftrag von Rosalia Dacosta Aguayo
Gesendet: Freitag, 19. Oktober 2018 14:10
An: Freesurfer support list 
mailto:freesurfer@nmr.mgh.harvard.edu>>
Betreff: Re: [Freesurfer] Problems to run -autorecon2


External Email - Use Caution
Dear Falk,

Thank you very much for your email and explanation. It is working now.
I wonder how I could set the smoothing for autorecon3 as to run recon -all -all 
I had the options: -qcache -openmp 8

Kind regards,
Rosalia


On Fri, Oct 19, 2018 at 2:06 PM Falk Lüsebrink 
mailto:falk.luesebr...@ovgu.de>> wrote:

External Email - Use Caution
Dear Rosalina,

you should run recon-all -sd ~/Desktop/MS_STUDY/subjects -s 001 -autorecon2 and 
everything will run nicely. You should not include the -i flag again if you 
want to continue processing your data, as this flag tells FreeSurfer to create 
a new subject folder (which already exists and therefore give an error).

Best,
Falk


Von: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>]
 Im Auftrag von Rosalia Dacosta Aguayo
Gesendet: Freitag, 19. Oktober 2018 11:11
An: Freesurfer support list 
mailto:freesurfer@nmr.mgh.harvard.edu>>
Betreff: [Freesurfer] Problems to run -autorecon2


External Email - Use Caution
Dear FreeSurfer team,

I am trying to run recon -all -autorecon2 using the following command line:  
recon-all -sd ~/Desktop/MS_STUDY/subjects -s 001 -i 
/home/rosalia/Desktop/MS_STUDY/subjects/001 -autorecon2

 It is the same command I used yesterday to run -autorecon1 without problems. 
However, maybe now it is different. Should I point to another sub folder? I do 
not know which -i I should point out now. My directory for this subject is as 
follows:
rosalia@rosalia-Lenovo-Y520-15IKBN ~/Desktop/MS_STUDY/subjects/001/mri $ ls
brainmask.auto.mgz  nu.mgz   rawavg.mgz
brainmask.mgz   orig T1.mgz
mri_nu_correct.mni.log  orig.mgz talairach_with_skull.log
mri_nu_correct.mni.log.bak  orig_nu.mgz  transforms
rosalia@rosalia-Lenovo-Y520-15IKBN ~/Desktop/MS_STUDY/subjects/001/mri $
Best regards,
Rosalia


___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu>
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu<mailto: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] Voxel size smaller than 1x1x1mm?

[Falk Lüsebrink]

Hi Freesurfers,

I'm currently doing my bachelors thesis in medical engineering and I'm
trying to measure the cortical thickness of scans acquired by a 7T MRT.
 
A colleague of mine has used Freesurfer (v4.0.5) before and mentioned that
high resolution scans with a voxel size smaller than 1x1x1mm (like
.7x.7x.7mm) are converted to 1x1x1mm during a processing stage of autorecon
- I think during the mri_convert process.

Is it possible to keep the native size or does Freesurfer need to change the
voxel size to 1mm in order to do the segmentation correctly?

Regards,
Falk

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

RE: [Freesurfer] Voxel size smaller than 1x1x1mm?

[Falk Lüsebrink]

Hi again,

so I did use the -cm flag to conform the voxels to its minimum size of .8mm
iso (which is also the native size of my data set) during the mri_convert
process and used the -noconform flag for the mri_normalize stage during
autorecon1 to prevent further conformation to 1mm.

But now recon-all exits with an error at stage 12
(http://surfer.nmr.mgh.harvard.edu/fswiki/recon-all). The error message I
got is as follows:
#
 #...@# Intensity Normalization2 Wed Mar 11 08:38:44 CET 2009 
 /home/falk/freesurfer/subjects/claus/mri

 mri_normalize -f home/falk/freesurfer/subjects/claus/tmp/control.dat 
 -noconform -aseg aseg.mgz -mask brainmask.mgz norm.mgz brain.mgz

 using control points from file
/home/falk/freesurfer/subjects/claus/tmp/control.dat...
 not interpolating and embedding volume to be 256^3...
 using segmentation for initial intensity normalization reading from 
 norm.mgz...
 mri_normalize: aseg volume aseg.mgz must be conformed using MR volume 
 brainmask.mgz to mask input volume...
 Linux xx 2.6.26-1-amd64 #1 SMP Mon Dec 15 17:25:36 UTC 2008 
 x86_64 GNU/Linux

 recon-all exited with ERRORS at Wed Mar 11 08:38:55 CET 2009
-

Does anyone know what to do?

Regards,
Falk


-Original Message-
From: Bruce Fischl [mailto:fis...@nmr.mgh.harvard.edu] 
Sent: Friday, March 06, 2009 1:26 PM
To: Falk Lüsebrink
Cc: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] Voxel size smaller than 1x1x1mm?

Hi Falk,

yes, you can use the "conform to min" (-cm I think) switch in recon-all. 
Can you cover the whole brain at .7mm iso? That's hard. And 7T is hard 
for whole brain morphometry because of dielectric effects. Good luck.

Bruce
On 
Fri, 6 Mar 2009, Falk Lüsebrink wrote:

> Hi Freesurfers,
>
> I'm currently doing my bachelors thesis in medical engineering and I'm
> trying to measure the cortical thickness of scans acquired by a 7T MRT.
>
> A colleague of mine has used Freesurfer (v4.0.5) before and mentioned that
> high resolution scans with a voxel size smaller than 1x1x1mm (like
> .7x.7x.7mm) are converted to 1x1x1mm during a processing stage of
autorecon
> - I think during the mri_convert process.
>
> Is it possible to keep the native size or does Freesurfer need to change
the
> voxel size to 1mm in order to do the segmentation correctly?
>
> Regards,
> Falk
>
> ___
> 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: RE: [Freesurfer] Voxel size smaller than 1x1x1mm?

[Falk Lüsebrink]

Hi Nick,

yes I have been trying to use the -noaseg flag, but as recon-all did exit with 
an error I thought this process might be needed, so I haven't tried anything 
else.

The error message I received was:

#
#...@# WM Segmentation Wed Mar 18 10:14:42 CET 2009

 cp wm.mgz wm.seg.mgz 


 mri_segment -keep brain.mgz wm.seg.mgz 

preserving editing changes in output volume...
doing initial intensity segmentation...
using local statistics to label ambiguous voxels...
computing class statistics for intensity windows...
WM (106.0): 106.9 +- 5.8 [80.0 --> 125.0]
GM (69.0) : 66.3 +- 11.6 [30.0 --> 96.0]
setting bottom of white matter range to 77.9
setting top of gray matter range to 89.4
doing initial intensity segmentation...
using local statistics to label ambiguous voxels...
using local geometry to label remaining ambiguous voxels...

reclassifying voxels using Gaussian border classifier...

removing voxels with positive offset direction...
smoothing T1 volume with sigma = 0.250
removing 1-dimensional structures...
thickening thin strands
20 segments, 4813 filled
10270 bright non-wm voxels segmented.
5589 diagonally connected voxels added...
white matter segmentation took 2.4 minutes
writing output to wm.seg.mgz...
ERROR: mri_segment-MRIcheckVolDims: volume1 height=256 != volume2 height=320.

Regards,
Falk


 Original-Nachricht 
> Datum: Sat, 21 Mar 2009 10:08:24 +0100
> Von: "Falk Lüsebrink" 
> An: falk.lu...@gmx.net
> Betreff: RE: [Freesurfer] Voxel size smaller than 1x1x1mm?

> Falk,
> 
> Probably you should try adding the -noaseg flag to recon-all, as the
> aseg step relies on having 'conformed' volume data to register to the
> atlas.  The -noaseg flag skips creation and usage of the subcortical
> atlas.
> 
> Nick
> 
> 
> On Wed, 2009-03-11 at 13:16 +0100, Falk Lüsebrink wrote:
> > Hi again,
> > 
> > so I did use the -cm flag to conform the voxels to its minimum size of
> .8mm
> > iso (which is also the native size of my data set) during the
> mri_convert
> > process and used the -noconform flag for the mri_normalize stage during
> > autorecon1 to prevent further conformation to 1mm.
> > 
> > But now recon-all exits with an error at stage 12
> > (http://surfer.nmr.mgh.harvard.edu/fswiki/recon-all). The error message
> I
> > got is as follows:
> > #
> >  #...@# Intensity Normalization2 Wed Mar 11 08:38:44 CET 2009 
> >  /home/falk/freesurfer/subjects/claus/mri
> > 
> >  mri_normalize -f home/falk/freesurfer/subjects/claus/tmp/control.dat 
> >  -noconform -aseg aseg.mgz -mask brainmask.mgz norm.mgz brain.mgz
> > 
> >  using control points from file
> > /home/falk/freesurfer/subjects/claus/tmp/control.dat...
> >  not interpolating and embedding volume to be 256^3...
> >  using segmentation for initial intensity normalization reading from 
> >  norm.mgz...
> >  mri_normalize: aseg volume aseg.mgz must be conformed using MR volume 
> >  brainmask.mgz to mask input volume...
> >  Linux xx 2.6.26-1-amd64 #1 SMP Mon Dec 15 17:25:36 UTC 2008 
> >  x86_64 GNU/Linux
> > 
> >  recon-all exited with ERRORS at Wed Mar 11 08:38:55 CET 2009
> > -----
> > 
> > Does anyone know what to do?
> > 
> > Regards,
> > Falk
> > 
> > 
> > -Original Message-
> > From: Bruce Fischl [mailto:fis...@nmr.mgh.harvard.edu] 
> > Sent: Friday, March 06, 2009 1:26 PM
> > To: Falk Lüsebrink
> > Cc: freesurfer@nmr.mgh.harvard.edu
> > Subject: Re: [Freesurfer] Voxel size smaller than 1x1x1mm?
> > 
> > Hi Falk,
> > 
> > yes, you can use the "conform to min" (-cm I think) switch in recon-all.
> > Can you cover the whole brain at .7mm iso? That's hard. And 7T is hard 
> > for whole brain morphometry because of dielectric effects. Good luck.
> > 
> > Bruce
> > On 
> > Fri, 6 Mar 2009, Falk Lüsebrink wrote:
> > 
> > > Hi Freesurfers,
> > >
> > > I'm currently doing my bachelors thesis in medical engineering and I'm
> > > trying to measure the cortical thickness of scans acquired by a 7T
> MRT.
> > >
> > > A colleague of mine has used Freesurfer (v4.0.5) before and mentioned
> that
> > > high resolution scans with a voxel size smaller than 1x1x1mm (like
> > > .7x.7x.7mm) are converted to 1x1x1mm during a processing stage of
> > autorecon
> > > - I think during the mri_convert process.
> > >
> > > Is it possible to keep the native size or do

[Freesurfer] Measuring cortical thickness with high resolution data

[Falk Lüsebrink]

Hi Freesurfers,

 

I’m trying to evaluate the usefulness of high resolution scans acquired at
7T with an isometric voxel size of .6mm for the measurement of cortical
thickness. The inhomogeneities are taken care of by dividing the scans with
another scan of another sequence, so they are not an issue anymore.

 

My problem is that Freesurfer usually conforms the voxel size to 1mm which
is not desirable. I tried using the –cm and –noaseg flags for the recon-all
process to avoid the conformation and to skip the subcortical segmentation,
but another problem arises while using these flags.

 

The error I receive is occurring after the WM Segmentation and states as
follows:

 

#

#...@# WM Segmentation Wed Mar 18 10:14:42 CET 2009

 

 cp wm.mgz wm.seg.mgz 

 

 

 mri_segment -keep brain.mgz wm.seg.mgz 

 

preserving editing changes in output volume...

doing initial intensity segmentation...

using local statistics to label ambiguous voxels...

computing class statistics for intensity windows...

WM (106.0): 106.9 +- 5.8 [80.0 --> 125.0]

GM (69.0) : 66.3 +- 11.6 [30.0 --> 96.0]

setting bottom of white matter range to 77.9

setting top of gray matter range to 89.4

doing initial intensity segmentation...

using local statistics to label ambiguous voxels...

using local geometry to label remaining ambiguous voxels...

 

reclassifying voxels using Gaussian border classifier...

 

removing voxels with positive offset direction...

smoothing T1 volume with sigma = 0.250

removing 1-dimensional structures...

thickening thin strands

20 segments, 4813 filled

10270 bright non-wm voxels segmented.

5589 diagonally connected voxels added...

white matter segmentation took 2.4 minutes

writing output to wm.seg.mgz...

ERROR: mri_segment-MRIcheckVolDims: volume1 height=256 != volume2
height=320.

 

The dimensions of the data I’m trying to process is 320 x 320 x 224 and is
changed to 320 x 320 x 320 while using the –cm flag. It seems the
mri_segment process can’t handle any dimensions above 256 or I’m missing
another flag.

 

Does someone has any ideas about that issue?

 

Regards,

Falk

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

RE: [Freesurfer] Measuring cortical thickness with high resolution data

[Falk Lüsebrink]

Hi Nick,

Thank you very much. I'll have to look into that and try to process some other 
volumes which might work a bit better, with less manual intervention.

Are there any plans to improve Freesurfer in the (near) future so that hires 
data can be processed within the currently available stream?

Regards,
Falk

-Original Message-
From: Nick Schmansky [mailto:ni...@nmr.mgh.harvard.edu] 
Sent: Wednesday, April 01, 2009 7:53 PM
To: Falk Lüsebrink
Cc: Freesurfer Mailing List
Subject: Re: [Freesurfer] Measuring cortical thickness with high resolution data

Falk,

Attached is a modified recon-all script where I've added a -hires switch to 
force the stream to not conform the data to 1mm^3, and to not use the atlases.

Note that you should add the -clean flag to delete any work that had been done 
prior (namely, -clean deletes brainmask.mgz, aseg.mgz and wm.mgz).

However, in working with the .8mm data that you sent me, working with hires 
data will require quite a bit of manual intervention due to the fact that the 
atlases normally used cannot be used.  The first problem occurs in 
skull-stripping, where quite a bit of dura and skull remains, and seems to have 
intensity values close to gray matter.  This would have to be manually erased 
on each of the slices.  If it is not erased (I did not do this because of the 
amount of time required), then the wm.mgz file, which is what is tessellated to 
create the initial surface, will be very wrong (it tessellates the garbage 
surrounding the gray matter).

See also Bruce's prior posting on the problems of working with hires data in 
freesurfer.

Nick


On Wed, 2009-03-25 at 13:04 +0100, Falk Lüsebrink wrote:
> Hi Freesurfers,
> 
>  
> 
> I’m trying to evaluate the usefulness of high resolution scans 
> acquired at 7T with an isometric voxel size of .6mm for the 
> measurement of cortical thickness. The inhomogeneities are taken care 
> of by dividing the scans with another scan of another sequence, so 
> they are not an issue anymore.
> 
>  
> 
> My problem is that Freesurfer usually conforms the voxel size to 1mm 
> which is not desirable. I tried using the –cm and –noaseg flags for 
> the recon-all process to avoid the conformation and to skip the 
> subcortical segmentation, but another problem arises while using these 
> flags.
> 
>  
> 
> The error I receive is occurring after the WM Segmentation and states 
> as follows:
> 
>  
> 
> #
> 
> #...@# WM Segmentation Wed Mar 18 10:14:42 CET 2009
> 
>  
> 
>  cp wm.mgz wm.seg.mgz
> 
>  
> 
>  
> 
>  mri_segment -keep brain.mgz wm.seg.mgz
> 
>  
> 
> preserving editing changes in output volume...
> 
> doing initial intensity segmentation...
> 
> using local statistics to label ambiguous voxels...
> 
> computing class statistics for intensity windows...
> 
> WM (106.0): 106.9 +- 5.8 [80.0 --> 125.0]
> 
> GM (69.0) : 66.3 +- 11.6 [30.0 --> 96.0]
> 
> setting bottom of white matter range to 77.9
> 
> setting top of gray matter range to 89.4
> 
> doing initial intensity segmentation...
> 
> using local statistics to label ambiguous voxels...
> 
> using local geometry to label remaining ambiguous voxels...
> 
>  
> 
> reclassifying voxels using Gaussian border classifier...
> 
>  
> 
> removing voxels with positive offset direction...
> 
> smoothing T1 volume with sigma = 0.250
> 
> removing 1-dimensional structures...
> 
> thickening thin strands
> 
> 20 segments, 4813 filled
> 
> 10270 bright non-wm voxels segmented.
> 
> 5589 diagonally connected voxels added...
> 
> white matter segmentation took 2.4 minutes
> 
> writing output to wm.seg.mgz...
> 
> ERROR: mri_segment-MRIcheckVolDims: volume1 height=256 != volume2 
> height=320.
> 
>  
> 
> The dimensions of the data I’m trying to process is 320 x 320 x 224 
> and is changed to 320 x 320 x 320 while using the –cm flag. It seems 
> the mri_segment process can’t handle any dimensions above 256 or I’m 
> missing another flag.
> 
>  
> 
> Does someone has any ideas about that issue?
> 
>  
> 
> Regards,
> 
> Falk
> 
> 
> ___
> 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] Measuring cortical thickness with high resolution data

[Falk Lüsebrink]

Hi Nick,

I tried using your modified recon-all today but as soon as I try to process any 
data I receive following error message:

'nknown option: `-
Usage: tcsh [ -bcdefilmnqstvVxX ] [argument ...].

Also it doesn't matter at all which flags I add to recon-all or if I don't use 
any flags at all, the error is the same. The unmodified recon-all performs well.

Regards,
Falk

-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Nick Schmansky
Sent: Thursday, April 02, 2009 3:28 PM
To: Falk Lüsebrink
Cc: Freesurfer Mailing List
Subject: RE: [Freesurfer] Measuring cortical thickness with high resolution data

Falk,

There are no plans in the near future, but in the long term we'd like to remove 
the dependence on conforming the data.

It just occurred to me that you could have the best of both worlds:
first run your data through the normal stream (conforming) up through 
autorecon1, then use mri_vol2vol to create a brainmask.mgz at the same 
resolution as that created using the -hires stream, and copy it over.
At least that would eliminate having to edit the original hires brainmask, 
which would save hours of work.  If i get few minutes i will try this.

You can copy that recon-all over top your existing v4.x freesurfer installation 
(attached again for the list).

Nick


On Thu, 2009-04-02 at 10:58 +0200, Falk Lüsebrink wrote:
> Hi Nick,
> 
> Thank you very much. I'll have to look into that and try to process some 
> other volumes which might work a bit better, with less manual intervention.
> 
> Are there any plans to improve Freesurfer in the (near) future so that hires 
> data can be processed within the currently available stream?
> 
> Regards,
> Falk
> 
> -Original Message-
> From: Nick Schmansky [mailto:ni...@nmr.mgh.harvard.edu]
> Sent: Wednesday, April 01, 2009 7:53 PM
> To: Falk Lüsebrink
> Cc: Freesurfer Mailing List
> Subject: Re: [Freesurfer] Measuring cortical thickness with high 
> resolution data
> 
> Falk,
> 
> Attached is a modified recon-all script where I've added a -hires switch to 
> force the stream to not conform the data to 1mm^3, and to not use the atlases.
> 
> Note that you should add the -clean flag to delete any work that had been 
> done prior (namely, -clean deletes brainmask.mgz, aseg.mgz and wm.mgz).
> 
> However, in working with the .8mm data that you sent me, working with hires 
> data will require quite a bit of manual intervention due to the fact that the 
> atlases normally used cannot be used.  The first problem occurs in 
> skull-stripping, where quite a bit of dura and skull remains, and seems to 
> have intensity values close to gray matter.  This would have to be manually 
> erased on each of the slices.  If it is not erased (I did not do this because 
> of the amount of time required), then the wm.mgz file, which is what is 
> tessellated to create the initial surface, will be very wrong (it tessellates 
> the garbage surrounding the gray matter).
> 
> See also Bruce's prior posting on the problems of working with hires data in 
> freesurfer.
> 
> Nick
> 
> 
> On Wed, 2009-03-25 at 13:04 +0100, Falk Lüsebrink wrote:
> > Hi Freesurfers,
> > 
> >  
> > 
> > I’m trying to evaluate the usefulness of high resolution scans 
> > acquired at 7T with an isometric voxel size of .6mm for the 
> > measurement of cortical thickness. The inhomogeneities are taken 
> > care of by dividing the scans with another scan of another sequence, 
> > so they are not an issue anymore.
> > 
> >  
> > 
> > My problem is that Freesurfer usually conforms the voxel size to 1mm 
> > which is not desirable. I tried using the –cm and –noaseg flags for 
> > the recon-all process to avoid the conformation and to skip the 
> > subcortical segmentation, but another problem arises while using 
> > these flags.
> > 
> >  
> > 
> > The error I receive is occurring after the WM Segmentation and 
> > states as follows:
> > 
> >  
> > 
> > #
> > 
> > #...@# WM Segmentation Wed Mar 18 10:14:42 CET 2009
> > 
> >  
> > 
> >  cp wm.mgz wm.seg.mgz
> > 
> >  
> > 
> >  
> > 
> >  mri_segment -keep brain.mgz wm.seg.mgz
> > 
> >  
> > 
> > preserving editing changes in output volume...
> > 
> > doing initial intensity segmentation...
> > 
> > using local statistics to label ambiguous voxels...
> > 
> > computing class statistics for intensity windows...
> > 
> > WM (106.0): 106.9 +- 5.8 [80.0 --> 125.0]
> &

RE: [Freesurfer] Measuring cortical thickness with high resolution data

[Falk Lüsebrink]

Hi Doug,

Thanks! Now recon-all is processing well.

Regards,
Falk

-Original Message-
From: Doug Greve [mailto:gr...@nmr.mgh.harvard.edu] 
Sent: Monday, April 06, 2009 6:25 PM
To: Falk Lüsebrink
Cc: 'Nick Schmansky'; freesurfer@nmr.mgh.harvard.edu
Subject: RE: [Freesurfer] Measuring cortical thickness with high resolution
data


Falk,  it looks like that file was somehow converted to DOS. try:

dos2unix recon-all
chmod a+x recon-all

then re-run

doug


On Mon, 6 Apr 2009, Falk Lüsebrink wrote:

> Hi Nick,
>
> I tried using your modified recon-all today but as soon as I try to
process any data I receive following error message:
>
> 'nknown option: `-
> Usage: tcsh [ -bcdefilmnqstvVxX ] [argument ...].
>
> Also it doesn't matter at all which flags I add to recon-all or if I don't
use any flags at all, the error is the same. The unmodified recon-all
performs well.
>
> Regards,
> Falk
>
> -Original Message-
> From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Nick Schmansky
> Sent: Thursday, April 02, 2009 3:28 PM
> To: Falk Lüsebrink
> Cc: Freesurfer Mailing List
> Subject: RE: [Freesurfer] Measuring cortical thickness with high
resolution data
>
> Falk,
>
> There are no plans in the near future, but in the long term we'd like to
remove the dependence on conforming the data.
>
> It just occurred to me that you could have the best of both worlds:
> first run your data through the normal stream (conforming) up through
autorecon1, then use mri_vol2vol to create a brainmask.mgz at the same
resolution as that created using the -hires stream, and copy it over.
> At least that would eliminate having to edit the original hires brainmask,
which would save hours of work.  If i get few minutes i will try this.
>
> You can copy that recon-all over top your existing v4.x freesurfer
installation (attached again for the list).
>
> Nick
>
>
> On Thu, 2009-04-02 at 10:58 +0200, Falk Lüsebrink wrote:
>> Hi Nick,
>>
>> Thank you very much. I'll have to look into that and try to process some
other volumes which might work a bit better, with less manual intervention.
>>
>> Are there any plans to improve Freesurfer in the (near) future so that
hires data can be processed within the currently available stream?
>>
>> Regards,
>> Falk
>>
>> -Original Message-
>> From: Nick Schmansky [mailto:ni...@nmr.mgh.harvard.edu]
>> Sent: Wednesday, April 01, 2009 7:53 PM
>> To: Falk Lüsebrink
>> Cc: Freesurfer Mailing List
>> Subject: Re: [Freesurfer] Measuring cortical thickness with high
>> resolution data
>>
>> Falk,
>>
>> Attached is a modified recon-all script where I've added a -hires switch
to force the stream to not conform the data to 1mm^3, and to not use the
atlases.
>>
>> Note that you should add the -clean flag to delete any work that had been
done prior (namely, -clean deletes brainmask.mgz, aseg.mgz and wm.mgz).
>>
>> However, in working with the .8mm data that you sent me, working with
hires data will require quite a bit of manual intervention due to the fact
that the atlases normally used cannot be used.  The first problem occurs in
skull-stripping, where quite a bit of dura and skull remains, and seems to
have intensity values close to gray matter.  This would have to be manually
erased on each of the slices.  If it is not erased (I did not do this
because of the amount of time required), then the wm.mgz file, which is what
is tessellated to create the initial surface, will be very wrong (it
tessellates the garbage surrounding the gray matter).
>>
>> See also Bruce's prior posting on the problems of working with hires data
in freesurfer.
>>
>> Nick
>>
>>
>> On Wed, 2009-03-25 at 13:04 +0100, Falk Lüsebrink wrote:
>>> Hi Freesurfers,
>>>
>>>
>>>
>>> Iÿÿm trying to evaluate the usefulness of high resolution scans
>>> acquired at 7T with an isometric voxel size of .6mm for the
>>> measurement of cortical thickness. The inhomogeneities are taken
>>> care of by dividing the scans with another scan of another sequence,
>>> so they are not an issue anymore.
>>>
>>>
>>>
>>> My problem is that Freesurfer usually conforms the voxel size to 1mm
>>> which is not desirable. I tried using the ÿÿcm and ÿÿnoaseg flags for
>>> the recon-all process to avoid the conformation and to skip the
>>> subcortical segmentation, but another problem arises while using
>>> these flags.
>>>
>>>
>>>
>>> The error I receive is occurring after the WM Segmentation a

RE: [Freesurfer] Measuring cortical thickness with high resolution data

[Falk Lüsebrink]

Hi Nick,

First I wanted to give you a little bit of feedback. I'm still processing
one volume with .6mm which is working perfectly fine until now. The skull
stripping was done really well and no manual intervention was needed. I'm
currently running autorecon3 and will have a look at the final results
pretty soon. Thanks again for your modification and the help you offered.

But I recently tried to process the data I send to you simultaneously to see
the results of the erroneous segmentation for myself. I just ran autorecon1
to view the brainmask.mgz and the result isn't as bad as the one you send to
me in terms of remaining dura and skull, but only the right hemisphere is
being shown and a small piece on the anterior is missing.

I also created a new subject so no older files could somehow influence the
new process. The result is the same. The flags I used were simply -hires and
-autorecon1 (and -clean in case for the older subject), so I don't know what
might have caused this issue.

Regards,
Falk


-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Doug Greve
Sent: Monday, April 06, 2009 6:25 PM
To: Falk Lüsebrink
Cc: freesurfer@nmr.mgh.harvard.edu; 'Nick Schmansky'
Subject: RE: [Freesurfer] Measuring cortical thickness with high resolution
data


Falk,  it looks like that file was somehow converted to DOS. try:

dos2unix recon-all
chmod a+x recon-all

then re-run

doug


On Mon, 6 Apr 2009, Falk Lüsebrink wrote:

> Hi Nick,
>
> I tried using your modified recon-all today but as soon as I try to
process any data I receive following error message:
>
> 'nknown option: `-
> Usage: tcsh [ -bcdefilmnqstvVxX ] [argument ...].
>
> Also it doesn't matter at all which flags I add to recon-all or if I don't
use any flags at all, the error is the same. The unmodified recon-all
performs well.
>
> Regards,
> Falk
>
> -Original Message-
> From: freesurfer-boun...@nmr.mgh.harvard.edu 
> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Nick 
> Schmansky
> Sent: Thursday, April 02, 2009 3:28 PM
> To: Falk Lüsebrink
> Cc: Freesurfer Mailing List
> Subject: RE: [Freesurfer] Measuring cortical thickness with high 
> resolution data
>
> Falk,
>
> There are no plans in the near future, but in the long term we'd like to
remove the dependence on conforming the data.
>
> It just occurred to me that you could have the best of both worlds:
> first run your data through the normal stream (conforming) up through
autorecon1, then use mri_vol2vol to create a brainmask.mgz at the same
resolution as that created using the -hires stream, and copy it over.
> At least that would eliminate having to edit the original hires brainmask,
which would save hours of work.  If i get few minutes i will try this.
>
> You can copy that recon-all over top your existing v4.x freesurfer
installation (attached again for the list).
>
> Nick
>
>
> On Thu, 2009-04-02 at 10:58 +0200, Falk Lüsebrink wrote:
>> Hi Nick,
>>
>> Thank you very much. I'll have to look into that and try to process some
other volumes which might work a bit better, with less manual intervention.
>>
>> Are there any plans to improve Freesurfer in the (near) future so that
hires data can be processed within the currently available stream?
>>
>> Regards,
>> Falk
>>
>> -Original Message-
>> From: Nick Schmansky [mailto:ni...@nmr.mgh.harvard.edu]
>> Sent: Wednesday, April 01, 2009 7:53 PM
>> To: Falk Lüsebrink
>> Cc: Freesurfer Mailing List
>> Subject: Re: [Freesurfer] Measuring cortical thickness with high 
>> resolution data
>>
>> Falk,
>>
>> Attached is a modified recon-all script where I've added a -hires switch
to force the stream to not conform the data to 1mm^3, and to not use the
atlases.
>>
>> Note that you should add the -clean flag to delete any work that had been
done prior (namely, -clean deletes brainmask.mgz, aseg.mgz and wm.mgz).
>>
>> However, in working with the .8mm data that you sent me, working with
hires data will require quite a bit of manual intervention due to the fact
that the atlases normally used cannot be used.  The first problem occurs in
skull-stripping, where quite a bit of dura and skull remains, and seems to
have intensity values close to gray matter.  This would have to be manually
erased on each of the slices.  If it is not erased (I did not do this
because of the amount of time required), then the wm.mgz file, which is what
is tessellated to create the initial surface, will be very wrong (it
tessellates the garbage surrounding the gray matter).
>>
>> See also Bruce's prior posting on the problems of working with hires da

[Freesurfer] aparcstats2table

[Falk Lüsebrink]

Hi Freesurfers,

 

I tried using aparcstats2table today and encountered following error
message:

 

Trackback (most recent call last):

  File “usr/share/freesurfer/bin/aparcstats2table”, line 6, in 

Import fsutils

ImportError: No module named fsutils

 

Is anyone able to offer some help? I am using v4.3.0 and it didn’t matter if
I used any flags or not.

 

Thanks in advance,

Falk

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

RE: [Freesurfer] aparcstats2table

[Falk Lüsebrink]

Hi Krish,

Thanks for your help.

Regards,
Falk

-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Krish
Subramaniam
Sent: Tuesday, April 14, 2009 5:03 PM
To: Falk Lüsebrink
Cc: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] aparcstats2table

Hi Falk

fsutils is one of the 4 helper scripts missing from the distribution.

Please get the 4 scripts from here:
ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/fixes/datastruct_utils.
py
ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/fixes/fsutils.py
ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/fixes/misc.py
ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/fixes/subject_info.py

And put them in your $FREESURFER_HOME/bin directory.

Sorry for the trouble.
Krish


On Apr 14, 2009, at 10:36 AM, Falk Lüsebrink wrote:

> Hi Freesurfers,
>
> I tried using aparcstats2table today and encountered following error  
> message:
>
> Trackback (most recent call last):
>   File “usr/share/freesurfer/bin/aparcstats2table”, line 6, in  
> 
> Import fsutils
> ImportError: No module named fsutils
>
> Is anyone able to offer some help? I am using v4.3.0 and it didn’t  
> matter if I used any flags or not.
>
> Thanks in advance,
> Falk
> ___
> 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

[Freesurfer] Issues with skull stripping

[Falk Lüsebrink]

Hi Freesurfers,

 

I’m currently working on four different subjects and I’m having problems
with the skull stripping for three of them. The four subjects I’m trying to
process are:

 

1)  0.6mm iso voxel size, being the same subject as 4)

2)  0.5mm iso voxel size

3)  0.8mm iso voxel size

4)  1mm iso voxel size

 

The only subject which works nearly perfectly fine is subject 1.

 

In case of 2 and 3 there are missing parts of the brain or even a whole
hemisphere. I tried using the –wsgthresh switch following the tutorial on
the wiki. In case of subject 2 the brainmask.mgz looks fairly good while
setting the threshold to 80, but still some parts of the brain are missing
and setting the threshold to 100 or 150 doesn’t change much. There is not
even more skull left.

 

For subject 3 a threshold of 30 is sufficient and the whole brain is being
shown, though some bits of skull and dura are not removed. I got a good
result for the skull stripping with v4.0.5 by not conforming the data, but I
haven’t been able to get the same result with v4.3.0.

 

In case of subject 4 autorecon1 exists with an error during the talairach
check. I tried to follow the wiki for that issue, but haven’t been able to
even roughly match the movable with the target. So I skipped the tal-check
running into the same problem as subject 2 and 3.

 

The command lines I used were for subject 1 to 3 recon-all –autorecon1
–hires and for subject 4 just recon-all –autorecon1. I tried to use
recon-all –autorecon1 –cm for subject 2 and 3, as this resulted in good
skull stripping using v4.0.5. But recon-all exists with an error during
mri_watershed: “GLOBAL region of the brain is empty!” I get the same error
if I don’t use the –no-wsgcaatlas switch during recon-all –skullstrip, even
if I didn’t use the –cm or –hires switches before.

 

As I’m not able to reproduce the same results between v4.0.5 and v4.3.0,
have there been made changes to the processes of autorecon1 which I haven’t
read of affecting the skull stripping? And does anyone have an idea besides
manually doing the skull stripping? 

 

Thanks in advance,

Regards,

Falk

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

[Freesurfer] Comparison of cortical thickness results

[Falk Lüsebrink]

Hi everyone,

 

I’d like to compare the individual cortical thickness results of Freesurfer
with the results of another software. The other software measures the
cortical thickness for example across the whole left parietal lobe. So I
have to get the according value of the whole left parietal lobe of
Freesurfer’s results. But I don’t know exactly how to do that.

 

Does someone have any suggestions how to get this value? At first glance I
would weight the average thickness of every structure belonging to the
parietal lobe given in the aparc.a2005s file by the number of vertices (or
maybe the gray matter volume in case the volume had a resolution of 1mm^3?).
Sum everything up and divide it by the number of vertices to get the mean
average across the parietal lobe. Would that result in the value I’m
searching for?

 

Thanks in advance,

Falk

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

RE: [Freesurfer] Comparison of cortical thickness results

[Falk Lüsebrink]

Hi Nick,

Thank you very much, that worked well. Though the initial command was 
mri_annotation2label not mris_annot2label in v4.3.0 of FreeSurfer.

Regards,
Falk

-Original Message-
From: Nick Schmansky [mailto:ni...@nmr.mgh.harvard.edu] 
Sent: Tuesday, April 28, 2009 7:08 AM
To: Falk Lüsebrink
Cc: Freesurfer Mailing List
Subject: Re: [Freesurfer] Comparison of cortical thickness results

Falk,

If you have the .annot file for a subject, you can break that apart into
individual label files using mris_annot2label.  Then knowing which
labels compose the parietal lobe (for the Desikan-Killiany atlas,
superior and inferior parietal, supramarginal, precuneus and postcentral
compose the parietal lobe), then you can create a new label file by
combining the label files into one with a text editor (the second line
is the number of vertices composing the label, so be sure to get that
right).  then use mris_anatomical_stats to get the stats on this new
label.

Nick


On Mon, 2009-04-27 at 16:31 +0200, Falk Lüsebrink wrote:
> Hi everyone,
> 
>  
> 
> I’d like to compare the individual cortical thickness results of
> Freesurfer with the results of another software. The other software
> measures the cortical thickness for example across the whole left
> parietal lobe. So I have to get the according value of the whole left
> parietal lobe of Freesurfer’s results. But I don’t know exactly how to
> do that.
> 
>  
> 
> Does someone have any suggestions how to get this value? At first
> glance I would weight the average thickness of every structure
> belonging to the parietal lobe given in the aparc.a2005s file by the
> number of vertices (or maybe the gray matter volume in case the volume
> had a resolution of 1mm^3?). Sum everything up and divide it by the
> number of vertices to get the mean average across the parietal lobe.
> Would that result in the value I’m searching for?
> 
>  
> 
> Thanks in advance,
> 
> Falk
> 
> 
> ___
> 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] (no subject)

[Falk Lüsebrink]

Hi Elina,

 

You could have a look at
http://surfer.nmr.mgh.harvard.edu/fswiki/recon-all#Step-wiseDirectives-1 and
http://surfer.nmr.mgh.harvard.edu/fswiki/ReconAllDevTable to identify the
needed time of each process. But I have to mention, that the timeline is not
perfectly accurate and can vary a lot.

 

Hope this helps,

Regards,

Falk

 

 

From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Elina Pitri
Sent: Wednesday, April 29, 2009 12:37 PM
To: freesurfer@nmr.mgh.harvard.edu
Subject: [Freesurfer] (no subject)

 

Hello Freesurfer Creators,

 

I am wondering how much time should Volume and Surface processing (using
recon-all commands) take.

 

thanks,

 

Elina

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

[Freesurfer] Literature values for cortical thickness

[Falk Lüsebrink]

Hi everyone,

 

As I don’t do a study in which I compare a group of subjects with some kind
of abnormality with a control group I was looking for literature values for
cortical thickness. The only paper I found which was written by von Economo
et al. in 1925 doing a post-mortem analysis.

 

Are there any more recent sources available which maybe even cover in-vivo
values for regional cortical thickness? Actually I’m looking for average
values across the whole lobes.

 

Thanks in advance,

Falk

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

RE: [Freesurfer] Literature values for cortical thickness

[Falk Lüsebrink]

Hi Rahul and Bruce,

I'm trying to evaluate the usefulness of 7T data for the measurement of
cortical thickness. But as FreeSurfer doesn't perform too well using high
resolution data right now I'm also using a module within Slicer to get
results. Though I'm still trying to process my high resolution data with
FreeSurfer.

To compare the results between this module and FreeSurfer and to do a
cross-scanner comparison I am comparing the mean average and std dev of the
frontal, temporal, occipital and parietal lobe. This is done because of the
parcellation of the Slicer module, so these parcellation units would be
helpful. The subjects I have used and will be using are young healthy
adults.

Regards,
Falk

-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of
ra...@nmr.mgh.harvard.edu
Sent: Wednesday, May 13, 2009 2:55 PM
To: Bruce Fischl
Cc: freesurfer@nmr.mgh.harvard.edu; Falk Lüsebrink
Subject: Re: [Freesurfer] Literature values for cortical thickness

Hi Falk,

We do indeed have cortical thickness values for each of the parcellation
units for a range of subjects (healthly elderly, middle age and young
controls and Alzheimer's disease subjects). Which parcellation units are
you looking for? A whole lobe?

Best,

rahul

> Hi Falk,
>
> we published some values in our Cerebral Cortex paper , but I suspect the
> effective thickness will vary a bit as a function of pulse sequence, and
> certainly it will vary with things like age. Rahul has probably tabulated
> by parcellation unit if that helps.
>
> cheers
> Bruce
>
> On Wed, 13 May
> 2009, Falk Lüsebrink wrote:
>
>> Hi everyone,
>>
>>
>>
>> As I don’t do a study in which I compare a group of subjects with some
>> kind
>> of abnormality with a control group I was looking for literature values
>> for
>> cortical thickness. The only paper I found which was written by von
>> Economo
>> et al. in 1925 doing a post-mortem analysis.
>>
>>
>>
>> Are there any more recent sources available which maybe even cover
>> in-vivo
>> values for regional cortical thickness? Actually I’m looking for average
>> values across the whole lobes.
>>
>>
>>
>> Thanks in advance,
>>
>> Falk
>>
>>

___
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] Processing high resolution data

[Falk Lüsebrink]

Hi FreeSurfers,

 

I’m still trying to process some high resolution data through the freesurfer
stream, but it is constantly failing during several different stages. The
biggest issue is the skull stripping and I’m still trying to get good
results here.

 

Using the –hires switch during –autorecon1 normally leaves to much skull or
cuts of too much tissue. Adjusting the parameters during mri_watershed (like
changing the preflooding height or using the –atlas switch) doesn’t work too
well in most cases.

 

I tried to manually edit the brainmask.mgz with tkmedit but I encountered
another problem. I was using data with an isometric voxel size of 0.6mm and
removed every bit of left skull from the coronal view. Afterwards I ran
–autorecon2 but it did exit, so I viewed the brainmask in Slicer and noticed
that probably every second slice was skipped in tkmedit.

 

I also tried using the –cm switch during –autorecon1 to create the .lta file
for the skull stripping stage, which I was hoping to improve the results.
But either mri_watershed exists with an error in which it states that the WM
intensity is 0 and therefore below the csf intensity and that I should check
the volume, though I can’t find anything unusual, or it exists with the
error “segmentation fault”. I read that these “segmentation fault” errors
seem to occur if the system runs out of memory, but as I’m having 32gb ram
and 16gb swap memory I don’t think this is the reason.

 

Another approach I was using is to use either a brainmask created by a
stream of Slicer and then importing it to freesurfer or to use a brainmask
created by a conformed stream, then using mri_vol2vol to resample it to the
original resolution and process the other stages. The first approach should
work fine, but the volume I used wasn’t well processed during mri_fill. Most
voxels were recognized as being part of the left hemisphere and only a few
(about 150) were marked as belonging to the right hemisphere. And I was
unable to fix this issue.

 

The second approach seems also to be a good idea, but the resulting
brainmask is blurred due to the “upscaling”. I noticed that using the –hires
switch the brainmask isn’t really used as a mask during normalization2 but
is just normalized again and the output is written as brain.mgz. If I want
to use the brainmask as a mask (as it should be intended) should I use it to
mask the T1.mgz? Like mri_normalize –noconform –mask brainmask.mgz T1.mgz
brain.mgz? In the original stream the brainmask is used here to mask the
norm.mgz, which I quite don’t understand as the norm.mgz is already
stripped. But maybe I just get something wrong.

 

Yesterday I was able get a good skull stripping by running mri_nu_correct
again with T1.mgz as the input and using the –distance 25 –stop 0.0001
switches (which I read of in another mail here on the list to improve
results using 3T data). But recon-all exists at the beginning of
mris_fix_topology with the “segmentation fault” error on both hemispheres.

 

I apologize for the long text, but maybe someone can give me some input to
try something else or help with existing issues.

 

Thanks in advance,

Regards,

Falk

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

RE: [Freesurfer] data conversion

[Falk Lüsebrink]

Hi Ali,

 

Try using the –cm switch for mri_convert. This should conform the input not
to 1mm iso and 256x256 matrix size, but will conform to the minimum voxel
size. The result should be an image having the correct resolution and matrix
size. Though you should keep in mind that you will have 320 slices
afterwards.

 

Regards,

Falk

 

 

From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Al-Radaideh Ali
Sent: Friday, May 15, 2009 3:12 PM
To: freesurfer@nmr.mgh.harvard.edu
Subject: [Freesurfer] data conversion

 

 Dear FreeSurfer experts,

 

I used 0.6mm isotropic resolution MPRAGE ( matrix size 320 x 320 ) and 260
slices in freesurfer. The output (.mgz) has a different resolution and
matrix size (1mm isotropic resolution and 256 x 256 matrix size). I used
mri_convert to convert the output image from mgz to analyze. is there any
way I can get back to the original resolution and matrix size, please? 

 

Thanks in advance

Ali 

 

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation. 

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

[Freesurfer] mri_fill

[Falk Lüsebrink]

Hi FreeSurfers,

 

At the end of mri_fill I’m told to check the filled volume as the cerebellum
may be included. It is and also the brainstem. But  actually I don’t know
how to fix this. Do I need to include the seed points for cc and pons for
better cutting planes? Do I need to manually edit the volume?

 

If the latter is better are there any other tools available besides tkmedit?
If I try to add or delete voxels of a high resolution volume tkmedit seems
to skin every second slice.

 

Regards,

Falk

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

RE: [Freesurfer] mri_fill

[Falk Lüsebrink]

Hi Bruce,

Actually I need to skip the whole aseg process as this is incompatible to
the high resolution volumes I'm using. I read that prior to the aseg files
the talairach transform was used to delete the cerebellum and that the
cutting planes correctly. Is it possible to use this again?

I also tried using seed points, though the cerebellum was never erased.

Regards,
Falk

-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Bruce Fischl
Sent: Monday, May 18, 2009 2:07 PM
To: Falk Lüsebrink
Cc: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] mri_fill

p.s. you can pick seed points in the callosum and pons in tkmedit and see if
that fixes your problem, but if there is something else going on then it may
not (e.g. if the aseg is badly wrong) On Mon, 18 May 2009, Falk Lüsebrink
wrote:

> Hi FreeSurfers,
>
>
>
> At the end of mri_fill I’m told to check the filled volume as the 
> cerebellum may be included. It is and also the brainstem. But  
> actually I don’t know how to fix this. Do I need to include the seed 
> points for cc and pons for better cutting planes? Do I need to manually
edit the volume?
>
>
>
> If the latter is better are there any other tools available besides
tkmedit?
> If I try to add or delete voxels of a high resolution volume tkmedit 
> seems to skin every second slice.
>
>
>
> Regards,
>
> Falk
>
>


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

RE: [Freesurfer] mri_fill

[Falk Lüsebrink]

As mentioned in the first email somehow tkmedit seems to skip some slices if
one tries to edit them manually and the resolution of the volume is not
1mm^3. Attached is a screenshot of the filled.mgz which I tried to edit on
the left from the coronal view and on the right from the sagittal view.

The resolution of the volume used in this case is 0.6mm. If I use the
"Slice" thing to browse through the slices nearly every second slice is
skipped. Increasing or decreasing the volume index by 1 in the direction I
would like to move on doesn't work either. For example if I change the
volume index from 162 338 124 to 163 338 124 the same slice is being shown.
161 338 124 and 164 338 124 are different as it should be, but it is not
possible to view 163 and so it is impossible to edit this slice.

Are there any other tools available to edit volumes like tkmedit does? It
doesn't need to be included within FreeSurfer but it would be better if it
could handle the .mgz format.

Regards,
Falk

-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Falk Lüsebrink
Sent: Monday, May 18, 2009 2:36 PM
To: 'Bruce Fischl'
Cc: freesurfer@nmr.mgh.harvard.edu
Subject: RE: [Freesurfer] mri_fill

Hi Bruce,

Actually I need to skip the whole aseg process as this is incompatible to
the high resolution volumes I'm using. I read that prior to the aseg files
the talairach transform was used to delete the cerebellum and that the
cutting planes correctly. Is it possible to use this again?

I also tried using seed points, though the cerebellum was never erased.

Regards,
Falk

-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Bruce Fischl
Sent: Monday, May 18, 2009 2:07 PM
To: Falk Lüsebrink
Cc: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] mri_fill

p.s. you can pick seed points in the callosum and pons in tkmedit and see if
that fixes your problem, but if there is something else going on then it may
not (e.g. if the aseg is badly wrong) On Mon, 18 May 2009, Falk Lüsebrink
wrote:

> Hi FreeSurfers,
>
>
>
> At the end of mri_fill I’m told to check the filled volume as the 
> cerebellum may be included. It is and also the brainstem. But  
> actually I don’t know how to fix this. Do I need to include the seed 
> points for cc and pons for better cutting planes? Do I need to manually
edit the volume?
>
>
>
> If the latter is better are there any other tools available besides
tkmedit?
> If I try to add or delete voxels of a high resolution volume tkmedit 
> seems to skin every second slice.
>
>
>
> Regards,
>
> Falk
>
>


___
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] mri_fill

[Falk Lüsebrink]

Hi Allison and Nick,

Thanks for the info. The wiki didn't mention that either freeview or scuba
(dev only) would be available in the current release.

I tried both scuba and freeview and I'm wondering if there is some easy way
to browse through the slices from either the sagital, coronal or axial view.
Using scuba I could enter the RAS or index coords or is there something else
I'm missing? In freeview I think I have to switch between the navigation
tool and voxel edit tool or is there another way?

At first glance freeview does appeal more to me in terms of simply erasing
some voxels, so I think I will stick with it.

Thanks in advance,
Regards,
Falk


-Original Message-
From: Allison Stevens [mailto:astev...@nmr.mgh.harvard.edu] 
Sent: Tuesday, May 19, 2009 5:38 PM
To: Nick Schmansky
Cc: Falk Lüsebrink
Subject: RE: [Freesurfer] mri_fill

Falk,
I can help you get started with scuba or freeview.

For freeview, you type:
freeview -v volume.mgz

and it will load your volume. There is a help guide in there to take you 
through all the tools. Let me know if you need any help.
Allison

-- 

On Tue, 19 May 2009, Nick Schmansky wrote:

> Falk,
>
> There are two tools included with freesurfer that can be used to perform
> edits on hi-res data: scuba, and freeview.  I do not have experience
> with either.  tkmedit is not setup to edit hi-res data, as it resamples
> to 1mm^3.
>
> Nick
>
> On Tue, 2009-05-19 at 11:46 +0200, Falk Lüsebrink wrote:
>> As mentioned in the first email somehow tkmedit seems to skip some slices
if
>> one tries to edit them manually and the resolution of the volume is not
>> 1mm^3. Attached is a screenshot of the filled.mgz which I tried to edit
on
>> the left from the coronal view and on the right from the sagittal view.
>>
>> The resolution of the volume used in this case is 0.6mm. If I use the
>> "Slice" thing to browse through the slices nearly every second slice is
>> skipped. Increasing or decreasing the volume index by 1 in the direction
I
>> would like to move on doesn't work either. For example if I change the
>> volume index from 162 338 124 to 163 338 124 the same slice is being
shown.
>> 161 338 124 and 164 338 124 are different as it should be, but it is not
>> possible to view 163 and so it is impossible to edit this slice.
>>
>> Are there any other tools available to edit volumes like tkmedit does? It
>> doesn't need to be included within FreeSurfer but it would be better if
it
>> could handle the .mgz format.
>>
>> Regards,
>> Falk
>>
>> -Original Message-
>> From: freesurfer-boun...@nmr.mgh.harvard.edu
>> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Falk
Lüsebrink
>> Sent: Monday, May 18, 2009 2:36 PM
>> To: 'Bruce Fischl'
>> Cc: freesurfer@nmr.mgh.harvard.edu
>> Subject: RE: [Freesurfer] mri_fill
>>
>> Hi Bruce,
>>
>> Actually I need to skip the whole aseg process as this is incompatible to
>> the high resolution volumes I'm using. I read that prior to the aseg
files
>> the talairach transform was used to delete the cerebellum and that the
>> cutting planes correctly. Is it possible to use this again?
>>
>> I also tried using seed points, though the cerebellum was never erased.
>>
>> Regards,
>> Falk
>>
>> -Original Message-
>> From: freesurfer-boun...@nmr.mgh.harvard.edu
>> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Bruce Fischl
>> Sent: Monday, May 18, 2009 2:07 PM
>> To: Falk Lüsebrink
>> Cc: freesurfer@nmr.mgh.harvard.edu
>> Subject: Re: [Freesurfer] mri_fill
>>
>> p.s. you can pick seed points in the callosum and pons in tkmedit and see
if
>> that fixes your problem, but if there is something else going on then it
may
>> not (e.g. if the aseg is badly wrong) On Mon, 18 May 2009, Falk Lüsebrink
>> wrote:
>>
>>> Hi FreeSurfers,
>>>
>>>
>>>
>>> At the end of mri_fill Iÿÿm told to check the filled volume as the
>>> cerebellum may be included. It is and also the brainstem. But
>>> actually I donÿÿt know how to fix this. Do I need to include the seed
>>> points for cc and pons for better cutting planes? Do I need to manually
>> edit the volume?
>>>
>>>
>>>
>>> If the latter is better are there any other tools available besides
>> tkmedit?
>>> If I try to add or delete voxels of a high resolution volume tkmedit
>>> seems to skin every second slice.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Falk
>>>
>>>
>>
>&

[Freesurfer] Guideline to process high resolution data using FreeSurfer and some questions

[Falk Lüsebrink]

Hi FreeSurfers,

 

Due to an accident and after several hundreds of hours of work I was finally
able to completely (actually not completely, but it seems to work) process
high resolution data with an isometric voxel size of 0.6mm without any
manual intervention, while using the advantage of all atlases. I would like
to share my experience with you and especially would like to know if and how
some of my individual changes to the recon-all stream may affect the
results.

 

The data I used was acquired at 7T (Siemens), so my volumes were not very
homogenous. To get rid of most of the inhomogeneities we are using a method
at our lab in which two volumes are acquired, a MPRAGE and 3D gradient echo.
Both volumes are co-registered and afterwards the MPRAGE is divided by the
3D GE. Everything further has been done directly using FreeSurfer.

 

First you need to run recon-all –autorecon1 –cm –noskullstrip –s . Using the –cm flag the volumes are not conformed to 1mm^3 voxel
size and 256^3, but to the smallest voxel size (in my case 0.5990mm^3 and
385^3). It is crucial to not run –skullstrip using the high resolution data
as this will not work! You need to go to your subject/mri folder and use
mri_convert –cs 1 nu.mgz nu.conformed.mgz, this creates a conformed version
of the nu.mgz. Now you should run mri_em_register –skull nu.conformed.mgz
$FREESURFER_HOME/average/RB_all_withskull_2008-03-26.gca
transforms/talairach_with_skull.lta.

 

This has to be done using a conformed nu.mgz as in the following stage
mri_watershed seems to conform the input file (Will it be really conformed?
The output volume doesn’t suggest this.) and if the talairach_with_skull.lta
is created using a not conformed volume one gets an error stating that the
WM intensity is lower than CSF intensity and the stage is exited. The
nu.conformed.mgz is only used during this stage, so your high resolution
volumes will never (Never? At least the output volumes are not.) be
resampled, conformed or whatever to a lower resolution.

 

After this has been done, one can use recon-all –skullstrip –s  and take advantage of the atlas! Though the input volume (T1.mgz)
seems to be conformed during mri_watershed, the output volume
(brainmask.mgz) will have the correct resolution. If the brainmask.mgz
doesn’t look well, try adding the –wsatlas switch first, as this improved
the skull stripping if only really small bits of skull and dura were still
left or small pieces of the temporal lobe or cerebellum were cut off. If
this doesn’t help much adjust the watershed threshold using the –wsthresh
 switch (but still use –wsatlas) like described in the wiki.

 

Now run recon-all –gcareg –canorm –careg –careginv –rmneck –skull-lta
–calabel –s . Even though the aseg.mgz should look perfectly
fine, one needs to stop here, as the –normalization2 stage can be run only
if the aseg.mgz is conformed (Why does it need to be conformed?). This is
something you don’t want, so go to the subject/mri folder again and run
mri_normalize –mask brainmask.mgz norm.mgz brain.mgz.

 

Right now I'm running the missing stages of -autorecon2 (being at the -fix
stage which will take some time) and I think it should work totally fine.
Maybe the following stages using the aseg.mgz might not run as those maybe
want the aseg.mgz to be conformed as well, but I don't know yet.
Additionally in my case this wouldn't be a problem as I just want to measure
the cortical thickness.

 

I would highly appreciate if you could answer the questions in the brackets
and how the results might be effected by the changes I have done.

 

By the way, I tried running mri_nu_correct.mni using the T1.mgz as the input
volume and running mri_normalize again afterwards to improve the
inhomogeneity correction. The result looks very good, but parts of the skull
and dura are not erased during the skull stripping stage (as they seem to
match the intensities of GM and WM). If I adjust the watershed threshold so
these are erased, pieces of the cerebellum and temporal lobes are erased
additionally. Would it be possible to run mri_nu_correct using the
brainmask.mgz as input volume and mri_normalize afterwards, so the
inhomogeneity correction can be further improved? Will mri_nu_correct.mni
work fine on a volume without skull?

 

Thanks in advance,

Regards,

Falk

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

[Freesurfer] Troubleshooting

[Falk Lüsebrink]

Hello,

 

I’m having trouble to generate a correct aseg.mgz for one volume of mine.
The nu_noneck.mgz is also incorrect and therefore I think the -careg stage
of autorecon2 might fail. Is there a way to do some kind quality check, like
the tal-check during autorecon1, to see whether the talairach.m3z is
incorrect? Are there some kind of instructions like fixing the bad output
from the talairach registration? Or are there some parameters which can be
adjusted to get better results?

 

If none of this is possible in some way, would it be advisable to use the
-noaseg flag? I’m actually in no need for the subcortical segmentation, it
would just be a plus, but the aseg.mgz is needed during the -segmentation
stage to remove the cerebellum and brain stem. Maybe there even is another
way to remove these structures automatically?

 

Thanks in advance,

Regards,

Falk

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

RE: [Freesurfer] Troubleshooting

[Falk Lüsebrink]

Hi Martin,

Thanks for the input, but I think you got me wrong. The talairach
registration and talairach check during -autorecon1 is fine. I think the
-careg stage during -autorecon2 might fail, which "generates a
multi-dimensinal talairach transform" (mri_ca_register). And I was looking
for something like the tutorials you mentioned, however not for the
talairach registration during -autorecon1, but for mri_ca_register.

Regards,
Falk


-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Martin Kavec
Sent: Thursday, May 28, 2009 1:31 PM
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] Troubleshooting

Hi Falk,

On Thursday 28 May 2009 11:56:51 Falk Lüsebrink wrote:
> Hello,
>
>
>
> I’m having trouble to generate a correct aseg.mgz for one volume of mine.
> The nu_noneck.mgz is also incorrect and therefore I think the -careg stage
> of autorecon2 might fail. Is there a way to do some kind quality check,
> like the tal-check during autorecon1, to see whether the talairach.m3z is
> incorrect? Are there some kind of instructions like fixing the bad output
> from the talairach registration?

For this you can follow instruction on 

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

and more specifically

http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/Talairach

Hope some of that may lead you to successful reconstruction.

Best,

Martin

___
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] Bad aseg

[Falk Lüsebrink]

Yes, the skull stripping looks nice.

- Original Message - 
From: "Bruce Fischl" 

To: "Falk Lüsebrink" 
Cc: 
Sent: Monday, June 29, 2009 6:19 PM
Subject: Re: [Freesurfer] Bad aseg


Did you check the skull stripping?



On Jun 29, 2009, at 3:54 AM, Falk Lüsebrink  wrote:





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

Re: [Freesurfer] Bad aseg

[Falk Lüsebrink]

I could do that, but not before wednesday.


- Original Message - 
From: "Bruce Fischl" 

To: "Falk Lüsebrink" 
Cc: 
Sent: Monday, June 29, 2009 6:53 PM
Subject: Re: [Freesurfer] Bad aseg



do you want to send us the subject?
On Mon, 29 Jun 2009, [UTF-8] Falk
Lüsebrink wrote:


Yes, the skull stripping looks nice.

- Original Message - From: "Bruce Fischl"

To: "Falk Lüsebrink" 
Cc: 
Sent: Monday, June 29, 2009 6:19 PM
Subject: Re: [Freesurfer] Bad aseg


Did you check the skull stripping?



On Jun 29, 2009, at 3:54 AM, Falk Lüsebrink  wrote:









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

[Freesurfer] Processing data with -noaseg flag

[Falk Lüsebrink]

Hi FreeSurfers,

 

As the subcortical segmentation fails fairly often on my high resolution
data I want to skip it by using the –noaseg flag, but I’m currently
encountering another issue.

 

1.)During the –fix stage of –autorecon2 I receive following error during
mris_euler_numbers (also if I want to view the lh.orig or rh.orig in
tksurfer):

 

rh.orig: face[233615].v[2] = 119048, but face 233615 not in vertex 119048
face list

 

lh.orig: face[196300].v[1] = 100366, but face 196300 not in vertex 100366
face list

 

2.)Normally the subcortical segmentation is also used to cut both
hemisphere and to remove the cerebellum. The cutting plane between the
hemispheres is done very well, but I have never been able to remove the
cerebellum. Do I need to remove it manually or are there some ways to remove
it automatically? Is it required to be removed?

 

3.)I’m interested in measuring cortical thickness only. But do I need to
keep something else in mind while not using the subcortical segmentation to
process my data?

 

 

Thanks in advance,

Regards,

Falk

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

Re: [Freesurfer] Processing data with -noaseg flag

[Falk Lüsebrink]

Hi Bruce,

Actually I also acquired a 1mm dataset at 3T and 7T, which works fine using
FreeSurfer. But I'm trying to compare the results with a 0.6mm (0.5mm later)
dataset of the same subjects scanned at 7T.

I tried selecting a seed point for the cutting planes following your advice
and using the tutorial in the wiki. Instead of using the seed point I
specify mri_fill is looking for another one "in the neighborhood". For
example if I choose the coordinates 193 197 174 mri_fill uses 186 220 216,
resulting in also removing most of the occipital lobe.

Is it possible to force FreeSurfer using the seed point I choose? Or do I
have to do something else so mri_fill recognizes the seed point I choose to
be valid?

Thanks in advance,
Regards,
Falk



-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Bruce Fischl
Sent: Thursday, July 30, 2009 2:39 PM
To: Falk Lüsebrink
Cc: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] Processing data with -noaseg flag

Hi Falk,

can you really not afford the 6 minutes or so of scan time to get  a good
1mm dataset? We have analyzed a bunch of 7T data successfully, although it
probably isn't as automated as 1.5 and 3T. The error you are getting we only
see when you have run out of disk space. It sounds like the surface file is
corrupted. As for the cutting planes, you should be able to select a point
in the pons above the cerebellar peduncle for the brainstem cutting plane.
This should remove the cerebellum, which is required for analysis.

We certainly did many cortical thickness studies before the aseg stuff was
integrated into the stream, so it should be possible, it just requires more
work.

cheers,
Bruce


On Thu, 30 Jul 2009, Falk Lüsebrink wrote:

> Hi FreeSurfers,
>
>
>
> As the subcortical segmentation fails fairly often on my high 
> resolution data I want to skip it by using the –noaseg flag, but I’m 
> currently encountering another issue.
>
>
>
> 1.)During the –fix stage of –autorecon2 I receive following error
during
> mris_euler_numbers (also if I want to view the lh.orig or rh.orig in
> tksurfer):
>
>
>
> rh.orig: face[233615].v[2] = 119048, but face 233615 not in vertex 
> 119048 face list
>
>
>
> lh.orig: face[196300].v[1] = 100366, but face 196300 not in vertex 
> 100366 face list
>
>
>
> 2.)Normally the subcortical segmentation is also used to cut both
> hemisphere and to remove the cerebellum. The cutting plane between the 
> hemispheres is done very well, but I have never been able to remove 
> the cerebellum. Do I need to remove it manually or are there some ways 
> to remove it automatically? Is it required to be removed?
>
>
>
> 3.)I’m interested in measuring cortical thickness only. But do I need
to
> keep something else in mind while not using the subcortical 
> segmentation to process my data?
>
>
>
>
>
> Thanks in advance,
>
> Regards,
>
> Falk
>
>


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

Re: [Freesurfer] mris_fix_topology

[Falk Lüsebrink]

Hi Doug,

I get the following error:

rh.orig: face[161898].v[2] = 82472, but face 161898 not in vertex 82472 face
list

Falk

-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Douglas N Greve
Sent: Thursday, August 20, 2009 12:12 AM
To: Falk Lüsebrink
Cc: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] mris_fix_topology


It was not mris_fix_topology that failed but mris_euler_number (but that 
might have failed because of something in the topology fix). What 
happens if you:

cd /home/falk/freesurfer/subjects/yv98_05mm_div
mris_euler_number ../surf/rh.orig

doug

Falk Lüsebrink wrote:
>
> Hi FreeSurfers,
>
>  
>
> Attached is a log file containing an error of mris_fix_topology and I 
> would like to know how to fix that issue if that is possible. Is it 
> possible to view a defect (in that case #33) in tksurfer or freeview 
> to identify a possible error in the wm.mgz or filled.mgz to correct it 
> manually?
>
>  
>
> Thanks in advance,
>
> Falk
>
> 
>
> ___
> 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

In order to help us help you, please follow the steps in:
surfer.nmr.mgh.harvard.edu/fswiki/BugReporting


___
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] mris_fix_topology

[Falk Lüsebrink]

Hi Bruce,

No, there are some hundreds of GB left.

Is the other topology fixer you meant before mris_topo_fixer?

Thanks in advance,
Falk

-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Bruce Fischl
Sent: Thursday, August 20, 2009 4:44 AM
To: Falk Lüsebrink
Cc: freesurfer@nmr.mgh.harvard.edu; 'Douglas N Greve'
Subject: Re: [Freesurfer] mris_fix_topology

are you out of disk space?
On Thu, 20 Aug 2009, Falk Lüsebrink wrote:

> Hi Doug,
>
> I get the following error:
>
> rh.orig: face[161898].v[2] = 82472, but face 161898 not in vertex 
> 82472 face list
>
> Falk
>
> -Original Message-
> From: freesurfer-boun...@nmr.mgh.harvard.edu
> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Douglas N 
> Greve
> Sent: Thursday, August 20, 2009 12:12 AM
> To: Falk Lüsebrink
> Cc: freesurfer@nmr.mgh.harvard.edu
> Subject: Re: [Freesurfer] mris_fix_topology
>
>
> It was not mris_fix_topology that failed but mris_euler_number (but 
> that might have failed because of something in the topology fix). What 
> happens if you:
>
> cd /home/falk/freesurfer/subjects/yv98_05mm_div
> mris_euler_number ../surf/rh.orig
>
> doug
>
> Falk Lüsebrink wrote:
>>
>> Hi FreeSurfers,
>>
>>
>>
>> Attached is a log file containing an error of mris_fix_topology and I 
>> would like to know how to fix that issue if that is possible. Is it 
>> possible to view a defect (in that case #33) in tksurfer or freeview 
>> to identify a possible error in the wm.mgz or filled.mgz to correct 
>> it manually?
>>
>>
>>
>> Thanks in advance,
>>
>> Falk
>>
>> -
>> ---
>>
>> ___
>> 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] mris_fix_topology

[Falk Lüsebrink]

Thanks, I'll try to do that.

Are the commands for mris_topo_fixer the same as of mris_fix_topology? I
haven't seen a help for that one.

Regards,
Falk

-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Bruce Fischl
Sent: Thursday, August 20, 2009 2:36 PM
To: Falk Lüsebrink
Cc: freesur...@surfer.nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] mris_fix_topology

yes. The only time I've seen this error is when the surface file didn't
finish writing. You can load the defects with something like:

tksurfer -orig orig.nofix $subject $hemi inflated.nofix

then load the curvature file $hemi.defect_labels. You should be able to use
save point/goto point in tksurfer and tkmedit to figure out where each
vertex is in the wm.mgz volume and manually correct it (although this is an
acquired skill!).  You may need to specifiy -white orig.nofix as well,
although looking at the code I don't think you do.

cheers,
Bruce

On Thu, 20 Aug 2009, Falk Lüsebrink wrote:

> Hi Bruce,
>
> No, there are some hundreds of GB left.
>
> Is the other topology fixer you meant before mris_topo_fixer?
>
> Thanks in advance,
> Falk
>
> -Original Message-
> From: freesurfer-boun...@nmr.mgh.harvard.edu
> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Bruce 
> Fischl
> Sent: Thursday, August 20, 2009 4:44 AM
> To: Falk Lüsebrink
> Cc: freesurfer@nmr.mgh.harvard.edu; 'Douglas N Greve'
> Subject: Re: [Freesurfer] mris_fix_topology
>
> are you out of disk space?
> On Thu, 20 Aug 2009, Falk Lüsebrink wrote:
>
>> Hi Doug,
>>
>> I get the following error:
>>
>> rh.orig: face[161898].v[2] = 82472, but face 161898 not in vertex
>> 82472 face list
>>
>> Falk
>>
>> -Original Message-
>> From: freesurfer-boun...@nmr.mgh.harvard.edu
>> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Douglas 
>> N Greve
>> Sent: Thursday, August 20, 2009 12:12 AM
>> To: Falk Lüsebrink
>> Cc: freesurfer@nmr.mgh.harvard.edu
>> Subject: Re: [Freesurfer] mris_fix_topology
>>
>>
>> It was not mris_fix_topology that failed but mris_euler_number (but 
>> that might have failed because of something in the topology fix). 
>> What happens if you:
>>
>> cd /home/falk/freesurfer/subjects/yv98_05mm_div
>> mris_euler_number ../surf/rh.orig
>>
>> doug
>>
>> Falk Lüsebrink wrote:
>>>
>>> Hi FreeSurfers,
>>>
>>>
>>>
>>> Attached is a log file containing an error of mris_fix_topology and 
>>> I would like to know how to fix that issue if that is possible. Is 
>>> it possible to view a defect (in that case #33) in tksurfer or 
>>> freeview to identify a possible error in the wm.mgz or filled.mgz to 
>>> correct it manually?
>>>
>>>
>>>
>>> Thanks in advance,
>>>
>>> Falk
>>>
>>> 
>>> -
>>> ---
>>>
>>> ___
>>> 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] mri_normalize -noconform flag doesn't work in FS 5.0

[Falk Lüsebrink]

Dear FreeSurfers,

 

The –noconform flag of mri_normalize doesn’t seem to work properly in the
centos4_x86_64_stable-pub-v5.0.0 build. I have been trying to process a
volume with an isotropic resolution of 0.7mm using

 

recon-all –cm –autorecon1 –s 

 

as the command line. The conformation is skipped until mri_normalize, but
afterwards the output volume T1.mgz is conformed. Although the log during
mri_normalize says:

 

“not interpolating and embedding volume to be 256^3…”

 

I have been trying to run it using the recon-all script and running
mri_normalize by hand, the error is the same. A fix is highly appreciated.

 

Thanks,

Falk Lüsebrink

___
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] -noconform flag of mri_normalize doesn't work

[Falk Lüsebrink]

Dear FreeSurfers,

The -noconform flag of mri_normalize doesn't seem to work properly in the 
centos4_x86_64_stable-pub-v5.0.0 build. I have been trying to process a volume 
with a native isotropic resolution of 0.7mm using recon-ll including the -cm 
flag to conform the input to minimum. But during the normalization of 
mri_normalize the volume is conformed to an isotropic resolution of 1mm.

The flag is correctly used during mri_normalize, but it doesn't seem to do 
anything. The recon-all log says:

"not interpolating and embedding volume to be 256^3..."

But the output volume T1.mgz is conformed to 256^3 and therefore to an 
isotropic resolution of 1mm. This also happens if mri_normalize is used by hand 
using the -noconform flag. 

A fix is highly appreciated.

Thanks in advance,
Falk Lüsebrink


___
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] -noconform flag of mri_normalize doesn't work

[Falk Lüsebrink]

Hi Bruce,

I'm so sorry, I should have double-checked. You are completely right; 
mri_normalize does work perfectly fine. The conformation to 1mm isotropic is 
done in the last step of mri_nu_correct.mni.

In the last step of mri_nu_correct.mni the --conform flag is used, which 
shouldn't be used:



mri_convert ./tmp.mri_nu_correct.mni.32343/nu1.mnc nu.mgz --like orig.mgz 
--conform
mri_convert ./tmp.mri_nu_correct.mni.32343/nu1.mnc nu.mgz --like orig.mgz 
--conform 
$Id: mri_convert.c,v 1.166.2.2 2010/08/10 19:11:50 greve Exp $
reading from ./tmp.mri_nu_correct.mni.32343/nu1.mnc...
TR=0.00, TE=0.00, TI=0.00, flip angle=0.00
i_ras = (-1, 0, 2.12874e-08)
j_ras = (3.72529e-08, 0, -1)
k_ras = (0, 1, 0)
Original Data has (0.7, 0.7, 0.7) mm size and (321, 321, 321) voxels.
Data is conformed to 1 mm size and 256 voxels for all directions
INFO: transform src into the like-volume: orig.mgz
changing data type from float to uchar (noscale = 0)...
MRIchangeType: Building histogram 
Reslicing using trilinear interpolation 
writing to nu.mgz...
 
 
Wed Nov 10 10:47:32 CET 2010
mri_nu_correct.mni done



Also attached is the recon-all.log and the output of mri_info of orig.mgz and 
nu.mgz.

Thanks again,
Falk Lüsebrink


 Original-Nachricht 
> Datum: Tue, 9 Nov 2010 21:06:49 -0500 (EST)
> Von: Bruce Fischl 
> An: "Falk Lüsebrink" 
> CC: freesurfer@nmr.mgh.harvard.edu
> Betreff: Re: [Freesurfer] -noconform flag of mri_normalize doesn\'t work

> Hi Falk,
> 
> I just tried it and it seemed to work for me:
> 
> mri_info Gaab20070225a/mri/rawavg.mgz
> Volume information for Gaab20070225a/mri/rawavg.mgz
>type: MGH
>  dimensions: 256 x 256 x 128
> voxel sizes: 1., 1., 1.3300
>type: SHORT (4)
> fov: 256.000
> dof: 0
>  xstart: -128.0, xend: 128.0
>  ystart: -128.0, yend: 128.0
>  zstart: -85.1, zend: 85.1
>  TR: 2000.00 msec, TE: 3.44 msec, TI: 900.00 msec, flip angle:
> 9.00 degrees
> nframes: 1
> PhEncDir: ROW
> ras xform present
>  xform info: x_r =   0.5924, y_r =   0.0086, z_r =  -0.8056, c_r = 
> -9.9942
>: x_a =  -0.7780, y_a =  -0.2537, z_a =  -0.5747, c_a = 
> 13.5548
>: x_s =   0.2093, y_s =  -0.9672, z_s =   0.1436, c_s = 
> -22.2562
> 
> mri_normalize -noconform rawavg.mgz test.mgz
> not interpolating and embedding volume to be 256^3...
> reading from rawavg.mgz...
> normalizing image...
> MRInormInit:
> Talairach origin at (142, 110, 71)
> wsize 10, windows 14 above, 9 below
> max gradient 1.000
> .
> .
> .
> mri_info test.mgz
> Volume information for test.mgz
>type: MGH
>  dimensions: 256 x 256 x 128
> voxel sizes: 1., 1., 1.3300
>type: SHORT (4)
> fov: 256.000
> dof: 0
>  xstart: -128.0, xend: 128.0
>  ystart: -128.0, yend: 128.0
>  zstart: -85.1, zend: 85.1
>  TR: 2000.00 msec, TE: 3.44 msec, TI: 900.00 msec, flip angle:
> 9.00 degrees
> nframes: 1
> PhEncDir: UNKNOWN
> ras xform present
>  xform info: x_r =   0.5924, y_r =   0.0086, z_r =  -0.8056, c_r = 
> -9.9942
>    : x_a =  -0.7780, y_a =  -0.2537, z_a =  -0.5747, c_a = 
> 13.5548
>: x_s =   0.2093, y_s =  -0.9672, z_s =   0.1436, c_s = 
> -22.2562
> 
> 
> 
> On Tue, 9 Nov 2010, Falk 
> Lüsebrink wrote:
> 
> > Dear FreeSurfers,
> >
> > The -noconform flag of mri_normalize doesn't seem to work properly in
> the centos4_x86_64_stable-pub-v5.0.0 build. I have been trying to process a
> volume with a native isotropic resolution of 0.7mm using recon-ll including
> the -cm flag to conform the input to minimum. But during the normalization
> of mri_normalize the volume is conformed to an isotropic resolution of 1mm.
> >
> > The flag is correctly used during mri_normalize, but it doesn't seem to
> do anything. The recon-all log says:
> >
> > "not interpolating and embedding volume to be 256^3..."
> >
> > But the output volume T1.mgz is conformed to 256^3 and therefore to an
> isotropic resolution of 1mm. This also happens if mri_normalize is used by
> hand using the -noconform flag.
> >
> > A fix is highly appreciated.
> >
> > Thanks in advance,
> > Falk Lüsebrink
> >
> >
> >

-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
Wed Nov 10 10:42:35 CET 2010
/home/falk/freesurfer/subjects/test_shan
/usr/share/freesurfer/bin/recon-all
-cm -autorecon

Re: [Freesurfer] -noconform flag of mri_normalize doesn't work

[Falk Lüsebrink]

Hi Bruce,

I'm trying to process data with a higher native resolution than 1mm^3 in
order to investigate whether a better resolution leads to more accurate
results in terms of cortical thickness.

Best,
Falk Lüsebrink

-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Bruce Fischl
Sent: Wednesday, November 10, 2010 2:18 PM
To: "Falk Lüsebrink"
Cc: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] -noconform flag of mri_normalize doesn't work

Hi Falk,

can you give us a big picture of what you are trying to accomplish?

Bruce
On Wed, 
10 Nov 2010, "Falk Lüsebrink" wrote:

> Hi Bruce,
>
> I'm so sorry, I should have double-checked. You are completely right;
mri_normalize does work perfectly fine. The conformation to 1mm isotropic is
done in the last step of mri_nu_correct.mni.
>
> In the last step of mri_nu_correct.mni the --conform flag is used, which
shouldn't be used:
>
> 
>
> mri_convert ./tmp.mri_nu_correct.mni.32343/nu1.mnc nu.mgz --like orig.mgz
--conform
> mri_convert ./tmp.mri_nu_correct.mni.32343/nu1.mnc nu.mgz --like orig.mgz
--conform
> $Id: mri_convert.c,v 1.166.2.2 2010/08/10 19:11:50 greve Exp $
> reading from ./tmp.mri_nu_correct.mni.32343/nu1.mnc...
> TR=0.00, TE=0.00, TI=0.00, flip angle=0.00
> i_ras = (-1, 0, 2.12874e-08)
> j_ras = (3.72529e-08, 0, -1)
> k_ras = (0, 1, 0)
> Original Data has (0.7, 0.7, 0.7) mm size and (321, 321, 321) voxels.
> Data is conformed to 1 mm size and 256 voxels for all directions
> INFO: transform src into the like-volume: orig.mgz
> changing data type from float to uchar (noscale = 0)...
> MRIchangeType: Building histogram
> Reslicing using trilinear interpolation
> writing to nu.mgz...
>
>
> Wed Nov 10 10:47:32 CET 2010
> mri_nu_correct.mni done
>
> ****
>
> Also attached is the recon-all.log and the output of mri_info of orig.mgz
and nu.mgz.
>
> Thanks again,
> Falk Lüsebrink
>
>
>  Original-Nachricht 
>> Datum: Tue, 9 Nov 2010 21:06:49 -0500 (EST)
>> Von: Bruce Fischl 
>> An: "Falk Lüsebrink" 
>> CC: freesurfer@nmr.mgh.harvard.edu
>> Betreff: Re: [Freesurfer] -noconform flag of mri_normalize doesn\'t work
>
>> Hi Falk,
>>
>> I just tried it and it seemed to work for me:
>>
>> mri_info Gaab20070225a/mri/rawavg.mgz
>> Volume information for Gaab20070225a/mri/rawavg.mgz
>>type: MGH
>>  dimensions: 256 x 256 x 128
>> voxel sizes: 1., 1., 1.3300
>>type: SHORT (4)
>> fov: 256.000
>> dof: 0
>>  xstart: -128.0, xend: 128.0
>>  ystart: -128.0, yend: 128.0
>>  zstart: -85.1, zend: 85.1
>>  TR: 2000.00 msec, TE: 3.44 msec, TI: 900.00 msec, flip
angle:
>> 9.00 degrees
>> nframes: 1
>> PhEncDir: ROW
>> ras xform present
>>  xform info: x_r =   0.5924, y_r =   0.0086, z_r =  -0.8056, c_r =
>> -9.9942
>>: x_a =  -0.7780, y_a =  -0.2537, z_a =  -0.5747, c_a =
>> 13.5548
>>: x_s =   0.2093, y_s =  -0.9672, z_s =   0.1436, c_s =
>> -22.2562
>>
>> mri_normalize -noconform rawavg.mgz test.mgz
>> not interpolating and embedding volume to be 256^3...
>> reading from rawavg.mgz...
>> normalizing image...
>> MRInormInit:
>> Talairach origin at (142, 110, 71)
>> wsize 10, windows 14 above, 9 below
>> max gradient 1.000
>> .
>> .
>> .
>> mri_info test.mgz
>> Volume information for test.mgz
>>type: MGH
>>  dimensions: 256 x 256 x 128
>> voxel sizes: 1., 1., 1.3300
>>type: SHORT (4)
>> fov: 256.000
>> dof: 0
>>  xstart: -128.0, xend: 128.0
>>  ystart: -128.0, yend: 128.0
>>  zstart: -85.1, zend: 85.1
>>  TR: 2000.00 msec, TE: 3.44 msec, TI: 900.00 msec, flip
angle:
>> 9.00 degrees
>> nframes: 1
>> PhEncDir: UNKNOWN
>> ras xform present
>>  xform info: x_r =   0.5924, y_r =   0.0086, z_r =  -0.8056, c_r =
>> -9.9942
>>: x_a =  -0.7780, y_a =  -0.2537, z_a =  -0.5747, c_a =
>> 13.5548
>>: x_s =   0.2093, y_s =  -0.9672, z_s =   0.1436, c_s =
>> -22.2562
>>
>>
>>
>> On Tue, 9 Nov 2010, Falk
>> Lüsebrink wrote:
>>
>>> Dear FreeSurfers,
>>>
>>> The -noconform flag of mri_normalize doesn't seem to work