Re: [Freesurfer] tksurfer vertex location

[Nabin Koirala]

Dear Doug,

Thank you for the repy but may be couple of things. One, when I used the
above command it said segmentation volume is missing , so I added the
segmentation volume as in the command below and it worked and I also got
the out.dat but not as I wanted. With this command :

mri_segstats --seg /home/freesurfer/subjects/qdec/Untitled/y.mgh --vox
10157 0 0 --id 1 --i ./qdec/Untitled/./Cor/sig.mgh --avgwf
./qdec/out.dat

Output was -5.718 , which was the log of p-value for that voxel. What I
wanted is the (say) thickness values for all the subjects in that voxel
(example as shown below), which is shown in this plot normally. I could get
it from the GUI from tksurfer by typing the vertex as you mentioned but not
with the command line yet.

Sub_10 Main 122.0 -0.0433319658041 0
Sub_101 Main 219.0 0.022786360234 0
Sub_104 Main 363.0 0.0189986526966 0
Sub_105 Main 687.0 -0.216253831983 0
Sub_106 Main 764.0 -0.763142108917 0
Sub_107 Main 175.0 0.067133423 0
Sub_108 Main 203.0 -0.0709587186575 0
Sub_109 Main 122.0 0.109558776021 0

Should I change something in the command line above ?

Many thanks again for your support.

Regards,
Nabin

On Mon, Jan 23, 2017 at 6:21 PM, Douglas N Greve 
wrote:

> btw, in tksurfer you can type the vertex no you want into the vertex
> field. If you want to extract it programatically, then you can run
> something like
>
> mri_segstats --vox vertexno 0 0 --id 1 --i yoursurfacemap.mgh --avgwf
> out.dat
>
>
> On 01/23/2017 05:29 AM, Nabin Koirala wrote:
> > Dear Bruce,
> >
> > Thank you for the reply but as you mentioned that tksurfer is
> > deprecated, is it possible to do the same from QDEC ? i.e Can I get
> > all the values from the plot (or save the plot) which we get in QDEC
> > for significant cluster ?
> >
> > Thank you.
> >
> > Regards,
> > Nabin
> >
> > On Fri, Jan 20, 2017 at 4:06 PM, Bruce Fischl
> > mailto:fis...@nmr.mgh.harvard.edu>> wrote:
> >
> > Hi Nabin
> >
> > note that tksurfer is deprecated - we are not developing it anymore.
> >
> > That said, I thing you can type:
> >
> > select_vertex_by_vno 
> >
> > at the tcl prompt, where  is the number of the vertex you want
> > to select
> >
> > cheers
> > Bruce
> >
> >
> >
> >
> > On Fri, 20 Jan 2017, Nabin Koirala wrote:
> >
> > Dear freesurfer team,
> > I was trying to obtain the values at a vertex in tksurfer and
> > this is what
> > is written in tksurfer manual.
> >
> > At first, an empty plot will be displayed in a separate
> > window. To
> > generate a plot for a particular vertex, select a point by
> > clicking on the
> > parametric map at that vertex and the plot window will be updated
> > accordingly.
> >
> > But is it possible to enter the desired vertex and get the
> > plot rather than
> > trying to point the mouse to exact vertex and update the plot
> > because it
> > looks like I am not good at pointing mouse to exact vertex I
> > want.
> >
> > Thank you and excuse me for the naive query.
> >
> > Best,
> > Nabin
> >
> >
> > ___
> > Freesurfer mailing list
> > Freesurfer@nmr.mgh.harvard.edu  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
>
> --
> Douglas N. Greve, Ph.D.
> MGH-NMR Center
> gr...@nmr.mgh.harvard.edu
> Phone Number: 617-724-2358
> Fax: 617-726-7422
>
> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
> www.nmr.mgh.harvard.edu/facility/filedrop/index.html
> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
___
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 o

[Freesurfer] trac-all bug: using #!/bin/sh instead of #!/bin/bash in scripts which use bash-only syntax extensions

[Parzer, Peter]

Hi,

there is a bug in the scripts bedpostx_mgh and fsl_sub_mgh. Both use code that 
do not conform to the standard shell syntax and work only with bash. This does 
not work in system that do not link /bin/sh to /bin/bash (as is the case in 
Ubuntu). Both scripts must use #!/bin/bash as the interpreter command in the 
first line. 

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] QDEC - Controlling for gender

[Jennifer Szeto]

Hi Doug,


That doesn't seem to work either? Is there anything else I should try/ does 
my fsgd file look alright?


Thanks for your help,

Jen



From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Douglas N Greve 

Sent: 24 January 2017 04:28
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] QDEC - Controlling for gender

Have you tried normalizing BDI and age? By normalizing, I mean
subtracting the mean and dividing by the stddev


On 01/20/2017 05:46 PM, Jennifer Szeto wrote:
>
> Sorry, hope this is the right one!
>
>
> Thanks,
>
> Jen
>
>
>
> 
> *From:* freesurfer-boun...@nmr.mgh.harvard.edu
>  on behalf of Douglas Greve
> 
> *Sent:* 20 January 2017 22:26
> *To:* freesurfer@nmr.mgh.harvard.edu
> *Subject:* Re: [Freesurfer] QDEC - Controlling for gender
>
> sorry, I wanted the y.fsgd file from the qdec output directory
>
>
> On 1/20/17 4:46 PM, Jennifer Szeto wrote:
>>
>> Thank you very much Doug,
>>
>>
>> Please find attached the files I have been using to run the QDEC
>> analyses.
>>
>>
>> Jen
>>
>>
>>
>> 
>> *From:* freesurfer-boun...@nmr.mgh.harvard.edu
>>  on behalf of Douglas Greve
>> 
>> *Sent:* 20 January 2017 15:27
>> *To:* freesurfer@nmr.mgh.harvard.edu
>> *Subject:* Re: [Freesurfer] QDEC - Controlling for gender
>>
>> can you send the fsgd file?
>>
>>
>> On 1/20/17 6:54 AM, Jennifer Szeto wrote:
>>>
>>> Thanks Doug,
>>>
>>>
>>> That seem to work for some of my variables (e.g. depression) when I
>>> put gender and diagnosis as fixed factors, depression as covariate,
>>> and age as nuisance factor but not for others (e.g. anxiety). I keep
>>> getting error messages when trying to run some of my variables as
>>> covariates (please see attached). Is there anything I can do to fix
>>> this?
>>>
>>>
>>> Thanks,
>>> Jen
>>>
>>> 
>>> *From:* freesurfer-boun...@nmr.mgh.harvard.edu
>>>  on behalf of Douglas N
>>> Greve 
>>> *Sent:* 19 January 2017 21:48
>>> *To:* freesurfer@nmr.mgh.harvard.edu
>>> *Subject:* Re: [Freesurfer] QDEC - Controlling for gender
>>> Just include it as a categorical factor. When you look at your contrast
>>> of interest, it will be with respect to regressing out gender
>>>
>>>
>>> On 01/15/2017 08:55 PM, Jennifer Szeto wrote:
>>> >
>>> > Hi Freesurfer experts,
>>> >
>>> >
>>> > I am trying to compare cortical thickness between groups while
>>> > controlling for age and gender using QDEC. However, _gender_ is not
>>> > showing up as a covariate variable or a nuisance factor (only showing
>>> > up as a fixed factor), I am wondering how I could control for gender
>>> > in this case?
>>> >
>>> >
>>> > Thank you very much,
>>> >
>>> > Jen
>>> >
>>> >
>>> >
>>> > ___
>>> > Freesurfer mailing list
>>> > Freesurfer@nmr.mgh.harvard.edu
>>> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Freesurfer Info Page - 
mail.nmr.mgh.harvard.edu
mail.nmr.mgh.harvard.edu
To see the collection of prior postings to the list, visit the Freesurfer 
Archives. A searchable archive which of messages PRIOR to March 2004 is at ...



>>> Freesurfer Info Page - Harvard University
>>> 
Freesurfer Info Page - 
mail.nmr.mgh.harvard.edu
mail.nmr.mgh.harvard.edu
To see the collection of prior postings to the list, visit the Freesurfer 
Archives. A searchable archive which of messages PRIOR to March 2004 is at ...



>>> mail.nmr.mgh.harvard.edu
>>> To see the collection of prior postings to the list, visit the
>>> Freesurfer Archives. A searchable archive which of messages PRIOR to
>>> March 2004 is at ...
>>>
>>>
>>>
>>>
>>> --
>>> Douglas N. Greve, Ph.D.
>>> MGH-NMR Center
>>> gr...@nmr.mgh.harvard.edu
>>> Phone Number: 617-724-2358
>>> Fax: 617-726-7422
>>>
>>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
>>> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
FileDrop v2.0 - Martinos Center for Biomedical 
Imaging
gate.nmr.mgh.harvard.edu
Filedrop is for sending files work-related files up to 2GiB; For files over 
2GiB, please use the Accellion File Transfer from Partners; Filedrop is not a 
secure ...



>>> FileDrop v2.0 - Martinos Center for Biomedical Imaging
>>> 
FileDrop v2.0 - Martinos Center for Biomedical 
Imaging
gate.nmr.mgh.harvard.edu
Filedrop is for sending files work-related files up to 2GiB; For files over 
2GiB, please use the Accellion File Transfer from Partners; Filedrop is not a 
secure ...



>>> gate.nmr.mgh.harvard.edu
>>> Filedrop is for s

[Freesurfer] Hippocampal Subfields Segmentation Error

[Michel Hu]

Dear Freesurfer Developers,

For my research I'm trying to run the hippocampal subfield segmentation 
analysis however, I keep running into the following error. I tried to solve it 
by myself however I had no luck ( I tried by removing the exec flag from the 
files ).

I'm using the following sofftware
Freesurfer : freesurfer-Linux-centos6_x86_64-dev-20170103-696bbc1
Ubuntu: 14.04.5 LTS
WIndows 10


michel@-:~$ recon-all -s bob -hippocampal-subfields-T1
Subject Stamp: freesurfer-Linux-centos6_x86_64-dev-20170103-696bbc1
Current Stamp: freesurfer-Linux-centos6_x86_64-dev-20170103-696bbc1
INFO: SUBJECTS_DIR is /usr/local/freesurfer/subjects
Actual FREESURFER_HOME /usr/local/freesurfer
-rw-rw-r-- 1 michel 1590 1249629 Jan 24 13:40 
/usr/local/freesurfer/subjects/bob/scripts/recon-all.log
Linux - 3.4.0+ #1 PREEMPT Thu Aug 1 17:06:05 CST 2013 x86_64 x86_64 x86_64 
GNU/Linux
'/usr/local/freesurfer/bin/recon-all' -> 
'/usr/local/freesurfer/subjects/bob/scripts/recon-all.local-copy'
#
#@# Hippocampal Subfields processing (T1 only) left Tue Jan 24 13:43:46 STD 2017

 /usr/local/freesurfer/bin/segmentSF_T1.sh /usr/local/freesurfer/MCRv80 
/usr/local/freesurfer bob /usr/local/freesurfer/subjects left

See log file: 
/usr/local/freesurfer/subjects/bob/scripts/hippocampal-subfields-T1.log
--
Setting up environment variables
---
LD_LIBRARY_PATH is 
.:/usr/local/freesurfer/MCRv80/runtime/glnxa64:/usr/local/freesurfer/MCRv80/bin/glnxa64:/usr/local/freesurfer/MCRv80/sys/os/glnxa64:/usr/local/freesurfer/MCRv80/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/usr/local/freesurfer/MCRv80/sys/java/jre/glnxa64/jre/lib/amd64/server:/usr/local/freesurfer/MCRv80/sys/java/jre/glnxa64/jre/lib/amd64/client:/usr/local/freesurfer/MCRv80/sys/java/jre/glnxa64/jre/lib/amd64:
/usr/local/freesurfer/bin/segmentSubjectT1_autoEstimateAlveusML: error while 
loading shared libraries: libut.so: cannot enable executable stack as shared 
object requires: Invalid argument
#
#@# Hippocampal Subfields processing (T1 only) right Tue Jan 24 13:43:46 STD 
2017

 /usr/local/freesurfer/bin/segmentSF_T1.sh /usr/local/freesurfer/MCRv80 
/usr/local/freesurfer bob /usr/local/freesurfer/subjects right

See log file: 
/usr/local/freesurfer/subjects/bob/scripts/hippocampal-subfields-T1.log
--
Setting up environment variables
---
LD_LIBRARY_PATH is 
.:/usr/local/freesurfer/MCRv80/runtime/glnxa64:/usr/local/freesurfer/MCRv80/bin/glnxa64:/usr/local/freesurfer/MCRv80/sys/os/glnxa64:/usr/local/freesurfer/MCRv80/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/usr/local/freesurfer/MCRv80/sys/java/jre/glnxa64/jre/lib/amd64/server:/usr/local/freesurfer/MCRv80/sys/java/jre/glnxa64/jre/lib/amd64/client:/usr/local/freesurfer/MCRv80/sys/java/jre/glnxa64/jre/lib/amd64:
/usr/local/freesurfer/bin/segmentSubjectT1_autoEstimateAlveusML: error while 
loading shared libraries: libut.so: cannot enable executable stack as shared 
object requires: Invalid argument

Started at Tue Jan 24 13:43:45 STD 2017
Ended   at Tue Jan 24 13:43:47 STD 2017
#@#%# recon-all-run-time-hours 0.001
recon-all -s bob finished without error at Tue Jan 24 13:43:47 STD 2017
done

Sincerely,
Michel

___
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] Some questions about coordinate systems

[Hsin-Tsung Lee]

Dear Freesurfer experts:

   My project objective is to build 3D reconstruction of brain with
inserted electrodes. I want register the Brian volume of CT and MR via
freesurfer. The registration result looks great when I used th "mri_coreg"
instruction, but when I tried to use the information in lta data to
register by myself, some trouble happens.


The LTA data
--
# transform file p19_movCT2refMR.lta
# created by caca on Tue Jan 24 17:45:08 2017

type  = 0 # LINEAR_VOX_TO_VOX
nxforms   = 1
mean  = 0. 0. 0.
sigma = 1.
1 4 4
4.795561134815216e-01 -1.318652089685202e-02 -2.057363465428352e-02
1.383309745788574e+01
1.247252989560366e-02 4.785549342632294e-01 -6.737518310546875e-02
1.315915203094482e+01
1.107159163802862e-02 3.306149691343307e-02 9.974335432052612e-01
-6.133582305908203e+01
0.000e+00 0.000e+00 0.000e+00
1.000e+00
src volume info
valid = 1  # volume info valid
filename = patient19CT.nii
volume = 512 512 228
voxelsize = 4.873275756835938e-01 4.873275756835938e-01
9.71985816956e-01
xras   = -9.993908405303955e-01 -0.000e+00 3.489949554204941e-02
yras   = -0.000e+00 1.000e+00 -0.000e+00
zras   = 3.489949554204941e-02 0.000e+00 9.993908405303955e-01
cras   = 7.39746093750e-02 -1.105121917724609e+02 1.181088867187500e+02
dst volume info
valid = 1  # volume info valid
filename = patient19MR.nii
volume = 256 256 192
voxelsize = 1.015599966049194e+00 1.015599966049194e+00
1.01072883606e+00
xras   = -1.000e+00 -0.000e+00 0.000e+00
yras   = -0.000e+00 1.000e+00 -0.000e+00
zras   = -0.000e+00 -0.000e+00 1.000e+00
cras   = 3.934204101562500e+00 2.904579925537109e+01 1.511990356445312e+01
subject unknown
---

First I thought the 4x4 matrix is the affine matrix (type = VOX_TO_VOX)

4.795561134815216e-01 -1.318652089685202e-02 -2.057363465428352e-02
1.383309745788574e+01
1.247252989560366e-02 4.785549342632294e-01 -6.737518310546875e-02
1.315915203094482e+01
1.107159163802862e-02 3.306149691343307e-02 9.974335432052612e-01
-6.133582305908203e+01
0.000e+00 0.000e+00 0.000e+00
1.000e+00

After I studied the document "FS Coordinates (PDF)"  at the following URL :
http://freesurfer.net/fswiki/CoordinateSystems
there are some question :

I thought in my case correspond to the page 3 condition "Two Fields of
View, Two Coordinate Systems"
But I am not sure that that does the affine matrix above is the vox_to_vox
matrix or not. If it is, could I use it directly to compute the
corresponding voxel location between 2 volume? or I need additional
coordinate transfer?


Sincerely,
Hsintsung
___
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] REPOST: Regarding: Habenula ROI

[Dr Sampada Sinha]

Dear freesurfer experts,

Is it possible to create Habenula as region of interest from fsaverage
(orig.mgz images) using tkmedit? I will be using following links to guide
me for creating Habenular region of interest. Hope my question is answered
since the next question is related to this please.

https://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/AnatomicalROI_tktools

http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/AnatomicalROI/
FreeSurferColorLUT

Thanks for your help.

Kind regards,

Sampada

-- 
Sampada
​Research medical scientist (B)​
Department of Geriatric Mental Health (DGMH)
King George Medical University
Lucknow-226003
​, Uttar Pradesh​
India











-- 
Sampada
​Research medical scientist (B)​
Department of Geriatric Mental Health (DGMH)
King George Medical University
Lucknow-226003
​, Uttar Pradesh​
India
___
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] REPOST: Regarding: Habenula ROI

[Bruce Fischl]

Hi Sampada

we don't automatically label habenula yet, but certainly you can draw it 
using freeview. Was that your question?


cheers
Bruce

On Tue, 24 Jan 2017, Dr Sampada Sinha wrote:


Dear freesurfer experts,

Is it possible to create Habenula as region of interest from fsaverage
(orig.mgz images) using tkmedit? I will be using following links to guide me
for creating Habenular region of interest. Hope my question is answered
since the next question is related to this please.

https://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/AnatomicalROI_tktools

http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/AnatomicalROI/FreeSurfe
rColorLUT

Thanks for your help.

Kind regards,

Sampada

--
Sampada
​Research medical scientist (B)​
Department of Geriatric Mental Health (DGMH)
King George Medical University
Lucknow-226003​, Uttar Pradesh​
India











--
Sampada
​Research medical scientist (B)​
Department of Geriatric Mental Health (DGMH)
King George Medical University
Lucknow-226003​, Uttar Pradesh​
India










___
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] FS6 recon-all hangs at mris_fix_topology

[Bruce Fischl]

Hi Matt
looks like you ahve a pretty big (almost 18K vertices) defect. It will 
eventually fix it, but possibly not in the correct way. You can load the 
lh.inflated.nofix in freeview and theoverlay lh.defect_labels to see 
what's going on (this is the first defect). It may be that some of the 
skull was left around or the cerebellum or something, in which case you'll 
want to manually correct the wm.mgz to remove the non-brain tissue


cheers
Bruce


On Tue, 24 Jan 2017, Hibert, 
Matthew Louis wrote:



Hi Freesurfer Devs,
I'm trying to re-process a subject who had a right temporal lobectomy using
FS6 but the recon hangs at the mris_fix_topology step, saying "XL defect
detected...".  It continues to use a CPU for several days if allowed, but
does not actually progress from that point.  This scan was able to be
processed in both stable 4 and stable 5.3.  I've attached the recon-all log
from the recon using the Martinos installation of "stable6".  Any
suggestions?

Thanks,
Matt

___
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] FS6 recon-all hangs at mris_fix_topology

[Bruce Fischl]

Hi Matt

you only need to edit them if the lh.orig.nofix surface includes them. 
Otherwise they are fine. The first defect will be near the back of the 
brain

cheers
Bruce

On Tue, 24 Jan 2017, Hibert, 
Matthew Louis wrote:

> Hi Bruce,
> Thanks, it does look like there is some skull included in the brainmask.mgz 
> and wm.mgz in many locations (very noisy scan).  I'll edit those out and give 
> it another try.
>
> Matt
> 
> From: freesurfer-boun...@nmr.mgh.harvard.edu 
> [freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Bruce Fischl 
> [fis...@nmr.mgh.harvard.edu]
> Sent: Tuesday, January 24, 2017 9:58 AM
> To: Freesurfer support list
> Subject: Re: [Freesurfer] FS6 recon-all hangs at mris_fix_topology
>
> Hi Matt
> looks like you ahve a pretty big (almost 18K vertices) defect. It will
> eventually fix it, but possibly not in the correct way. You can load the
> lh.inflated.nofix in freeview and theoverlay lh.defect_labels to see
> what's going on (this is the first defect). It may be that some of the
> skull was left around or the cerebellum or something, in which case you'll
> want to manually correct the wm.mgz to remove the non-brain tissue
>
> cheers
> Bruce
>
>
> On Tue, 24 Jan 2017, Hibert,
> Matthew Louis wrote:
>
>> Hi Freesurfer Devs,
>> I'm trying to re-process a subject who had a right temporal lobectomy using
>> FS6 but the recon hangs at the mris_fix_topology step, saying "XL defect
>> detected...".  It continues to use a CPU for several days if allowed, but
>> does not actually progress from that point.  This scan was able to be
>> processed in both stable 4 and stable 5.3.  I've attached the recon-all log
>> from the recon using the Martinos installation of "stable6".  Any
>> suggestions?
>>
>> Thanks,
>> Matt
>>
>>
>
> ___
> 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] FS6 recon-all hangs at mris_fix_topology

[Hibert, Matthew Louis]

Hi Bruce,
Thanks, it does look like there is some skull included in the brainmask.mgz and 
wm.mgz in many locations (very noisy scan).  I'll edit those out and give it 
another try.

Matt

From: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Bruce Fischl 
[fis...@nmr.mgh.harvard.edu]
Sent: Tuesday, January 24, 2017 9:58 AM
To: Freesurfer support list
Subject: Re: [Freesurfer] FS6 recon-all hangs at mris_fix_topology

Hi Matt
looks like you ahve a pretty big (almost 18K vertices) defect. It will
eventually fix it, but possibly not in the correct way. You can load the
lh.inflated.nofix in freeview and theoverlay lh.defect_labels to see
what's going on (this is the first defect). It may be that some of the
skull was left around or the cerebellum or something, in which case you'll
want to manually correct the wm.mgz to remove the non-brain tissue

cheers
Bruce


On Tue, 24 Jan 2017, Hibert,
Matthew Louis wrote:

> Hi Freesurfer Devs,
> I'm trying to re-process a subject who had a right temporal lobectomy using
> FS6 but the recon hangs at the mris_fix_topology step, saying "XL defect
> detected...".  It continues to use a CPU for several days if allowed, but
> does not actually progress from that point.  This scan was able to be
> processed in both stable 4 and stable 5.3.  I've attached the recon-all log
> from the recon using the Martinos installation of "stable6".  Any
> suggestions?
>
> Thanks,
> Matt
>
>

___
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] Extracting significant clusters after qdec analyses

[Katherine Damme]

Thanks Douglas. I am not sure that I understand. Will you please review the
commands below?

I believe I need to complete something like:

mri_surfcluster --in ${qdecoutputfolder}/cache.th40.abs.sig.masked.mgh
--fdr 0.05 --mask ${qdecoutputfolder}/mask.mgh --csd
/usr/local/freesurfer/average/mult-comp-cor/rh/cortex/fwhm25/abs/th40/mc-z.csd
--surf pial --ocn ${qdecoutputfolder}/

Which puts out a *.w file, a COR-00#, and COR.info, but I am not sure which
file I should supply to -- seg

mri_segstats --seg ??  --i y.mgh --avgfw ${nameoftextoutput}  --exludeid 0

Could I supply the ocn file from the mri_glmfit-sim?


On Mon, Jan 23, 2017 at 7:10 PM, Douglas N Greve 
wrote:

> It is probably better to work with the y.mgh file that qdec produces. It
> is in fsaverage space. If you create an ocn file with mri_surfcluster, you
> can feed that as the --seg to mri_segstats (along with --i y.mgh), spec the
> output with --avgwf to get a matrix of nsubjects  by nclusters (make sure
> to also include --exludeid 0)
>
>
> On 01/23/2017 08:00 PM, Katherine Damme wrote:
>
>> Thank you so much!
>>
>> This got me to the stage of having separate labels for each significant
>> cluster, but I would like to extract the values from each subject to look
>> at the raw data.
>>
>> Do I have to use mri_label2label to move the label into each individual's
>> space?
>>
>> Can I use aparcstats2table to get a table of the individual values of the
>> label?
>> (It seems that this is set up for the segmentation data)
>>
>> Thank you again!
>>
>>
>> On Mon, Jan 23, 2017 at 11:44 AM, Douglas N Greve <
>> gr...@nmr.mgh.harvard.edu > wrote:
>>
>> Try mri_surfcluster. Run it with --help to get usage. You can set the
>> threshold with --fdr. Make sure to use the --mask option passing
>> it the
>> mask.mgh from the qdec  output
>>
>>
>> On 01/22/2017 07:56 PM, Katherine Damme wrote:
>> > Hello Everyone,
>> >
>> > Is there a way to extract the significant clusters as masks from
>> > significant group comparisons using qdec?
>> >
>> > All I can seem to find is  mri_glmfit-sim which doesn't quite
>> > replicate the QDEC FDR 0.05 output and doesn't seem to make anything
>> > that I could extract as a label, or hand drawing an ROI.
>> >
>> > I am working with a longitudinal model of cortical thickness, and
>> > would like to extract the average thickness of each significant
>> > cluster to understand the change in thickness.
>> >
>> > Thank you.
>> >
>> > Kate Damme
>> >
>> >
>> > ___
>> > Freesurfer mailing list
>> > Freesurfer@nmr.mgh.harvard.edu
>> 
>> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>> 
>>
>> --
>> Douglas N. Greve, Ph.D.
>> MGH-NMR Center
>> gr...@nmr.mgh.harvard.edu 
>> Phone Number: 617-724-2358 
>> Fax: 617-726-7422 
>>
>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
>> 
>> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
>> 
>> www.nmr.mgh.harvard.edu/facility/filedrop/index.html
>> 
>> Outgoing:
>> ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
>> 
>>
>> ___
>> Freesurfer mailing list
>> Freesurfer@nmr.mgh.harvard.edu > >
>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>> 
>>
>>
>> The information in this e-mail is intended only for the person to
>> whom it is
>> addressed. If you believe this e-mail was sent to you in error and
>> the e-mail
>> contains patient information, please contact the Partners
>> Compliance HelpLine at
>> http://www.partners.org/complianceline
>>  . If the e-mail was sent
>> to you in error
>> but does not contain patient information, please contact the
>> sender and properly
>> dispose of the e-mail.
>>
>>
>>
> --
> Douglas N. Greve, Ph.D.
> MGH-NMR Center
> gr...@nmr.mgh.harvard.edu
> Phone Number: 617-724-2358
> Fax: 617-726-7422
>
> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
> www.nmr.mgh.harvard.edu/facility/filedrop/index.html
> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.

Re: [Freesurfer] How high resolution for -hires in FS6.0

[Bruce Fischl]

Hi Alex

cut it for what?

Bruce

On Tue, 24 Jan 2017, Alex Cohen wrote:

> So what resolution would make sense to use? the release notes say <1.0mm but
> would 0.9mm isovol really cut it?
> -Alex
> 
> 
> Alexander Li Cohen, M.D., Ph.D.
> E-mail: alexander.coh...@childrens.harvard.edu (Medical/Science Email)
> E-mail: alexco...@gmail.com (Lifetime Email)
> 
> 
>
___
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] How high resolution for -hires in FS6.0

[Alex Cohen]

So what resolution would make sense to use? the release notes say <1.0mm
but would 0.9mm isovol really cut it?

-Alex


Alexander Li Cohen, M.D., Ph.D.
E-mail: alexander.coh...@childrens.harvard.edu (Medical/Science Email)
E-mail: alexco...@gmail.com (Lifetime Email)

___
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] Ynt: Ynt: Ynt: Ynt: Ynt: Neighborhood of a vertex

[Bruce Fischl]

yes, you can use mri_surf2surf to map the thicknesses to fsaverage space 
(this is what recon-all -qcache does)


cheers
Bruce


On Tue, 24 Jan 2017, Onur Uğurlu wrote:



Dear Bruce,

 

Now I can get thickness values, vertex locations and the faces. But it seems
every subject has a different number of vertices. In my case Subject1 has
107107 vertices, whereas Subject2 has 133093. Is it possible to normalized
the subjects into same space?

 

Thanks for the all help.

sincerely yours,


Onur



Gönderen: Onur Uğurlu  adına
freesurfer-boun...@nmr.mgh.harvard.edu

Gönderildi: 25 Aralık 2016 Pazar 23:56
Kime: Freesurfer support list
Konu: [Freesurfer] Ynt: Ynt: Ynt: Ynt: Neighborhood of a vertex  

Hi Bruce;


It works! I didn't know that it's a scalar.


Thanks for the help.


sincerely yours,

Onur




Gönderen: Bruce Fischl  adına
freesurfer-boun...@nmr.mgh.harvard.edu

Gönderildi: 23 Aralık 2016 Cuma 22:48
Kime: Freesurfer support list
Konu: Re: [Freesurfer] Ynt: Ynt: Ynt: Neighborhood of a vertex  
Thickness isn't a surface, it's a scalar field. Use read_curv for it

On Dec 23, 2016, at 11:09 AM, Onur Uğurlu  wrote:

  Hi Bruce;


Unfortunately still we have the same problem.

I've executed "recon-all -all -s SubjID" script, and here are the time
stamps for these 2 files
lh.orig => 01:56:56
lh.thickness => 04:07:52

I also executed "recon-all -make all" script as you suggested but
nothing changed.

When i use "read_surf" function in Matlab on "lh.thickness" and the
answer is 489x3 double
When i use "[coords, faces]=read_surf" function on "lh.orig" ,
"corrds" is 125312x3 double and the "faces" is 250620x3 double

Any ideas?



Gönderen: Bruce Fischl  adına
freesurfer-boun...@nmr.mgh.harvard.edu

Gönderildi: 21 Aralık 2016 Çarşamba 00:05
Kime: Freesurfer support list
Konu: Re: [Freesurfer] Ynt: Ynt: Neighborhood of a vertex  
nope, that should be fine, but the lh.thickness should have exactly as
many entries as the lh.orig. If not, it means one was regenerated and
the
other wasn't. What are the dates on the two files? The lh.thickness
should
be newer than the lh.orig. If it isn't, you probably edited and reran
part
of recon-all but not all the way through. You could also try recon-all
-make all and it will rerun things if it thinks they are needed


On Tue, 20 Dec 2016, Onur Uğurlu
wrote:

>
> Hi Bruce,
>
>
> I am using lh.orig file located in "surf" directory after running
recon-all
> script with -qcache option, and trying to match this data with
lh.thickness
> file again in the same directory. Am I using a wrong combination ?
>
>
> sincerely yours,
>
> Onur
>
>
>___
_
> Gönderen: Bruce Fischl  adına
> freesurfer-boun...@nmr.mgh.harvard.edu
> 
> Gönderildi: 19 Aralık 2016 Pazartesi 19:48
> Kime: Freesurfer support list
> Konu: Re: [Freesurfer] Ynt: Neighborhood of a vertex  
> that shouldn't be the case. Run mris_info or mris_euler_number on
your
> input surface. Can you load the thickness as a surface overlay? It
may be
> that you regenerated surface  and not the htickness, or visa-versa.
Which
> surface are you using?
>
> On Mon, 19 Dec 2016, Onur Uğurlu wrote:
>
> >
> > Hi Bruce,
> >
> >
> > Thank you so much for the answer.
> >
> >
> > I have used "read_surf.m" function and got the list of vertex
locations
> and
> > a list of faces. However, the list contains 107106 vertices
whereas the
> > lh.thickness.asc file contains 118603 vertices. How can I match
the
> > thickness values which are inlh.thickness.asc file with the
vertices which
> > were obtained from "read_surf.m" function?
> >
> >
> > Sincerely yours,
> >
> > Onur
> >
> >
>>__
_
> _
> > Gönderen: Bruce Fischl  adına
> > freesurfer-boun...@nmr.mgh.harvard.edu
> > 
> > Gönderildi: 18 Aralık 2016 Pazar 17:54
> > Kime: Freesurfer support list
> > Konu: Re: [Freesurfer] Neighborhood of a vertex  
> > Hi Onur
> >
> > for that you need a surface file. If you are using matlab you can
load a
> > surface file in with read_surf.m. The  will then be
an index
> > into the surface (although note that you will need to add 1 to it
since
> > matlab is 1-based when you index into the vertex list). It will
return a
> > list of vertex locations and also a list of faces. The faces
contain the
> > (0-based) indices of the vertices in each triangle, which can be
used to
> > compile a list of neighbors.
> >
> > cheers
> > Bruce
> >
> >
> >
> > On Sun, 18 Dec 2016, Onur Uğurlu wrote:
> >
> > >
> > > Hi all,
> > >
> > >
> > > I have a 'lh.thickness.asc' file which contains thickness values
of each
> > > vertex.
> > >
> > > The format of the file is following;
> > >
> > > 
> > >
> > > However, x,

[Freesurfer] Ynt: Ynt: Ynt: Ynt: Ynt: Neighborhood of a vertex

[Onur Uğurlu]

Dear Bruce,

Now I can get thickness values, vertex locations and the faces. But it seems 
every subject has a different number of vertices. In my case Subject1 has 
107107 vertices, whereas Subject2 has 133093. Is it possible to normalized the 
subjects into same space?

Thanks for the all help.
sincerely yours,


Onur



Gönderen: Onur Uğurlu  adına 
freesurfer-boun...@nmr.mgh.harvard.edu 
Gönderildi: 25 Aralık 2016 Pazar 23:56
Kime: Freesurfer support list
Konu: [Freesurfer] Ynt: Ynt: Ynt: Ynt: Neighborhood of a vertex


Hi Bruce;


It works! I didn't know that it's a scalar.


Thanks for the help.


sincerely yours,

Onur



Gönderen: Bruce Fischl  adına 
freesurfer-boun...@nmr.mgh.harvard.edu 
Gönderildi: 23 Aralık 2016 Cuma 22:48
Kime: Freesurfer support list
Konu: Re: [Freesurfer] Ynt: Ynt: Ynt: Neighborhood of a vertex

Thickness isn't a surface, it's a scalar field. Use read_curv for it

On Dec 23, 2016, at 11:09 AM, Onur Uğurlu 
mailto:t_mac_o...@hotmail.com>> wrote:


Hi Bruce;

Unfortunately still we have the same problem.

I've executed "recon-all -all -s SubjID" script, and here are the time stamps 
for these 2 files
lh.orig => 01:56:56
lh.thickness => 04:07:52

I also executed "recon-all -make all" script as you suggested but nothing 
changed.

When i use "read_surf" function in Matlab on "lh.thickness" and the answer is 
489x3 double
When i use "[coords, faces]=read_surf" function on "lh.orig" , "corrds" is 
125312x3 double and the "faces" is 250620x3 double

Any ideas?



Gönderen: Bruce Fischl 
mailto:fis...@nmr.mgh.harvard.edu>> adına 
freesurfer-boun...@nmr.mgh.harvard.edu
 
mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
Gönderildi: 21 Aralık 2016 Çarşamba 00:05
Kime: Freesurfer support list
Konu: Re: [Freesurfer] Ynt: Ynt: Neighborhood of a vertex

nope, that should be fine, but the lh.thickness should have exactly as
many entries as the lh.orig. If not, it means one was regenerated and the
other wasn't. What are the dates on the two files? The lh.thickness should
be newer than the lh.orig. If it isn't, you probably edited and reran part
of recon-all but not all the way through. You could also try recon-all
-make all and it will rerun things if it thinks they are needed


On Tue, 20 Dec 2016, Onur Uğurlu
wrote:

>
> Hi Bruce,
>
>
> I am using lh.orig file located in "surf" directory after running recon-all
> script with -qcache option, and trying to match this data with lh.thickness
> file again in the same directory. Am I using a wrong combination ?
>
>
> sincerely yours,
>
> Onur
>
>
> 
> Gönderen: Bruce Fischl 
> mailto:fis...@nmr.mgh.harvard.edu>> adına
> freesurfer-boun...@nmr.mgh.harvard.edu
> mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
> Gönderildi: 19 Aralık 2016 Pazartesi 19:48
> Kime: Freesurfer support list
> Konu: Re: [Freesurfer] Ynt: Neighborhood of a vertex
> that shouldn't be the case. Run mris_info or mris_euler_number on your
> input surface. Can you load the thickness as a surface overlay? It may be
> that you regenerated surface  and not the htickness, or visa-versa. Which
> surface are you using?
>
> On Mon, 19 Dec 2016, Onur Uğurlu wrote:
>
> >
> > Hi Bruce,
> >
> >
> > Thank you so much for the answer.
> >
> >
> > I have used "read_surf.m" function and got the list of vertex locations
> and
> > a list of faces. However, the list contains 107106 vertices whereas the
> > lh.thickness.asc file contains 118603 vertices. How can I match the
> > thickness values which are inlh.thickness.asc file with the vertices which
> > were obtained from "read_surf.m" function?
> >
> >
> > Sincerely yours,
> >
> > Onur
> >
> >
> >___
> _
> > Gönderen: Bruce Fischl 
> > mailto:fis...@nmr.mgh.harvard.edu>> adına
> > freesurfer-boun...@nmr.mgh.harvard.edu
> > mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
> > Gönderildi: 18 Aralık 2016 Pazar 17:54
> > Kime: Freesurfer support list
> > Konu: Re: [Freesurfer] Neighborhood of a vertex
> > Hi Onur
> >
> > for that you need a surface file. If you are using matlab you can load a
> > surface file in with read_surf.m. The  will then be an index
> > into the surface (although note that you will need to add 1 to it since
> > matlab is 1-based when you index into the vertex list). It will return a
> > list of vertex locations and also a list of faces. The faces contain the
> > (0-based) indices of the vertices in each triangle, which can be used to
> > compile a list of neighbors.
> >
> > cheers
> > Bruce
> >
> >
> >
> > On Sun, 18 Dec 2016, Onur Uğurlu wrote:
> >
> > >
> > > Hi all,
> > >
> > >
> > > I have a 'lh.thickness.asc' file which contains thickness val

Re: [Freesurfer] How high resolution for -hires in FS6.0

[Bruce Fischl]

sorry, I still don't understand. Are you really trying to generate a 
subcortical atlas? Or do you mean a subcortical segmentation? If the
latter, then 1mm is fine.  The resolution you want really depends on what 
you are trying to do

On Tue, 24 Jan 2017, Alex Cohen wrote:

> generating the subcortical atlas:
> recon-all now produces aseg.mgz (subcortical atlas) with Hi-Res data (<1mm).
> The -hires flag is still necessary to include with recon-all when hi-res
> data is input. Changes to mri_normalize, mri_em_register and mri_watershed
> were made to support this feature.
> 
> 
> 
> Alexander Li Cohen, M.D., Ph.D.
> E-mail: alexander.coh...@childrens.harvard.edu (Medical/Science Email)
> E-mail: alexco...@gmail.com (Lifetime Email)
> 
> 
> On Tue, Jan 24, 2017 at 12:21 PM, Bruce Fischl 
> wrote:
>   Hi Alex
>
>   cut it for what?
>
>   Bruce
>
>   On Tue, 24 Jan 2017, Alex Cohen wrote:
>
> So what resolution would make sense to use? the
> release notes say <1.0mm but
> would 0.9mm isovol really cut it?
> -Alex
>
> 
> Alexander Li Cohen, M.D., Ph.D.
> E-mail: alexander.coh...@childrens.harvard.edu
> (Medical/Science Email)
> E-mail: alexco...@gmail.com (Lifetime Email)
> 
> 
> 
> 
> 
> 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] How high resolution for -hires in FS6.0

[Alex Cohen]

generating the subcortical atlas:

recon-all now produces aseg.mgz (subcortical atlas) with Hi-Res data
(<1mm). The -hires flag is still necessary to include with recon-all when
hi-res data is input. Changes to mri_normalize, mri_em_register and
mri_watershed were made to support this feature.



Alexander Li Cohen, M.D., Ph.D.
E-mail: alexander.coh...@childrens.harvard.edu (Medical/Science Email)
E-mail: alexco...@gmail.com (Lifetime Email)


On Tue, Jan 24, 2017 at 12:21 PM, Bruce Fischl 
wrote:

> Hi Alex
>
> cut it for what?
>
> Bruce
>
>
> On Tue, 24 Jan 2017, Alex Cohen wrote:
>
> So what resolution would make sense to use? the release notes say <1.0mm
>> but
>> would 0.9mm isovol really cut it?
>> -Alex
>>
>> 
>> Alexander Li Cohen, M.D., Ph.D.
>> E-mail: alexander.coh...@childrens.harvard.edu (Medical/Science Email)
>> E-mail: alexco...@gmail.com (Lifetime Email)
>> 
>>
>>
>>
>
> 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] How high resolution for -hires in FS6.0

[Alex Cohen]

It was more a question of:
Should the -hires switch be used if you're just interested in subcortical
parcellation, and your data happens to be 0.9mm, etc... or is this feature
aimed at ex-vivo data or similar data.

-Alex



Alexander Li Cohen, M.D., Ph.D.
E-mail: alexander.coh...@childrens.harvard.edu (Medical/Science Email)
E-mail: alexco...@gmail.com (Lifetime Email)


On Tue, Jan 24, 2017 at 12:32 PM, Bruce Fischl 
wrote:

> sorry, I still don't understand. Are you really trying to generate a
> subcortical atlas? Or do you mean a subcortical segmentation? If the
> latter, then 1mm is fine.  The resolution you want really depends on what
> you are trying to do
>
>
> On Tue, 24 Jan 2017, Alex Cohen wrote:
>
> generating the subcortical atlas:
>> recon-all now produces aseg.mgz (subcortical atlas) with Hi-Res data
>> (<1mm).
>> The -hires flag is still necessary to include with recon-all when hi-res
>> data is input. Changes to mri_normalize, mri_em_register and mri_watershed
>> were made to support this feature.
>>
>>
>> 
>> Alexander Li Cohen, M.D., Ph.D.
>> E-mail: alexander.coh...@childrens.harvard.edu (Medical/Science Email)
>> E-mail: alexco...@gmail.com (Lifetime Email)
>> 
>>
>> On Tue, Jan 24, 2017 at 12:21 PM, Bruce Fischl <
>> fis...@nmr.mgh.harvard.edu>
>> wrote:
>>   Hi Alex
>>
>>   cut it for what?
>>
>>   Bruce
>>
>>   On Tue, 24 Jan 2017, Alex Cohen wrote:
>>
>> So what resolution would make sense to use? the
>> release notes say <1.0mm but
>> would 0.9mm isovol really cut it?
>> -Alex
>>
>> 
>> 
>> Alexander Li Cohen, M.D., Ph.D.
>> E-mail: alexander.coh...@childrens.harvard.edu
>> (Medical/Science Email)
>> E-mail: alexco...@gmail.com (Lifetime Email)
>> 
>> 
>>
>>
>>
>>
>> The information in this e-mail is intended only for the person to whom
>> it is
>> addressed. If you believe this e-mail was sent to you in error and the
>> e-mail
>> contains patient information, please contact the Partners Compliance
>> HelpLine at
>> http://www.partners.org/complianceline . If the e-mail was sent to you
>> in error
>> but does not contain patient information, please contact the sender
>> and properly
>> dispose of the e-mail.
>>
>>
>>
>>
>>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

[Freesurfer] Freesurfer 6 - Segfault - mri_ca_register

[Florian Krismer]

Dear FreeSurfer Developers,

I'm attempting to run recon-all on a test subject (through recon-all –all 
–subjid test001 in Freesurfer 6). Recon-all hangs at the mri_ca_register 
command throwing a Segfault error. 

This is the corresponding part of the recon-all.log:
---
mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z 

not handling expanded ventricles...
using previously computed transform transforms/talairach.lta
renormalizing sequences with structure alignment, equivalent to:
-renormalize
-regularize_mean 0.500
-regularize 0.500
using MR volume brainmask.mgz to mask input volume...

== Number of threads available to mri_ca_register for OpenMP = 1 == 
reading 1 input volumes...
logging results to talairach.log
reading input volume 'norm.mgz'...
reading GCA '/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'...
label assignment complete, 0 changed (0.00%)
det(m_affine) = 1.26 (predicted orig area = 6.3)
Segmentation fault
---


When debugging the error through gdb I get the following, additional 
information:

---

[florian@freesurfer]$ gdb --args mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/local/freesurfer/bin/mri_ca_register...(no debugging 
symbols found)...done.
(gdb) run
Starting program: /usr/local/freesurfer/bin/mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x77ffa000
[Thread debugging using libthread_db enabled]
not handling expanded ventricles...
using previously computed transform transforms/talairach.lta
renormalizing sequences with structure alignment, equivalent to:
-renormalize
-regularize_mean 0.500
-regularize 0.500
using MR volume brainmask.mgz to mask input volume...

== Number of threads available to /usr/local/freesurfer/bin/mri_ca_register for 
OpenMP = 1 == 
reading 1 input volumes...
logging results to talairach.log
reading input volume 'norm.mgz'...
reading GCA '/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'...
freeing gibbs priors...done.
average std[0] = 5.0
label assignment complete, 0 changed (0.00%)
det(m_affine) = 1.26 (predicted orig area = 6.3)

Program received signal SIGSEGV, Segmentation fault.
_int_free (av=0x76bb4120, p=0x619a5f30, have_lock=0) at malloc.c:5000
5000    if (__builtin_expect (!prev_inuse(nextchunk), 0))
(gdb) 
---


I run the command on a virtual machine (using XEN as hypervisor software) with 
2 cores and 8gb RAM assigned to the virtual machine.
Some basic information about the platform:
1) FreeSurfer version: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0 
(download date 24-Jan-17)
2) Platform: CentOS release 6.8 (Final)
3) uname –a: Linux  4.4.27-x86_64-jb1 #1 SMP Thu Oct 27 13:51:17 CEST 2016 
x86_64 x86_64 x86_64 GNU/Linux
4) mri_ca_register –all-info: ProgramName: mri_ca_register  ProgramArguments: 
-all-info  ProgramVersion: $Name:  $  TimeStamp: 2017/01/24-17:30:37-GMT  
BuildTimeStamp: Dec 29 2016 17:01:05  CVS: $Id: mri_ca_register.c,v 1.96.2.3 
2016/10/27 22:25:10 zkaufman
5) libgcc.i686 4.4.7-17.el6 

Does anyone have any thoughts on how to trouble-shoot this one?
The funny thing is that if I remove the –align-after flag, the command works 
like a charm (I couldn’t find any documentation describing the purpose of 
–align-after?).

Many thanks for your support & best wishes,
Florian








___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.m

Re: [Freesurfer] mris_make_surfaces error with bbr-init-header

[Sneha Pandya]

Thank you so much Andrew, I indeed looked into that. FLAIR volume used were 
acquired in the same session, however not sure of different geometry. I had to 
also fix the origins for FLAIRraw.mgz as their origins were outside the brain 
(not sure if that would be contributing to different geometry, I guess not so 
much).


In addition to bbr-init-header I independently tried bbregister with 
bbr-init-fsl and bbr-init-spm. bbregister only worked with bbr-init-spm 
resulting in non-empty and properly registered FLAIR.prenorm.mgz and non-empty 
FLAIR.mgz volume in the mri_normalize step. I tried this with only one case, so 
not sure if it will be successful for others as well.


Do you suggest I run them with bbr-init-spm or registering with FLAIRraw to the 
orig as you suggested. If bbr-init-spm is fine then with which step of recon 
should I run? I tried running it with autorecon3 step with bbr-init-spm and 
FLAIRpial flags, but it did not overwrite FLAIR.prenorm.mgz and FLAIR.mgz 
volumes.

Thanks,
Sneha

From: Hoopes, Andrew 
Sent: Tuesday, January 24, 2017 12:20:03 PM
To: Freesurfer support list; Sneha Pandya
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header


Hi Sneha,

I took a look at your issue. Was the FLAIR volume acquired in a different scan 
session than the other volumes? FLAIRraw.mgz has a much different geometry than 
001.mgz and 002.mgz, and so bbregister (the first step of -FLAIRpial) could not 
register the FLAIRraw to the orig volume, resulting in empty FLAIR.prenorm.mgz 
and FLAIR.mgz files. Before rerunning autorecon3, I suggest registering the 
FLAIRraw to the orig, and then applying the resulting transform so that the 
FLAIRraw geometry is initially in alignment with the other volumes:

cd 1_S_5002_snp_bbr-init-header/mri/orig
mri_robust_register --mov FLAIRraw.mgz --dst ../orig.mgz --lta FLAIRorig.lta 
--satit
cp FLAIRraw.mgz FLAIRcopy.mgz
mri_vol2vol --mov FLAIRraw.mgz --lta FLAIRorig.lta --targ ../orig.mgz --o 
FLAIRraw.mgz --no-resample

This should do the trick.

best,
Andrew



From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Sneha Pandya 

Sent: Thursday, January 19, 2017 1:42:06 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header


Hi Bruce,


Any luck with what went wrong?


Thanks,

Sneha


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Sneha Pandya 

Sent: Wednesday, January 18, 2017 2:43:01 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header


I transferred file using ftp transfer.

Thanks,
Sneha

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Bruce Fischl 

Sent: Wednesday, January 18, 2017 1:58:11 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header

oh, something else went wrong, it's not a memory issue.If you upload the
subject we will take a look
Bruce

On Wed, 18 Jan 2017, Sneha Pandya wrote:

>
> Sure, please find it attached.
>
>
> Thanks,
>
> Sneha
>
>
> 
> From: freesurfer-boun...@nmr.mgh.harvard.edu
>  on behalf of Bruce Fischl
> 
> Sent: Wednesday, January 18, 2017 12:20 PM
> To: Freesurfer support list
> Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
> hmmm, can you send us the recon-all.log file?
>
> On Wed, 18 Jan 2017, Sneha Pandya wrote:
>
> >
> > Hi Bruce,
> >
> >
> > Total is 23108 kB from /proc/meminfo and flair vozel size is 1.,
> > 0.9766, 0.9766.
> >
> >
> > I ran quite a few recon-all after this one failed and it did not complain.
> > It just fails when I run recon-all -autorecon3 with -bbr-init-header flag.
> >
> >
> > Thanks,
> > Sneha
> >
> >___
> _
> > From: freesurfer-boun...@nmr.mgh.harvard.edu
> >  on behalf of Bruce Fischl
> > 
> > Sent: Wednesday, January 18, 2017 11:09:36 AM
> > To: Freesurfer support list
> > Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
> > Hi Sneha
> >
> > how much RAM do you have in your machine? And what is the resolution of
> > your data?
> >
> > cheers
> > Bruce
> > On Wed, 18 Jan 2017, Sneha Pandya wrote:
> >
> > >
> > > Hi all,
> > >
> > >
> > > I have successfully ran recon-all on my subjects with multiple T1s. We
> > want
> > > to use flair to refine pial surfaces as for all the subjects pial
> surfaces
> > > are messy and will demand lots of control point edits.
> > >
> > >
> > >
> > > After successfully running entire recon-all stream I am running
> following
> > > command to incorporate flair:
> > >
> > >
> > > recon-all -autorecon3 \
> > > -s SUBJ \
> > > -bbr-init-header \
> > > -FLAIRpial \
> > > -bigventricles \
> > > -openmp 12 \
>

Re: [Freesurfer] Freesurfer 6 - Segfault - mri_ca_register

[Bruce Fischl]

Hi Florian

can you tar and gzip that subject dir and we will take a look?

cheers
Bruce
On Tue, 24 
Jan 2017, Florian Krismer wrote:



Dear FreeSurfer Developers,

I'm attempting to run recon-all on a test subject (through recon-all –all 
–subjid test001 in Freesurfer 6). Recon-all hangs at the mri_ca_register 
command throwing a Segfault error.

This is the corresponding part of the recon-all.log:
---
mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z

not handling expanded ventricles...
using previously computed transform transforms/talairach.lta
renormalizing sequences with structure alignment, equivalent to:
-renormalize
-regularize_mean 0.500
-regularize 0.500
using MR volume brainmask.mgz to mask input volume...

== Number of threads available to mri_ca_register for OpenMP = 1 ==
reading 1 input volumes...
logging results to talairach.log
reading input volume 'norm.mgz'...
reading GCA '/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'...
label assignment complete, 0 changed (0.00%)
det(m_affine) = 1.26 (predicted orig area = 6.3)
Segmentation fault
---


When debugging the error through gdb I get the following, additional 
information:

---

[florian@freesurfer]$ gdb --args mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/local/freesurfer/bin/mri_ca_register...(no debugging 
symbols found)...done.
(gdb) run
Starting program: /usr/local/freesurfer/bin/mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x77ffa000
[Thread debugging using libthread_db enabled]
not handling expanded ventricles...
using previously computed transform transforms/talairach.lta
renormalizing sequences with structure alignment, equivalent to:
-renormalize
-regularize_mean 0.500
-regularize 0.500
using MR volume brainmask.mgz to mask input volume...

== Number of threads available to /usr/local/freesurfer/bin/mri_ca_register for 
OpenMP = 1 == 
reading 1 input volumes...
logging results to talairach.log
reading input volume 'norm.mgz'...
reading GCA '/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'...
freeing gibbs priors...done.
average std[0] = 5.0
label assignment complete, 0 changed (0.00%)
det(m_affine) = 1.26 (predicted orig area = 6.3)

Program received signal SIGSEGV, Segmentation fault.
_int_free (av=0x76bb4120, p=0x619a5f30, have_lock=0) at malloc.c:5000
5000    if (__builtin_expect (!prev_inuse(nextchunk), 0))
(gdb) 
---


I run the command on a virtual machine (using XEN as hypervisor software) with 
2 cores and 8gb RAM assigned to the virtual machine.
Some basic information about the platform:
1) FreeSurfer version: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0 
(download date 24-Jan-17)
2) Platform: CentOS release 6.8 (Final)
3) uname –a: Linux  4.4.27-x86_64-jb1 #1 SMP Thu Oct 27 13:51:17 CEST 2016 
x86_64 x86_64 x86_64 GNU/Linux
4) mri_ca_register –all-info: ProgramName: mri_ca_register  ProgramArguments: 
-all-info  ProgramVersion: $Name:  $  TimeStamp: 2017/01/24-17:30:37-GMT  
BuildTimeStamp: Dec 29 2016 17:01:05  CVS: $Id: mri_ca_register.c,v 1.96.2.3 
2016/10/27 22:25:10 zkaufman
5) libgcc.i686 4.4.7-17.el6

Does anyone have any thoughts on how to trouble-shoot this one?
The funny thing is that if I remove the –align-after flag, the command works 
like a charm (I couldn’t find any documentation describing the purpose of 
–align-after?).

Many thanks for your support & best wishes,
Florian

Re: [Freesurfer] How high resolution for -hires in FS6.0

[Bruce Fischl]

sure, it will preserve the 0.9mm which should help a bit if you have enough 
SNR


On Tue, 24 Jan 
2017, Alex Cohen wrote:



It was more a question of:Should the -hires switch be used if you're just
interested in subcortical parcellation, and your data happens to be 0.9mm,
etc... or is this feature aimed at ex-vivo data or similar data.
-Alex



Alexander Li Cohen, M.D., Ph.D.
E-mail: alexander.coh...@childrens.harvard.edu (Medical/Science Email)
E-mail: alexco...@gmail.com (Lifetime Email)


On Tue, Jan 24, 2017 at 12:32 PM, Bruce Fischl 
wrote:
  sorry, I still don't understand. Are you really trying to
  generate a subcortical atlas? Or do you mean a subcortical
  segmentation? If the
  latter, then 1mm is fine.  The resolution you want really
  depends on what you are trying to do

  On Tue, 24 Jan 2017, Alex Cohen wrote:

generating the subcortical atlas:
recon-all now produces aseg.mgz (subcortical atlas)
with Hi-Res data (<1mm).
The -hires flag is still necessary to include with
recon-all when hi-res
data is input. Changes to mri_normalize,
mri_em_register and mri_watershed
were made to support this feature.



Alexander Li Cohen, M.D., Ph.D.
E-mail: alexander.coh...@childrens.harvard.edu
(Medical/Science Email)
E-mail: alexco...@gmail.com (Lifetime Email)


On Tue, Jan 24, 2017 at 12:21 PM, Bruce Fischl

wrote:
      Hi Alex

      cut it for what?

      Bruce

      On Tue, 24 Jan 2017, Alex Cohen wrote:

            So what resolution would make sense to
use? the
            release notes say <1.0mm but
            would 0.9mm isovol really cut it?
            -Alex

           

            Alexander Li Cohen, M.D., Ph.D.
            E-mail:
alexander.coh...@childrens.harvard.edu
            (Medical/Science Email)
            E-mail: alexco...@gmail.com (Lifetime
Email)
           





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






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


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

[Freesurfer] Freesurfer 6.0 and ex-vivo T1

[Trisanna Sprung-Much]

Hi there

I am wondering if the Freesurfer 6.0 version is more flexible with the
parameters used for ex-vivo scans other than what 5.3 required, as listed
here
 https://surfer.nmr.mgh.harvard.edu/fswiki/ExVivo.

We acquired some ex-vivo scans at 0.4mm iso but not with those above
parameters.

many thanks!

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.

Re: [Freesurfer] Freesurfer 6.0 and ex-vivo T1

[Bruce Fischl]

Hi Trisanna

it is better about handling highres data, but the ex vivo recon stream is 
still a work in progress


cheers
Bruce
On Tue, 24 Jan 2017, Trisanna Sprung-Much wrote:


Hi there
I am wondering if the Freesurfer 6.0 version is more flexible with the
parameters used for ex-vivo scans other than what 5.3 required, as listed
here
 https://surfer.nmr.mgh.harvard.edu/fswiki/ExVivo.

We acquired some ex-vivo scans at 0.4mm iso but not with those above
parameters.

many thanks!

Trisanna

--
Ph.D. CandidateMcGill 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.

Re: [Freesurfer] Freesurfer 6.0 and ex-vivo T1

[Trisanna Sprung-Much]

thanks for the quick response Bruce!

--
Ph.D. Candidate
McGill University
Integrated Program in Neuroscience
Psychology


On Tue, Jan 24, 2017 at 1:18 PM, Bruce Fischl 
wrote:

> Hi Trisanna
>
> it is better about handling highres data, but the ex vivo recon stream is
> still a work in progress
>
> cheers
> Bruce
> On Tue, 24 Jan 2017, Trisanna Sprung-Much wrote:
>
> Hi there
>> I am wondering if the Freesurfer 6.0 version is more flexible with the
>> parameters used for ex-vivo scans other than what 5.3 required, as listed
>> here
>>  https://surfer.nmr.mgh.harvard.edu/fswiki/ExVivo.
>>
>> We acquired some ex-vivo scans at 0.4mm iso but not with those above
>> parameters.
>>
>> many thanks!
>>
>> Trisanna
>>
>> --
>> Ph.D. CandidateMcGill 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 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] mris_make_surfaces error with bbr-init-header

[Hoopes, Andrew]

Ah great! If the registration is accurate with bbr-init-spm, I suggest just 
using that. I would only use the mri_robust_register technique if none of the 
bbr initialization options produce a precise alignment. To overwrite the FLAIR 
volumes, I'm pretty sure including the "-clean-FLAIR" flag in your autorecon3 
command will do the job.


best,

Andrew


From: Sneha Pandya 
Sent: Tuesday, January 24, 2017 12:49:31 PM
To: Hoopes, Andrew; Freesurfer support list
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header


Thank you so much Andrew, I indeed looked into that. FLAIR volume used were 
acquired in the same session, however not sure of different geometry. I had to 
also fix the origins for FLAIRraw.mgz as their origins were outside the brain 
(not sure if that would be contributing to different geometry, I guess not so 
much).


In addition to bbr-init-header I independently tried bbregister with 
bbr-init-fsl and bbr-init-spm. bbregister only worked with bbr-init-spm 
resulting in non-empty and properly registered FLAIR.prenorm.mgz and non-empty 
FLAIR.mgz volume in the mri_normalize step. I tried this with only one case, so 
not sure if it will be successful for others as well.


Do you suggest I run them with bbr-init-spm or registering with FLAIRraw to the 
orig as you suggested. If bbr-init-spm is fine then with which step of recon 
should I run? I tried running it with autorecon3 step with bbr-init-spm and 
FLAIRpial flags, but it did not overwrite FLAIR.prenorm.mgz and FLAIR.mgz 
volumes.

Thanks,
Sneha

From: Hoopes, Andrew 
Sent: Tuesday, January 24, 2017 12:20:03 PM
To: Freesurfer support list; Sneha Pandya
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header


Hi Sneha,

I took a look at your issue. Was the FLAIR volume acquired in a different scan 
session than the other volumes? FLAIRraw.mgz has a much different geometry than 
001.mgz and 002.mgz, and so bbregister (the first step of -FLAIRpial) could not 
register the FLAIRraw to the orig volume, resulting in empty FLAIR.prenorm.mgz 
and FLAIR.mgz files. Before rerunning autorecon3, I suggest registering the 
FLAIRraw to the orig, and then applying the resulting transform so that the 
FLAIRraw geometry is initially in alignment with the other volumes:

cd 1_S_5002_snp_bbr-init-header/mri/orig
mri_robust_register --mov FLAIRraw.mgz --dst ../orig.mgz --lta FLAIRorig.lta 
--satit
cp FLAIRraw.mgz FLAIRcopy.mgz
mri_vol2vol --mov FLAIRraw.mgz --lta FLAIRorig.lta --targ ../orig.mgz --o 
FLAIRraw.mgz --no-resample

This should do the trick.

best,
Andrew



From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Sneha Pandya 

Sent: Thursday, January 19, 2017 1:42:06 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header


Hi Bruce,


Any luck with what went wrong?


Thanks,

Sneha


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Sneha Pandya 

Sent: Wednesday, January 18, 2017 2:43:01 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header


I transferred file using ftp transfer.

Thanks,
Sneha

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Bruce Fischl 

Sent: Wednesday, January 18, 2017 1:58:11 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header

oh, something else went wrong, it's not a memory issue.If you upload the
subject we will take a look
Bruce

On Wed, 18 Jan 2017, Sneha Pandya wrote:

>
> Sure, please find it attached.
>
>
> Thanks,
>
> Sneha
>
>
> 
> From: freesurfer-boun...@nmr.mgh.harvard.edu
>  on behalf of Bruce Fischl
> 
> Sent: Wednesday, January 18, 2017 12:20 PM
> To: Freesurfer support list
> Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
> hmmm, can you send us the recon-all.log file?
>
> On Wed, 18 Jan 2017, Sneha Pandya wrote:
>
> >
> > Hi Bruce,
> >
> >
> > Total is 23108 kB from /proc/meminfo and flair vozel size is 1.,
> > 0.9766, 0.9766.
> >
> >
> > I ran quite a few recon-all after this one failed and it did not complain.
> > It just fails when I run recon-all -autorecon3 with -bbr-init-header flag.
> >
> >
> > Thanks,
> > Sneha
> >
> >___
> _
> > From: freesurfer-boun...@nmr.mgh.harvard.edu
> >  on behalf of Bruce Fischl
> > 
> > Sent: Wednesday, January 18, 2017 11:09:36 AM
> > To: Freesurfer support list
> > Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
> > Hi Sneha
> >
> > how much RAM do you have in your machine? And what is the resolution of
> > your data?
> >
> > cheers
> > Bruce
> > On Wed, 18 Jan 2017, Sneha Pandya wrote:
> >
> > >
> > >

Re: [Freesurfer] Freesurfer 6 - Segfault - mri_ca_register

[Bruce Fischl]

Hi Florian

how much RAM do you have in that machine? I think it is not enough
cheers
Bruce
On 
Tue, 24 Jan 2017, Florian Krismer wrote:



Dear FreeSurfer Developers,

I'm attempting to run recon-all on a test subject (through recon-all –all 
–subjid test001 in Freesurfer 6). Recon-all hangs at the mri_ca_register 
command throwing a Segfault error.

This is the corresponding part of the recon-all.log:
---
mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z

not handling expanded ventricles...
using previously computed transform transforms/talairach.lta
renormalizing sequences with structure alignment, equivalent to:
-renormalize
-regularize_mean 0.500
-regularize 0.500
using MR volume brainmask.mgz to mask input volume...

== Number of threads available to mri_ca_register for OpenMP = 1 ==
reading 1 input volumes...
logging results to talairach.log
reading input volume 'norm.mgz'...
reading GCA '/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'...
label assignment complete, 0 changed (0.00%)
det(m_affine) = 1.26 (predicted orig area = 6.3)
Segmentation fault
---


When debugging the error through gdb I get the following, additional 
information:

---

[florian@freesurfer]$ gdb --args mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/local/freesurfer/bin/mri_ca_register...(no debugging 
symbols found)...done.
(gdb) run
Starting program: /usr/local/freesurfer/bin/mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x77ffa000
[Thread debugging using libthread_db enabled]
not handling expanded ventricles...
using previously computed transform transforms/talairach.lta
renormalizing sequences with structure alignment, equivalent to:
-renormalize
-regularize_mean 0.500
-regularize 0.500
using MR volume brainmask.mgz to mask input volume...

== Number of threads available to /usr/local/freesurfer/bin/mri_ca_register for 
OpenMP = 1 == 
reading 1 input volumes...
logging results to talairach.log
reading input volume 'norm.mgz'...
reading GCA '/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'...
freeing gibbs priors...done.
average std[0] = 5.0
label assignment complete, 0 changed (0.00%)
det(m_affine) = 1.26 (predicted orig area = 6.3)

Program received signal SIGSEGV, Segmentation fault.
_int_free (av=0x76bb4120, p=0x619a5f30, have_lock=0) at malloc.c:5000
5000    if (__builtin_expect (!prev_inuse(nextchunk), 0))
(gdb) 
---


I run the command on a virtual machine (using XEN as hypervisor software) with 
2 cores and 8gb RAM assigned to the virtual machine.
Some basic information about the platform:
1) FreeSurfer version: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0 
(download date 24-Jan-17)
2) Platform: CentOS release 6.8 (Final)
3) uname –a: Linux  4.4.27-x86_64-jb1 #1 SMP Thu Oct 27 13:51:17 CEST 2016 
x86_64 x86_64 x86_64 GNU/Linux
4) mri_ca_register –all-info: ProgramName: mri_ca_register  ProgramArguments: 
-all-info  ProgramVersion: $Name:  $  TimeStamp: 2017/01/24-17:30:37-GMT  
BuildTimeStamp: Dec 29 2016 17:01:05  CVS: $Id: mri_ca_register.c,v 1.96.2.3 
2016/10/27 22:25:10 zkaufman
5) libgcc.i686 4.4.7-17.el6

Does anyone have any thoughts on how to trouble-shoot this one?
The funny thing is that if I remove the –align-after flag, the command works 
like a charm (I couldn’t find any documentation describing the purpose of 
–align-after?).

Many thanks for your support & best wishes,

[Freesurfer] recon-all -all FS6.0

[stdp82]

Hi list,I wonder whether the recon-all -all processing are running 
correctly.I'm noting the follow linesThanks
Stefano
nsamples 3243
Quasinewton: input matrix
 1.05460  -0.04529  -0.00589  -5.39976;
 0.04715   1.21082   0.14343  -52.53261;
 0.00057  -0.10515   0.95251   8.62344;
 0.0   0.0   0.0   1.0;
 IFLAG= -1  LINE SEARCH FAILED. SEE DOCUMENTATION OF ROUTINE MCSRCH ERROR 
RETURN OF LINE SEARCH: INFO= 3 POSSIBLE CAUSES: FUNCTION OR GRADIENT ARE 
INCORRECT OR INCORRECT TOLERANCESoutof QuasiNewtonEMA: 011: -log(p) =   -0.0  
tol 0.10
Resulting transform:
 1.05460  -0.04529  -0.00589  -5.39976;
 0.04715   1.21082   0.14343  -52.53261;
 0.00057  -0.10515   0.95251   8.62344;
 0.0   0.0   0.0   1.0;___
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] mris_make_surfaces error with bbr-init-header

[Sneha Pandya]

Perfect, shall go ahead with bbr-init-spm and will try running it with 
"-clean-FLAIR" flag.


Thanks again!

Sneha


From: Hoopes, Andrew 
Sent: Tuesday, January 24, 2017 2:15:31 PM
To: Sneha Pandya; Freesurfer support list
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header


Ah great! If the registration is accurate with bbr-init-spm, I suggest just 
using that. I would only use the mri_robust_register technique if none of the 
bbr initialization options produce a precise alignment. To overwrite the FLAIR 
volumes, I'm pretty sure including the "-clean-FLAIR" flag in your autorecon3 
command will do the job.


best,

Andrew


From: Sneha Pandya 
Sent: Tuesday, January 24, 2017 12:49:31 PM
To: Hoopes, Andrew; Freesurfer support list
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header


Thank you so much Andrew, I indeed looked into that. FLAIR volume used were 
acquired in the same session, however not sure of different geometry. I had to 
also fix the origins for FLAIRraw.mgz as their origins were outside the brain 
(not sure if that would be contributing to different geometry, I guess not so 
much).


In addition to bbr-init-header I independently tried bbregister with 
bbr-init-fsl and bbr-init-spm. bbregister only worked with bbr-init-spm 
resulting in non-empty and properly registered FLAIR.prenorm.mgz and non-empty 
FLAIR.mgz volume in the mri_normalize step. I tried this with only one case, so 
not sure if it will be successful for others as well.


Do you suggest I run them with bbr-init-spm or registering with FLAIRraw to the 
orig as you suggested. If bbr-init-spm is fine then with which step of recon 
should I run? I tried running it with autorecon3 step with bbr-init-spm and 
FLAIRpial flags, but it did not overwrite FLAIR.prenorm.mgz and FLAIR.mgz 
volumes.

Thanks,
Sneha

From: Hoopes, Andrew 
Sent: Tuesday, January 24, 2017 12:20:03 PM
To: Freesurfer support list; Sneha Pandya
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header


Hi Sneha,

I took a look at your issue. Was the FLAIR volume acquired in a different scan 
session than the other volumes? FLAIRraw.mgz has a much different geometry than 
001.mgz and 002.mgz, and so bbregister (the first step of -FLAIRpial) could not 
register the FLAIRraw to the orig volume, resulting in empty FLAIR.prenorm.mgz 
and FLAIR.mgz files. Before rerunning autorecon3, I suggest registering the 
FLAIRraw to the orig, and then applying the resulting transform so that the 
FLAIRraw geometry is initially in alignment with the other volumes:

cd 1_S_5002_snp_bbr-init-header/mri/orig
mri_robust_register --mov FLAIRraw.mgz --dst ../orig.mgz --lta FLAIRorig.lta 
--satit
cp FLAIRraw.mgz FLAIRcopy.mgz
mri_vol2vol --mov FLAIRraw.mgz --lta FLAIRorig.lta --targ ../orig.mgz --o 
FLAIRraw.mgz --no-resample

This should do the trick.

best,
Andrew



From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Sneha Pandya 

Sent: Thursday, January 19, 2017 1:42:06 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header


Hi Bruce,


Any luck with what went wrong?


Thanks,

Sneha


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Sneha Pandya 

Sent: Wednesday, January 18, 2017 2:43:01 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header


I transferred file using ftp transfer.

Thanks,
Sneha

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Bruce Fischl 

Sent: Wednesday, January 18, 2017 1:58:11 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header

oh, something else went wrong, it's not a memory issue.If you upload the
subject we will take a look
Bruce

On Wed, 18 Jan 2017, Sneha Pandya wrote:

>
> Sure, please find it attached.
>
>
> Thanks,
>
> Sneha
>
>
> 
> From: freesurfer-boun...@nmr.mgh.harvard.edu
>  on behalf of Bruce Fischl
> 
> Sent: Wednesday, January 18, 2017 12:20 PM
> To: Freesurfer support list
> Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
> hmmm, can you send us the recon-all.log file?
>
> On Wed, 18 Jan 2017, Sneha Pandya wrote:
>
> >
> > Hi Bruce,
> >
> >
> > Total is 23108 kB from /proc/meminfo and flair vozel size is 1.,
> > 0.9766, 0.9766.
> >
> >
> > I ran quite a few recon-all after this one failed and it did not complain.
> > It just fails when I run recon-all -autorecon3 with -bbr-init-header flag.
> >
> >
> > Thanks,
> > Sneha
> >
> >___
> _
> > From: freesurfer-boun...@nmr.mgh.harvard.edu
> >  on behalf of Bruce Fischl
> > 
> > Sent: Wednesday,

Re: [Freesurfer] Freesurfer 6 - Segfault - mri_ca_register

[Florian Krismer]

Hi Bruce,

it is a virtual machine with 8GB RAM dedicated to it. Any idea how much RAM 
would be enough?

Thanks,
Florian



Am 24.01.17, 21:39 schrieb "Bruce Fischl" 
:

Hi Florian

how much RAM do you have in that machine? I think it is not enough
cheers
Bruce
On 
Tue, 24 Jan 2017, Florian Krismer wrote:

> Dear FreeSurfer Developers,
>
> I'm attempting to run recon-all on a test subject (through recon-all –all 
–subjid test001 in Freesurfer 6). Recon-all hangs at the mri_ca_register 
command throwing a Segfault error.
>
> This is the corresponding part of the recon-all.log:
> 
---
> mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
>
> not handling expanded ventricles...
> using previously computed transform transforms/talairach.lta
> renormalizing sequences with structure alignment, equivalent to:
>   -renormalize
>   -regularize_mean 0.500
>   -regularize 0.500
> using MR volume brainmask.mgz to mask input volume...
>
> == Number of threads available to mri_ca_register for OpenMP = 1 ==
> reading 1 input volumes...
> logging results to talairach.log
> reading input volume 'norm.mgz'...
> reading GCA '/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'...
> label assignment complete, 0 changed (0.00%)
> det(m_affine) = 1.26 (predicted orig area = 6.3)
> Segmentation fault
> 
---
>
>
> When debugging the error through gdb I get the following, additional 
information:
>
> 
---
>
> [florian@freesurfer]$ gdb --args mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6)
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 

> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/local/freesurfer/bin/mri_ca_register...(no 
debugging symbols found)...done.
> (gdb) run
> Starting program: /usr/local/freesurfer/bin/mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
> warning: no loadable sections found in added symbol-file system-supplied 
DSO at 0x77ffa000
> [Thread debugging using libthread_db enabled]
> not handling expanded ventricles...
> using previously computed transform transforms/talairach.lta
> renormalizing sequences with structure alignment, equivalent to:
>   -renormalize
>   -regularize_mean 0.500
>   -regularize 0.500
> using MR volume brainmask.mgz to mask input volume...
>
> == Number of threads available to 
/usr/local/freesurfer/bin/mri_ca_register for OpenMP = 1 == 
> reading 1 input volumes...
> logging results to talairach.log
> reading input volume 'norm.mgz'...
> reading GCA '/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'...
> freeing gibbs priors...done.
> average std[0] = 5.0
> label assignment complete, 0 changed (0.00%)
> det(m_affine) = 1.26 (predicted orig area = 6.3)
>
> Program received signal SIGSEGV, Segmentation fault.
> _int_free (av=0x76bb4120, p=0x619a5f30, have_lock=0) at malloc.c:5000
> 5000  if (__builtin_expect (!prev_inuse(nextchunk), 0))
> (gdb) 
> 
---
>
>
> I run the command on a virtual machine (using XEN as hypervisor software) 
with 2 cores and 8gb RAM assigned to the virtual machine.
> Some basic information about the platform:
> 1) FreeSurfer version: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0 
(download date 24-Jan-17)
> 2) Platform: CentOS release 6.8 (Final)
> 3) uname –a: Linux  4.4.27-x86_64-jb1 #1 SMP Thu Oct 27 13:5

Re: [Freesurfer] recon-all -all FS6.0

[Bruce Fischl]

Hi Stefano

that's a warning burried in the depths of some open source quasi-newton 
optimization code that doesn't seem to matter - it can be safely ignored I 
believe


cheers
Bruce
On Tue, 24 Jan 2017, 
std...@virgilio.it wrote:



Hi list,I wonder whether the recon-all -all processing are running
correctly.
I'm noting the follow lines
Thanks

Stefano

nsamples 3243

Quasinewton: input matrix

 1.05460  -0.04529  -0.00589  -5.39976;

 0.04715   1.21082   0.14343  -52.53261;

 0.00057  -0.10515   0.95251   8.62344;

 0.0   0.0   0.0   1.0;

 IFLAG= -1  LINE SEARCH FAILED. SEE DOCUMENTATION OF ROUTINE MCSRCH ERROR
RETURN OF LINE SEARCH: INFO= 3 POSSIBLE CAUSES: FUNCTION OR GRADIENT ARE
INCORRECT OR INCORRECT TOLERANCESoutof QuasiNewtonEMA: 011: -log(p) =  
-0.0  tol 0.10

Resulting transform:

 1.05460  -0.04529  -0.00589  -5.39976;

 0.04715   1.21082   0.14343  -52.53261;

 0.00057  -0.10515   0.95251   8.62344;

 0.0   0.0   0.0   1.0;


___
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 - Segfault - mri_ca_register

[Bruce Fischl]

I think that should be enough, but your data doesn't segfault for me. I 
also noticed the following in your recon-all.log file:


usr/local/freesurfer/bin/recon-all
-all -gca RB_all_2017-01-23.gca -gca-skull RB_all_withskull_2017-01-23.gca 
-subjid vco1573test_mpr



are you using your own version of our atlases? Or did you rename them? I 
don't think we rebuilt any in 2017.


cheers
Bruce


On 
Tue, 24 Jan 2017, Florian Krismer wrote:



Hi Bruce,

it is a virtual machine with 8GB RAM dedicated to it. Any idea how much RAM 
would be enough?

Thanks,
Florian



Am 24.01.17, 21:39 schrieb "Bruce Fischl" :

   Hi Florian

   how much RAM do you have in that machine? I think it is not enough
   cheers
   Bruce
   On
   Tue, 24 Jan 2017, Florian Krismer wrote:

   > Dear FreeSurfer Developers,
   >
   > I'm attempting to run recon-all on a test subject (through recon-all –all 
–subjid test001 in Freesurfer 6). Recon-all hangs at the mri_ca_register command 
throwing a Segfault error.
   >
   > This is the corresponding part of the recon-all.log:
   > 
---
   > mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
   >
   > not handling expanded ventricles...
   > using previously computed transform transforms/talairach.lta
   > renormalizing sequences with structure alignment, equivalent to:
   > -renormalize
   > -regularize_mean 0.500
   > -regularize 0.500
   > using MR volume brainmask.mgz to mask input volume...
   >
   > == Number of threads available to mri_ca_register for OpenMP = 1 ==
   > reading 1 input volumes...
   > logging results to talairach.log
   > reading input volume 'norm.mgz'...
   > reading GCA '/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'...
   > label assignment complete, 0 changed (0.00%)
   > det(m_affine) = 1.26 (predicted orig area = 6.3)
   > Segmentation fault
   > 
---
   >
   >
   > When debugging the error through gdb I get the following, additional 
information:
   >
   > 
---
   >
   > [florian@freesurfer]$ gdb --args mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
   > GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6)
   > Copyright (C) 2010 Free Software Foundation, Inc.
   > License GPLv3+: GNU GPL version 3 or later 

   > This is free software: you are free to change and redistribute it.
   > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
   > and "show warranty" for details.
   > This GDB was configured as "x86_64-redhat-linux-gnu".
   > For bug reporting instructions, please see:
   > ...
   > Reading symbols from /usr/local/freesurfer/bin/mri_ca_register...(no 
debugging symbols found)...done.
   > (gdb) run
   > Starting program: /usr/local/freesurfer/bin/mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
   > warning: no loadable sections found in added symbol-file system-supplied 
DSO at 0x77ffa000
   > [Thread debugging using libthread_db enabled]
   > not handling expanded ventricles...
   > using previously computed transform transforms/talairach.lta
   > renormalizing sequences with structure alignment, equivalent to:
   > -renormalize
   > -regularize_mean 0.500
   > -regularize 0.500
   > using MR volume brainmask.mgz to mask input volume...
   >
   > == Number of threads available to 
/usr/local/freesurfer/bin/mri_ca_register for OpenMP = 1 ==
   > reading 1 input volumes...
   > logging results to talairach.log
   > reading input volume 'norm.mgz'...
   > reading GCA '/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'...
   > freeing gibbs priors...done.
   > average std[0] = 5.0
   > label assignment complete, 0 changed (0.00%)
   > det(m_affine) = 1.26 (predicted orig area = 6.3)
   >
   > Program received signal SIGSEGV, Segmentation fault.
   > _int_free (av=0x76bb4120, p=0x619a5f30, have_lock=0) at malloc.c:5000
   > 5000if (__builtin_expect (!prev_inuse(nextchunk), 0))
   > (gdb)
   > 
---
   >
   >
   > I run the com

Re: [Freesurfer] Freesurfer 6 - Segfault - mri_ca_register

[Florian Krismer]

Hi Bruce,

It’s a custom atlas with minor changes that was build with the 
rebuild_gca_atlas.csh script. 
What is puzzling to me is the fact that if I omit the align-after flag the 
mri_ca_register command works perfectly fine.

Many thanks & best wishes,
Florian


Am 24.01.17, 21:48 schrieb "Bruce Fischl" 
:

I think that should be enough, but your data doesn't segfault for me. I 
also noticed the following in your recon-all.log file:

usr/local/freesurfer/bin/recon-all
-all -gca RB_all_2017-01-23.gca -gca-skull RB_all_withskull_2017-01-23.gca 
-subjid vco1573test_mpr


are you using your own version of our atlases? Or did you rename them? I 
don't think we rebuilt any in 2017.

cheers
Bruce


On 
Tue, 24 Jan 2017, Florian Krismer wrote:

> Hi Bruce,
>
> it is a virtual machine with 8GB RAM dedicated to it. Any idea how much 
RAM would be enough?
>
> Thanks,
> Florian
>
>
>
> Am 24.01.17, 21:39 schrieb "Bruce Fischl" 
:
>
>Hi Florian
>
>how much RAM do you have in that machine? I think it is not enough
>cheers
>Bruce
>On
>Tue, 24 Jan 2017, Florian Krismer wrote:
>
>> Dear FreeSurfer Developers,
>>
>> I'm attempting to run recon-all on a test subject (through recon-all 
–all –subjid test001 in Freesurfer 6). Recon-all hangs at the mri_ca_register 
command throwing a Segfault error.
>>
>> This is the corresponding part of the recon-all.log:
>> 
---
>> mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
>>
>> not handling expanded ventricles...
>> using previously computed transform transforms/talairach.lta
>> renormalizing sequences with structure alignment, equivalent to:
>>  -renormalize
>>  -regularize_mean 0.500
>>  -regularize 0.500
>> using MR volume brainmask.mgz to mask input volume...
>>
>> == Number of threads available to mri_ca_register for OpenMP = 1 ==
>> reading 1 input volumes...
>> logging results to talairach.log
>> reading input volume 'norm.mgz'...
>> reading GCA 
'/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'...
>> label assignment complete, 0 changed (0.00%)
>> det(m_affine) = 1.26 (predicted orig area = 6.3)
>> Segmentation fault
>> 
---
>>
>>
>> When debugging the error through gdb I get the following, additional 
information:
>>
>> 
---
>>
>> [florian@freesurfer]$ gdb --args mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
>> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6)
>> Copyright (C) 2010 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later 

>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-redhat-linux-gnu".
>> For bug reporting instructions, please see:
>> ...
>> Reading symbols from /usr/local/freesurfer/bin/mri_ca_register...(no 
debugging symbols found)...done.
>> (gdb) run
>> Starting program: /usr/local/freesurfer/bin/mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
>> warning: no loadable sections found in added symbol-file 
system-supplied DSO at 0x77ffa000
>> [Thread debugging using libthread_db enabled]
>> not handling expanded ventricles...
>> using previously computed transform transforms/talairach.lta
>> renormalizing sequences with structure alignment, equivalent to:
>>  -renormalize
>>  -regularize_mean 0.500
>>  -regularize 0.500
>> using MR volume brainmask.mgz to mask input volume...
>

[Freesurfer] R: Re: recon-all -all FS6.0

[stdp82]

Thanks!


>Messaggio originale
>Da: "Bruce Fischl" 
>Data: 24-gen-2017 21.45
>A: , "Freesurfer support list"
>Ogg: Re: [Freesurfer] recon-all -all FS6.0
>
>Hi Stefano
>
>that's a warning burried in the depths of some open source quasi-newton 
>optimization code that doesn't seem to matter - it can be safely ignored I 
>believe
>
>cheers
>Bruce
>On Tue, 24 Jan 2017, 
>std...@virgilio.it wrote:
>
>> Hi list,I wonder whether the recon-all -all processing are running
>> correctly.
>> I'm noting the follow lines
>> Thanks
>> 
>> Stefano
>> 
>> nsamples 3243
>> 
>> Quasinewton: input matrix
>> 
>>  1.05460  -0.04529  -0.00589  -5.39976;
>> 
>>  0.04715   1.21082   0.14343  -52.53261;
>> 
>>  0.00057  -0.10515   0.95251   8.62344;
>> 
>>  0.0   0.0   0.0   1.0;
>> 
>>  IFLAG= -1  LINE SEARCH FAILED. SEE DOCUMENTATION OF ROUTINE MCSRCH ERROR
>> RETURN OF LINE SEARCH: INFO= 3 POSSIBLE CAUSES: FUNCTION OR GRADIENT ARE
>> INCORRECT OR INCORRECT TOLERANCESoutof QuasiNewtonEMA: 011: -log(p) =  
>> -0.0  tol 0.10
>> 
>> Resulting transform:
>> 
>>  1.05460  -0.04529  -0.00589  -5.39976;
>> 
>>  0.04715   1.21082   0.14343  -52.53261;
>> 
>>  0.00057  -0.10515   0.95251   8.62344;
>> 
>>  0.0   0.0   0.0   1.0;
>> 
>> 
>>___
>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] trac-all bug: using #!/bin/sh instead of #!/bin/bash in scripts which use bash-only syntax extensions

[Yendiki, Anastasia]

Thanks for the tip, Peter. Someone has had this issue in past. These were
adapted from old FSL scripts and the goal is to phase them out eventually.
Right now trac-all has a new option to print out the commands to be
submitted to a cluster, so that the user can handle that herself. It would
be impractical to support all possible cluster versions anyway. I hope
this works.

a.y

On 1/24/17, 5:25 AM, "freesurfer-boun...@nmr.mgh.harvard.edu on behalf of
Parzer, Peter"  wrote:

>Hi,
>
>there is a bug in the scripts bedpostx_mgh and fsl_sub_mgh. Both use code
>that do not conform to the standard shell syntax and work only with bash.
>This does not work in system that do not link /bin/sh to /bin/bash (as is
>the case in Ubuntu). Both scripts must use #!/bin/bash as the interpreter
>command in the first line.
>
>Peter
>___
>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] hippo-subfields analysis 6.0v

[stdp82]

Hi list,I'm performing hippo-subfields analysis on T1 having the followed 
parameters:
data_type  INT32dim1   170dim2   256dim3   256dim4  
 1datatype   8pixdim11.25pixdim21.00pixdim3 
   1.00pixdim41.00cal_max0.cal_min
0.file_type  NIFTI-1+
Does my result will be reliable also whether I avoid to add the T2 scan?
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] Freesurfer 6 - Segfault - mri_ca_register

[Bruce Fischl]

Hi FLorian

I think you are not running the release, but a slightly earlier version 
(from the info at the top of your recon-all.log).


Can you try running with the standard atlases and see if that works? And if 
it does, upload your rebuilt atlases so I can try to replicate the crash?


cheers
Bruce


On Tue, 24 Jan 2017, Florian Krismer wrote:


Hi Bruce,

It’s a custom atlas with minor changes that was build with the 
rebuild_gca_atlas.csh script.
What is puzzling to me is the fact that if I omit the align-after flag the 
mri_ca_register command works perfectly fine.

Many thanks & best wishes,
Florian


Am 24.01.17, 21:48 schrieb "Bruce Fischl" :

   I think that should be enough, but your data doesn't segfault for me. I
   also noticed the following in your recon-all.log file:

   usr/local/freesurfer/bin/recon-all
   -all -gca RB_all_2017-01-23.gca -gca-skull RB_all_withskull_2017-01-23.gca
   -subjid vco1573test_mpr


   are you using your own version of our atlases? Or did you rename them? I
   don't think we rebuilt any in 2017.

   cheers
   Bruce


   On
   Tue, 24 Jan 2017, Florian Krismer wrote:

   > Hi Bruce,
   >
   > it is a virtual machine with 8GB RAM dedicated to it. Any idea how much 
RAM would be enough?
   >
   > Thanks,
   > Florian
   >
   >
   >
   > Am 24.01.17, 21:39 schrieb "Bruce Fischl" 
:
   >
   >Hi Florian
   >
   >how much RAM do you have in that machine? I think it is not enough
   >cheers
   >Bruce
   >On
   >Tue, 24 Jan 2017, Florian Krismer wrote:
   >
   >> Dear FreeSurfer Developers,
   >>
   >> I'm attempting to run recon-all on a test subject (through recon-all 
–all –subjid test001 in Freesurfer 6). Recon-all hangs at the mri_ca_register command 
throwing a Segfault error.
   >>
   >> This is the corresponding part of the recon-all.log:
   >> 
---
   >> mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
   >>
   >> not handling expanded ventricles...
   >> using previously computed transform transforms/talairach.lta
   >> renormalizing sequences with structure alignment, equivalent to:
   >> -renormalize
   >> -regularize_mean 0.500
   >> -regularize 0.500
   >> using MR volume brainmask.mgz to mask input volume...
   >>
   >> == Number of threads available to mri_ca_register for OpenMP = 1 ==
   >> reading 1 input volumes...
   >> logging results to talairach.log
   >> reading input volume 'norm.mgz'...
   >> reading GCA 
'/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'...
   >> label assignment complete, 0 changed (0.00%)
   >> det(m_affine) = 1.26 (predicted orig area = 6.3)
   >> Segmentation fault
   >> 
---
   >>
   >>
   >> When debugging the error through gdb I get the following, additional 
information:
   >>
   >> 
---
   >>
   >> [florian@freesurfer]$ gdb --args mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
   >> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6)
   >> Copyright (C) 2010 Free Software Foundation, Inc.
   >> License GPLv3+: GNU GPL version 3 or later 

   >> This is free software: you are free to change and redistribute it.
   >> There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"
   >> and "show warranty" for details.
   >> This GDB was configured as "x86_64-redhat-linux-gnu".
   >> For bug reporting instructions, please see:
   >> ...
   >> Reading symbols from /usr/local/freesurfer/bin/mri_ca_register...(no 
debugging symbols found)...done.
   >> (gdb) run
   >> Starting program: /usr/local/freesurfer/bin/mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
   >> warning: no loadable sections found in added symbol-file 
system-supplied DSO at 0x77ffa000
   >> [Thread debugging using libthread_db enabled]
   >> not handling expanded ventricles...
   >> using previously computed transform transforms/talairach.lta

[Freesurfer] cuda 7.5 and new ver6

[Jeff Stevenson]

hi freesufer folks, has your new version 6 run a successful cuda7.5 gpu on 
ubuntu 16.04? i'm getting a core dump. jeff
here is the cmd:

recon-all -all -use-gpu -s ${filenames_arr[$i]}_freesurf -i 
${sesnum_arr[$i]}/anat/${filenames_arr[$i]}.nii

first output gave:

Testing for CUDA device:
/home/toddr/Software/freesurfer/bin/mri_em_register_cuda: error while loading 
shared libraries: libcudart.so.5.0: cannot open shared object file: No such 
file or directory
Linux redshirt 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux

thinking its a missing link i did:
sudo ln -s /usr/lib/x86_64-linux-gnu/libcudart.so.7.5.18 
/usr/lib/x86_64-linux-gnu/libcudart.so.5.0

and then got:

Testing for CUDA device:
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2012 NVIDIA Corporation
Built on Fri_Sep_21_17:28:58_PDT_2012
Cuda compilation tools, release 5.0, V0.2.1221

Driver : 8.0
Runtime : 7.50

Acquiring CUDA device
Using default device
CUDA device: GeForce GTX TITAN Black
Segmentation fault (core dumped)
Linux redshirt 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux

recon-all -s sub-bbc101_ses-1_mpr_3_freesurf exited with ERRORS at Tue Jan 24 
13:21:33 PST 2017

For more details, see the log file
To report a problem, see http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting


___
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] mris_make_surfaces error with bbr-init-header

[Douglas N Greve]

The -spm will work well, but it does require matlab (and spm). Note that 
in version 6 we use mri_coreg which is our implementation of spmreg.


On 01/24/2017 02:15 PM, Hoopes, Andrew wrote:
>
> Ah great! If the registration is accurate with bbr-init-spm, I suggest 
> just using that. I would only use the mri_robust_register technique if 
> none of the bbr initialization options produce a precise alignment. To 
> overwrite the FLAIR volumes, I'm pretty 
> sure including the "-clean-FLAIR" flag in your autorecon3 command will 
> do the job.
>
>
> best,
>
> Andrew
>
> 
> *From:* Sneha Pandya 
> *Sent:* Tuesday, January 24, 2017 12:49:31 PM
> *To:* Hoopes, Andrew; Freesurfer support list
> *Subject:* Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
>
> Thank you so much Andrew, I indeed looked into that. FLAIR volume used 
> were acquired in the same session, however not sure of different 
> geometry. I had to also fix the origins for FLAIRraw.mgzas their 
> origins were outside the brain (not sure if that would be contributing 
> to different geometry, I guess not so much).
>
>
> In addition to bbr-init-headerI independentlytried bbregister with 
> bbr-init-fsl and bbr-init-spm. bbregister only worked with 
> bbr-init-spmresulting innon-empty and properly registered 
> FLAIR.prenorm.mgzand non-emptyFLAIR.mgz volume in the mri_normalize 
> step. I tried this with only one case, so not sure if it will be 
> successfulfor others as well.
>
>
> Do you suggest I run them with bbr-init-spmor registering with 
> FLAIRraw to the origas you suggested. Ifbbr-init-spmis fine then 
> withwhich step of recon should I run? I tried running it with 
> autorecon3step with bbr-init-spmand FLAIRpialflags, but it did not 
> overwrite FLAIR.prenorm.mgz and FLAIR.mgzvolumes.
>
>
> Thanks,
> Sneha
> 
> *From:* Hoopes, Andrew 
> *Sent:* Tuesday, January 24, 2017 12:20:03 PM
> *To:* Freesurfer support list; Sneha Pandya
> *Subject:* Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
> Hi Sneha,
>
> I took a look at your issue. Was the FLAIR volume acquired in a 
> different scan session than the other volumes? FLAIRraw.mgz has a much 
> different geometry than 001.mgz and 002.mgz, and so bbregister (the 
> first step of -FLAIRpial) could not register the FLAIRraw to the orig 
> volume, resulting in empty FLAIR.prenorm.mgz and FLAIR.mgz files. 
> Before rerunning autorecon3, I suggest registering the FLAIRraw to the 
> orig, and then applying the resulting transform so that the FLAIRraw 
> geometry is initially in alignment with the other volumes:
>
> cd 1_S_5002_snp_bbr-init-header/mri/orig
> mri_robust_register --mov FLAIRraw.mgz --dst ../orig.mgz --lta 
> FLAIRorig.lta --satit
> cp FLAIRraw.mgz FLAIRcopy.mgz
> mri_vol2vol --mov FLAIRraw.mgz --lta FLAIRorig.lta --targ ../orig.mgz 
> --o FLAIRraw.mgz --no-resample
>
> This should do the trick.
>
> best,
> Andrew
>
> 
> *From:* freesurfer-boun...@nmr.mgh.harvard.edu 
>  on behalf of Sneha Pandya 
> 
> *Sent:* Thursday, January 19, 2017 1:42:06 PM
> *To:* Freesurfer support list
> *Subject:* Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
>
> Hi Bruce,
>
>
> Any luck with what went wrong?
>
>
> Thanks,
>
> Sneha
>
>
> 
> *From:* freesurfer-boun...@nmr.mgh.harvard.edu 
>  on behalf of Sneha Pandya 
> 
> *Sent:* Wednesday, January 18, 2017 2:43:01 PM
> *To:* Freesurfer support list
> *Subject:* Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
>
> I transferred file using ftp transfer.
>
>
> Thanks,
> Sneha
> 
> *From:* freesurfer-boun...@nmr.mgh.harvard.edu 
>  on behalf of Bruce Fischl 
> 
> *Sent:* Wednesday, January 18, 2017 1:58:11 PM
> *To:* Freesurfer support list
> *Subject:* Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
> oh, something else went wrong, it's not a memory issue.If you upload the
> subject we will take a look
> Bruce
>
> On Wed, 18 Jan 2017, Sneha Pandya wrote:
>
> >
> > Sure, please find it attached.
> >
> >
> > Thanks,
> >
> > Sneha
> >
> >
> > 
> 
> > From: freesurfer-boun...@nmr.mgh.harvard.edu
> >  on behalf of Bruce Fischl
> > 
> > Sent: Wednesday, January 18, 2017 12:20 PM
> > To: Freesurfer support list
> > Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
> > hmmm, can you send us the recon-all.log file?
> >
> > On Wed, 18 Jan 2017, Sneha Pandya wrote:
> >
> > >
> > > Hi Bruce,
> > >
> > >
> > > Total is 23108 kB from /proc/meminfo and flair vozel size is 
> 1.,
> > > 0.9766, 0.9766.
> > >
> > >
> > > I ran quite a few recon-all

Re: [Freesurfer] mris_make_surfaces error with bbr-init-header

[Sneha Pandya]

Thank you Dough, yes I believe so, we have matlab and spm installed as well.


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Douglas N Greve 

Sent: Tuesday, January 24, 2017 5:00:19 PM
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] mris_make_surfaces error with bbr-init-header

The -spm will work well, but it does require matlab (and spm). Note that
in version 6 we use mri_coreg which is our implementation of spmreg.


On 01/24/2017 02:15 PM, Hoopes, Andrew wrote:
>
> Ah great! If the registration is accurate with bbr-init-spm, I suggest
> just using that. I would only use the mri_robust_register technique if
> none of the bbr initialization options produce a precise alignment. To
> overwrite the FLAIR volumes, I'm pretty
> sure including the "-clean-FLAIR" flag in your autorecon3 command will
> do the job.
>
>
> best,
>
> Andrew
>
> 
> *From:* Sneha Pandya 
> *Sent:* Tuesday, January 24, 2017 12:49:31 PM
> *To:* Hoopes, Andrew; Freesurfer support list
> *Subject:* Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
>
> Thank you so much Andrew, I indeed looked into that. FLAIR volume used
> were acquired in the same session, however not sure of different
> geometry. I had to also fix the origins for FLAIRraw.mgzas their
> origins were outside the brain (not sure if that would be contributing
> to different geometry, I guess not so much).
>
>
> In addition to bbr-init-headerI independentlytried bbregister with
> bbr-init-fsl and bbr-init-spm. bbregister only worked with
> bbr-init-spmresulting innon-empty and properly registered
> FLAIR.prenorm.mgzand non-emptyFLAIR.mgz volume in the mri_normalize
> step. I tried this with only one case, so not sure if it will be
> successfulfor others as well.
>
>
> Do you suggest I run them with bbr-init-spmor registering with
> FLAIRraw to the origas you suggested. Ifbbr-init-spmis fine then
> withwhich step of recon should I run? I tried running it with
> autorecon3step with bbr-init-spmand FLAIRpialflags, but it did not
> overwrite FLAIR.prenorm.mgz and FLAIR.mgzvolumes.
>
>
> Thanks,
> Sneha
> 
> *From:* Hoopes, Andrew 
> *Sent:* Tuesday, January 24, 2017 12:20:03 PM
> *To:* Freesurfer support list; Sneha Pandya
> *Subject:* Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
> Hi Sneha,
>
> I took a look at your issue. Was the FLAIR volume acquired in a
> different scan session than the other volumes? FLAIRraw.mgz has a much
> different geometry than 001.mgz and 002.mgz, and so bbregister (the
> first step of -FLAIRpial) could not register the FLAIRraw to the orig
> volume, resulting in empty FLAIR.prenorm.mgz and FLAIR.mgz files.
> Before rerunning autorecon3, I suggest registering the FLAIRraw to the
> orig, and then applying the resulting transform so that the FLAIRraw
> geometry is initially in alignment with the other volumes:
>
> cd 1_S_5002_snp_bbr-init-header/mri/orig
> mri_robust_register --mov FLAIRraw.mgz --dst ../orig.mgz --lta
> FLAIRorig.lta --satit
> cp FLAIRraw.mgz FLAIRcopy.mgz
> mri_vol2vol --mov FLAIRraw.mgz --lta FLAIRorig.lta --targ ../orig.mgz
> --o FLAIRraw.mgz --no-resample
>
> This should do the trick.
>
> best,
> Andrew
>
> 
> *From:* freesurfer-boun...@nmr.mgh.harvard.edu
>  on behalf of Sneha Pandya
> 
> *Sent:* Thursday, January 19, 2017 1:42:06 PM
> *To:* Freesurfer support list
> *Subject:* Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
>
> Hi Bruce,
>
>
> Any luck with what went wrong?
>
>
> Thanks,
>
> Sneha
>
>
> 
> *From:* freesurfer-boun...@nmr.mgh.harvard.edu
>  on behalf of Sneha Pandya
> 
> *Sent:* Wednesday, January 18, 2017 2:43:01 PM
> *To:* Freesurfer support list
> *Subject:* Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
>
> I transferred file using ftp transfer.
>
>
> Thanks,
> Sneha
> 
> *From:* freesurfer-boun...@nmr.mgh.harvard.edu
>  on behalf of Bruce Fischl
> 
> *Sent:* Wednesday, January 18, 2017 1:58:11 PM
> *To:* Freesurfer support list
> *Subject:* Re: [Freesurfer] mris_make_surfaces error with bbr-init-header
> oh, something else went wrong, it's not a memory issue.If you upload the
> subject we will take a look
> Bruce
>
> On Wed, 18 Jan 2017, Sneha Pandya wrote:
>
> >
> > Sure, please find it attached.
> >
> >
> > Thanks,
> >
> > Sneha
> >
> >
> >
> 
> > From: freesurfer-boun...@nmr.mgh.harvard.edu
> >  on behalf of Bruce Fischl
> > 
> > Sent: Wednesday, January 18, 2017 12:20 PM
> > To: Freesurfer support list
> > Subject: Re: [Freesurfer] mris_make_surfaces error wi

Re: [Freesurfer] longitudinal stream v 5.3 - transfer edits of the wm.mgz from cross to base?

[Antonin Skoch]

Dear Martin,

thanks for the feedback. We had to edit cross due to the fact that

1. our dataset is involved also in cross-sectional studies
2. we are continuously acquiring timepoints but want to do some analyses with 
data we already have

Therefore only editing the base was not an option for us.

I was thinking (to save time spent on edits) of transferring the INTERSECTION 
of wm edits from all cross points to base. 
I think this should work, the only issue I see here is how to handle resampling 
from space of cross to the space of base. What do you think?

And, regarding the v6.0 is currently released, would you recommend to 
re-process our cross-sectional data (originally processed with v5.3) with v6.0?
Would you expect any issues with cross-sectional edits made on v 5.3? Most of 
the edits are on the wm.mgz, some on brainmask.mgz or 
brain.finalsurfs.manedit.mgz.

Regards,

Antonin





Hi Antonin, 

in most cases it should be sufficient to only edit wm.mgz in the base, instead 
of editing all time points. This is a big time saving especially if you have 
many time points.I don’t think merging edits from cross will work well, as 
there could be 
atrophy and lots of non-linear deformations in some of the fast progressing 
brains. 

Best, Martin

> On 23 Jan 2017, at 23:11, Antonin Skoch  wrote:
> 
> Dear experts,
> 
> I am currently starting longitudinal analysis of data I previously corrected 
> in cross-sectional stream (FreeSurfer v5.3).
> The analysis comprises quite large number of subjects - approx 150 subjects, 
> each scanned twice.
> All subjects are already inspected and errors corrected in cross-sectional 
> analysis. Some of them needed quite large edits, mainly to the wm.mgz and the 
> whole process took large time.
> 
> As I read the documentation, the wm.mgz edits in cross are not currently 
> transferred to base. However, wm.mgz has to be correct in base in order to 
> estimate surfaces correctly. From this it implies to me that I would need to 
> edit all wm.mgz errors in base again.
> Do you think that it could be possible/reasonable to transfer some wm.mgz 
> edits from cross to base, for example to make intersection of edits of all 
> cross timepoints and to transfer it to the base? This could significantly 
> reduce time spent on edits. Does it make sense? 
> 
> Regards,
> 
> Antonin Skoch ___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

Re: [Freesurfer] longitudinal stream v 5.3 - transfer edits of the wm.mgz from cross to base?

[Martin Reuter]

Hi Antonin, 

I see. The problem with the intersection would be that it could be zero in 
spite of several edits that move around. Still would be better than nothing. 
Feel free to test that (e.g. you can load that in matlab, intersect and then 
apply to the wm from base to see if it helps). Let me know. 

About 6.0 usually edits should carry through. Test it in one or two cases to 
make sure it works. Also you could keep 5.3 cross and (consistently for all 
individuals) run 6.0 for base and long. Should also work. 

Best, Martin


> On 24 Jan 2017, at 23:40, Antonin Skoch  wrote:
> 
> Dear Martin,
> 
> thanks for the feedback. We had to edit cross due to the fact that
> 
> 1. our dataset is involved also in cross-sectional studies
> 2. we are continuously acquiring timepoints but want to do some analyses with 
> data we already have
> 
> Therefore only editing the base was not an option for us.
> 
> I was thinking (to save time spent on edits) of transferring the INTERSECTION 
> of wm edits from all cross points to base. 
> I think this should work, the only issue I see here is how to handle 
> resampling from space of cross to the space of base. What do you think?
> 
> And, regarding the v6.0 is currently released, would you recommend to 
> re-process our cross-sectional data (originally processed with v5.3) with 
> v6.0?
> Would you expect any issues with cross-sectional edits made on v 5.3? Most of 
> the edits are on the wm.mgz, some on brainmask.mgz or 
> brain.finalsurfs.manedit.mgz.
> 
> Regards,
> 
> Antonin
> 
> 
> 
> 
> 
> Hi Antonin, 
> 
> in most cases it should be sufficient to only edit wm.mgz in the base, 
> instead 
> of editing all time points. This is a big time saving especially if you have 
> many time points.
> I don’t think merging edits from cross will work well, as there could be 
> atrophy and lots of non-linear deformations in some of the fast progressing 
> brains. 
> 
> Best, Martin
> 
> > On 23 Jan 2017, at 23:11, Antonin Skoch  wrote:
> > 
> > Dear experts,
> > 
> > I am currently starting longitudinal analysis of data I previously 
> > corrected 
> > in cross-sectional stream (FreeSurfer v5.3).
> > The analysis comprises quite large number of subjects - approx 150 
> > subjects, 
> > each scanned twice.
> > All subjects are already inspected and errors corrected in cross-sectional 
> > analysis. Some of them needed quite large edits, mainly to the wm.mgz and 
> > the 
> > whole process took large time.
> > 
> > As I read the documentation, the wm.mgz edits in cross are not currently 
> > transferred to base. However, wm.mgz has to be correct in base in order to 
> > estimate surfaces correctly. From this it implies to me that I would need 
> > to 
> > edit all wm.mgz errors in base again.
> > Do you think that it could be possible/reasonable to transfer some wm.mgz 
> > edits from cross to base, for example to make intersection of edits of all 
> > cross timepoints and to transfer it to the base? This could significantly 
> > reduce time spent on edits. Does it make sense? 
> > 
> > Regards,
> > 
> > Antonin Skoch 
> ___
> 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] Freesurfer 6 - Segfault - mri_ca_register

[Bruce Fischl]

Hi FLorian

the problem is that you have cortical labels from the aparc+aseg in your 
.gca file, and these exceed the max label we are expecting in a .gca atlas. 
Is there a reason you need them and not just left and right cortical gray 
matter labels? I don't think labeling folds will be terribly accurate with 
a volume morph, and there are downstream steps in recon-all that will do 
strange things if they can't find any cortical gray matter labels.


BTW: you may not know that you can directly visualize a .gca file with 
freeview. Just load it in freeview and it will come up as a multi-frame 
volume (frame 0 is the mean of the most likely class, frame 1 is the most 
likely class, and frame 2 is the prior of the most likely class). This is 
only a subset of what we store in the atlas, but it's a nice way to take a 
quick look and make sure everything looks ok

cheers
Bruce


On Tue, 24 Jan 2017, Florian Krismer wrote:


Hi Bruce,

It’s a custom atlas with minor changes that was build with the 
rebuild_gca_atlas.csh script.
What is puzzling to me is the fact that if I omit the align-after flag the 
mri_ca_register command works perfectly fine.

Many thanks & best wishes,
Florian


Am 24.01.17, 21:48 schrieb "Bruce Fischl" :

   I think that should be enough, but your data doesn't segfault for me. I
   also noticed the following in your recon-all.log file:

   usr/local/freesurfer/bin/recon-all
   -all -gca RB_all_2017-01-23.gca -gca-skull RB_all_withskull_2017-01-23.gca
   -subjid vco1573test_mpr


   are you using your own version of our atlases? Or did you rename them? I
   don't think we rebuilt any in 2017.

   cheers
   Bruce


   On
   Tue, 24 Jan 2017, Florian Krismer wrote:

   > Hi Bruce,
   >
   > it is a virtual machine with 8GB RAM dedicated to it. Any idea how much 
RAM would be enough?
   >
   > Thanks,
   > Florian
   >
   >
   >
   > Am 24.01.17, 21:39 schrieb "Bruce Fischl" 
:
   >
   >Hi Florian
   >
   >how much RAM do you have in that machine? I think it is not enough
   >cheers
   >Bruce
   >On
   >Tue, 24 Jan 2017, Florian Krismer wrote:
   >
   >> Dear FreeSurfer Developers,
   >>
   >> I'm attempting to run recon-all on a test subject (through recon-all 
–all –subjid test001 in Freesurfer 6). Recon-all hangs at the mri_ca_register command 
throwing a Segfault error.
   >>
   >> This is the corresponding part of the recon-all.log:
   >> 
---
   >> mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
   >>
   >> not handling expanded ventricles...
   >> using previously computed transform transforms/talairach.lta
   >> renormalizing sequences with structure alignment, equivalent to:
   >> -renormalize
   >> -regularize_mean 0.500
   >> -regularize 0.500
   >> using MR volume brainmask.mgz to mask input volume...
   >>
   >> == Number of threads available to mri_ca_register for OpenMP = 1 ==
   >> reading 1 input volumes...
   >> logging results to talairach.log
   >> reading input volume 'norm.mgz'...
   >> reading GCA 
'/usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca'...
   >> label assignment complete, 0 changed (0.00%)
   >> det(m_affine) = 1.26 (predicted orig area = 6.3)
   >> Segmentation fault
   >> 
---
   >>
   >>
   >> When debugging the error through gdb I get the following, additional 
information:
   >>
   >> 
---
   >>
   >> [florian@freesurfer]$ gdb --args mri_ca_register -rusage 
/usr/local/freesurfer/subjects/test001/touch/rusage.mri_ca_register.dat 
-nobigventricles -T transforms/talairach.lta -align-after -mask brainmask.mgz 
norm.mgz /usr/local/freesurfer/average/RB_all_2016-05-10.vc700.gca 
transforms/talairach.m3z
   >> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-90.el6)
   >> Copyright (C) 2010 Free Software Foundation, Inc.
   >> License GPLv3+: GNU GPL version 3 or later 

   >> This is free software: you are free to change and redistribute it.
   >> There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"
   >> and "show warranty" for details.
   >> This GDB was configured as "x86_64-redhat-linux-gnu".
   >> For bug reporting instructions, please see:
   >> ...
   >> Reading symbols from /usr/local/freesurfer/bin/mri_ca_register...(no 
debugging symbols found)...done.
   >> (gdb) run
   >> Starting

[Freesurfer] More freeview feature requests

[Chris Adamson]

Freesurfer devs,

Freeview is really nice to use. I have a few more suggestions:

It would be good to have keyboard shortcuts to change the brush size ala. 
Tkmedit.
A clone feature ala tkmedit that would be needed to fill in brainmask or 
brain.finalsurfs.manedit.mgz
When you are saving control points you have to manually change to the tmp 
directory and save as control.dat. It would be good to have an option that 
would automatically create this file.

Thanks in advance,

Chris Adamson.

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
_
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.