Re: [Freesurfer] Cortical gray matter surface area

[Douglas Greve]

The volume for each structure is given as the 4th column. If you want 
total GM volume, look in aseg.stats

doug


On 8/26/14 8:43 PM, will brown wrote:

Hi all,

I am a little unclear as to how to find the cortical grey matter 
volume in the stats output files. The ?.aparc.stats file shows:


Measure Cortex, WhiteSurfArea, White Surface Total Area, , mm^2

What about grey?

Thanks,
Will


___
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] Change in the location/path and the name of subject

[Douglas Greve]

no, that should not affect anything.  Once you do the fMRI analysis, 
changing the subject name then means having to re-register (or change 
the name in the registration files).
doug

On 8/27/14 12:05 AM, Reza Rajimehr wrote:
> Hi,
>
> I have got anatomicals of a subject from someone else. The anatomicals
> have been processed, and the surfaces have been reconstructed. The path to
> these files in my machine is obviously different from the path where data
> have been analyzed. I also want to change the name of the subject and give
> a name based on a convention that I have for my other subjects. Would the
> change in the location and name of the subject be problematic later on
> when I want to work with the anatomical data or use them during the
> functional data analysis? (re-processing of the anatomicals is not an
> option, since these are monkey data with heavy amounts of manual editings)
>
> Thanks,
> Reza
> ___
> 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] Change in the location/path and the name of subject

[Reza Rajimehr]

Hi,

I have got anatomicals of a subject from someone else. The anatomicals
have been processed, and the surfaces have been reconstructed. The path to
these files in my machine is obviously different from the path where data
have been analyzed. I also want to change the name of the subject and give
a name based on a convention that I have for my other subjects. Would the
change in the location and name of the subject be problematic later on
when I want to work with the anatomical data or use them during the
functional data analysis? (re-processing of the anatomicals is not an
option, since these are monkey data with heavy amounts of manual editings)

Thanks,
Reza
___
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] Cortical gray matter surface area

[will brown]

Hi all,

I am a little unclear as to how to find the cortical grey matter volume in
the stats output files. The ?.aparc.stats file shows:

Measure Cortex, WhiteSurfArea, White Surface Total Area, , mm^2

What about grey?

Thanks,
Will
___
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 version vs cvs version

[Nick Schmansky, MGH]

Joel,

The 'recon-all.log' file in the 'scripts' directory of the subject
should have the version of freesurfer used.  Also, the file
'build-stamp.txt' in that same directory will show the version used.

N,


On Tue, 2014-08-26 at 18:31 +, Joel R Pieper wrote:
> Hello,
> 
> I have 80 subjects' MRIs that were segmented in 2009 with a version of
> freesurfer that included this (cvs_version $Id: mri_segstats.c,v
> 1.11.2.5 2006/04/13 18:57:07 nicks Exp $) in the aseg.stats output.
> The other 19 of my subjects segmented in 2013 display this
> (cvs_version $Id: mri_segstats.c,v 1.33.2.5 2009/02/11 22:38:51 nicks
> Exp $) in the output. I think this latest version the 19 subjects were
> run on is freesurfer 4.4.0 but I'm not sure which freesurfer version
> the older segmentations were run on. The volumes I am looking at are
> significantly different between the subjects segmented in 2009 and
> those segmented in 2013. I would like to remove any bias in my data
> due to different software versions. Is there a way to know which
> freesurfer version output the older cvs_version so I can download that
> and resegment my 19 subjects to remove version bias? This would be
> much quicker than running all 100 subjects on the newest freesurfer
> version.
> 
> Joel Pieper
> ___
> 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] Individual commands in preproc-sess

[Douglas N Greve]

Hi Reza, if you look in preproc-sess you will see each of the commands 
that gets run. You can adapt the command lines from that
doug

On 08/24/2014 07:52 PM, Reza Rajimehr wrote:
> Hi,
>
> I want to use FreeSurfer v5.3 and its FS-FAST for the functional analysis
> of monkey data. To have a better control on the parameters of the
> analysis, I prefer to run the individual commands of preproc-sess
> one-by-one and check the output of each stage before proceeding with the
> rest of preproc-sess. Specifically I may manually edit the
> functional-anatomical registration, so I want to check the registration
> before moving on to the next step in preproc-sess. Also I need to skip the
> human-specific aspects of the analysis (e.g. Talairaching) if there are
> such things in preproc-sess. So is there a list of individual commends, in
> an appropriate order, that are used in preproc-sess?
>
> If someone has a routine for monkey data analysis with FreeSurfer v5.3, I
> would be happy to know about that as well.
>
> Thanks,
> Reza
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>

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

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

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


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

Re: [Freesurfer] success and failure of wm surfaces in (almost) identical structural image

[Douglas N Greve]

In the bad output of the fill, is it hanging onto the mask by a small 
thread, one that does not exist in the good wm/fill? When the wm is 
analyzed to get the fill, it removes "islands". I think that 
extracerebral stuff is an island in the good (and so removed) and still 
connected in the bad. It may be that the connection is just above some 
threshold in the bad but just below threshold in the good. Does this 
make sense?

doug


On 08/26/2014 06:08 PM, Vincent Beliveau wrote:
>
> That area outside the brain is not present in both wm.mgz and 
> filled.mgz for the failed output but for the good output, it is 
> present in wm.mgz but not in filled.mgz (see attached figures). Again, 
> given the similarity of the inputs it is surprising that the wm.mgz 
> and filled.mgz end up being segmented so differently.
>
> On 26.08.2014 23:41, Douglas N Greve wrote:
>
>> And is that area outside of the brain not present in the wm.mgz or
>> filled.mgz on the good output? The orig.nofix should hug the boundary of
>> the wm.mgz
>> doug
>>
>>
>> On 08/26/2014 04:53 PM, Vincent Beliveau wrote:
>>> I've attached ?h.orig.nofix for both recon with and without wm 
>>> error. They are similar to ?h.orig in the sense that the one from 
>>> the recon with wm error misclassifies part of dura as wm. 
>>> Interestingly when looking at ?h.orig.nofix from the recon with 
>>> error overlayed on brain.finalsurfs.mgz of the recon without error I 
>>> can see a few voxels in the misclassified dura are removed from 
>>> brain.finalsurfs, although not all. Could this small difference 
>>> explain why we see the wm error in one case and not the other? On 
>>> 26.08.2014 20:24, Douglas N Greve wrote:
 how about the ?h.orig.nofix On 08/26/2014 10:45 AM, Vincent 
 Beliveau wrote:
> Dear Sebastian, Attached is the *.orig for both recon (green being 
> the one with wm error and red being the one with error). 
> Unfortunately they are not identical; a section of the dura is 
> misclassified as wm in the red delineation. As mentionned before, 
> both orig.mgz are numerically identical in that area. As I also 
> mentionned before, the recon were ran on the same machine, same 
> os, same binaries. You expressed some confusion as to what were 
> trying to achieve. We want to figure out why, given numerically 
> almost identical inputs, Freesurfer correctly delineates wm in one 
> case but fails in the other. Unfortunately this type of error 
> appears to be systematic in some of our data. Vincent. On 
> 26.08.2014 16:22, Sebastian Moeller wrote:
>> Hi Vincent hi Melanie, please show us the *.orig surfaces on the 
>> critical slice. I predict that these will be identical, If so you 
>> can ignore everything except brain.finalsurfs.mgz. Are the two 
>> versions of this file identical around the area of mis-classified 
>> tissue? I predict that there will be a slight difference. Also if 
>> you take Vincent’s brain.finalsurf.mgz and put this into 
>> Melanie’s recon and redo the generation of the wm surfaces I 
>> predict that now Melinie’s version will show the same problem. On 
>> Aug 26, 2014, at 16:08 , Melanie Ganz > melanie.g...@nru.dk>melanie.g...@nru.dk>> 
>> wrote:
>>> Hi Sebastian, I'm afraid that the problem is slightly more 
>>> complicated. The inputs to recon-all are almost numerically 
>>> identical (to the 4th decimal); when converted to orig.mgz, all 
>>> voxels which are not identical (about only 700 of all the 
>>> 1677216 voxels) vary only by 1 due to rounding. Their 
>>> distribution is sparse and do not overlap with the white matter 
>>> errors. Can such a small source of variation give this kind of 
>>> difference? Ok, Freesurfer uses some random initialization, 
>>> however as far as I know the seed is not random and set to 1234. 
>>> We have looked at all the outputs created before wm.mgz 
>>> (orig,nu,T1,brainmask,norm,nu_noneck,aseg,brain,wm,filled) and 
>>> the only one showing a differences overlapping the wm errors is 
>>> filled.mgz;
>> I think the filled.mgz is changed during the generation of the wm 
>> surfaces (at least temporarily)...
>>> in all the other images the differences are minor.
>> Are you running the analyses on exactly the same machine and get 
>> different results or are you using two “identical” computers? I 
>> ask as I think there is a paper about the reproducibility of 
>> freesurfer reconstructions 
>> (http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0038234)
>>  
>> with different freesurfer versions or different 
>> hardware/operating systems that might explain a bit of systematic 
>> variance. But I guess I still do not exactly understand what the 
>> problem is that you want to solve here …. Best Regards Sebastian
>>> Thanks. Vincent. P.S.: I ke

[Freesurfer] White Matter and Pial Edit Question

[Thomas DeRamus]

Dear Freesurfer Experts,

I'm working on a younger population (around age 8), and I seem to have an
issue with the pial and wm surfaces grabbing dura on the images.

I've run gcut, -wsthresh at about 15, and even used the
talairach_with_skull_2.lta registration file to no avail, and I'd rather
not do manual edits if I don't have to.

Now I made the mistake of using a skull-stripped version of my original T1
and feeding into the pipeline before, but those images came out
significantly better looking than the raw T1 files. Problem is it thew off
the TICV measures by close to 500k compared to the originals.

So my question is, would it be feasible or kosher to put the brainmask and
wm.mgz values from those skull-stripped images into the problem folders
grabbing too much dura and re-running the subjects starting from autorecon2?

Thank you.

-- 
*Thomas DeRamus*
UAB Department of Psychology, Behavioral Neuroscience
Graduate Research Trainee
Civitan International Research Center
1719 6th Ave S, Suite 235J, Birmingham, AL 35233
*Phone*: 205-934-0971 *Email:* tpdera...@gmail.com, faus...@uab.edu
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

Re: [Freesurfer] success and failure of wm surfaces in (almost) identical structural image

[Vincent Beliveau]

 

That area outside the brain is not present in both wm.mgz and
filled.mgz for the failed output but for the good output, it is present
in wm.mgz but not in filled.mgz (see attached figures). Again, given the
similarity of the inputs it is surprising that the wm.mgz and filled.mgz
end up being segmented so differently. 

On 26.08.2014 23:41, Douglas N
Greve wrote: 

> And is that area outside of the brain not present in
the wm.mgz or 
> filled.mgz on the good output? The orig.nofix should
hug the boundary of 
> the wm.mgz
> doug
> 
> On 08/26/2014 04:53 PM,
Vincent Beliveau wrote:
> 
>> I've attached ?h.orig.nofix for both recon
with and without wm error. They are similar to ?h.orig in the sense that
the one from the recon with wm error misclassifies part of dura as wm.
Interestingly when looking at ?h.orig.nofix from the recon with error
overlayed on brain.finalsurfs.mgz of the recon without error I can see a
few voxels in the misclassified dura are removed from brain.finalsurfs,
although not all. Could this small difference explain why we see the wm
error in one case and not the other? On 26.08.2014 20:24, Douglas N
Greve wrote: 
>> 
>>> how about the ?h.orig.nofix On 08/26/2014 10:45
AM, Vincent Beliveau wrote: 
>>> 
 Dear Sebastian, Attached is the
*.orig for both recon (green being the one with wm error and red being
the one with error). Unfortunately they are not identical; a section of
the dura is misclassified as wm in the red delineation. As mentionned
before, both orig.mgz are numerically identical in that area. As I also
mentionned before, the recon were ran on the same machine, same os, same
binaries. You expressed some confusion as to what were trying to
achieve. We want to figure out why, given numerically almost identical
inputs, Freesurfer correctly delineates wm in one case but fails in the
other. Unfortunately this type of error appears to be systematic in some
of our data. Vincent. On 26.08.2014 16:22, Sebastian Moeller wrote:

 
> Hi Vincent hi Melanie, please show us the *.orig surfaces
on the critical slice. I predict that these will be identical, If so you
can ignore everything except brain.finalsurfs.mgz. Are the two versions
of this file identical around the area of mis-classified tissue? I
predict that there will be a slight difference. Also if you take
Vincent's brain.finalsurf.mgz and put this into Melanie's recon and redo
the generation of the wm surfaces I predict that now Melinie's version
will show the same problem. On Aug 26, 2014, at 16:08 , Melanie Ganz
melanie.g...@nru.dk>>
wrote: 
> 
>> Hi Sebastian, I'm afraid that the problem is
slightly more complicated. The inputs to recon-all are almost
numerically identical (to the 4th decimal); when converted to orig.mgz,
all voxels which are not identical (about only 700 of all the 1677216
voxels) vary only by 1 due to rounding. Their distribution is sparse and
do not overlap with the white matter errors. Can such a small source of
variation give this kind of difference? Ok, Freesurfer uses some random
initialization, however as far as I know the seed is not random and set
to 1234. We have looked at all the outputs created before wm.mgz
(orig,nu,T1,brainmask,norm,nu_noneck,aseg,brain,wm,filled) and the only
one showing a differences overlapping the wm errors is filled.mgz;
>
I think the filled.mgz is changed during the generation of the wm
surfaces (at least temporarily)... 
> 
>> in all the other
images the differences are minor.
> Are you running the analyses on
exactly the same machine and get different results or are you using two
"identical" computers? I ask as I think there is a paper about the
reproducibility of freesurfer reconstructions
(http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0038234
[24]) with different freesurfer versions or different
hardware/operating systems that might explain a bit of systematic
variance. But I guess I still do not exactly understand what the problem
is that you want to solve here …. Best Regards Sebastian

___ Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu [25] Freesurfer@nmr.mgh.harvard.edu>
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer [26]
>>> --
Douglas N. Greve, Ph.D. MGH-NMR Center gr...@nmr.mgh.harvard.edu [27]
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 [28]
www.nmr.mgh.harvard.edu/facility/filedrop/index.html [29]

Outgoing:ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
[31] ___ Freesurfer mailing
list Freesurfer@nmr.mgh.harvard.edu [32] Freesurfer@nmr.mgh.harvard.edu>
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer [33]
>>
___ Freesurfer maili

Re: [Freesurfer] success and failure of wm surfaces in (almost) identical structural image

[Douglas N Greve]

And is that area outside of the brain not present in the wm.mgz or 
filled.mgz on the good output? The orig.nofix should hug the boundary of 
the wm.mgz
doug


On 08/26/2014 04:53 PM, Vincent Beliveau wrote:
>
> I've attached ?h.orig.nofix for both recon with and without wm error. 
> They are similar to ?h.orig in the sense that the one from the recon 
> with wm error misclassifies part of dura as wm. Interestingly when 
> looking at ?h.orig.nofix from the recon with error overlayed on 
> brain.finalsurfs.mgz of the recon without error I can see a few voxels 
> in the misclassified dura are removed from brain.finalsurfs, although 
> not all. Could this small difference explain why we see the wm error 
> in one case and not the other?
>
> On 26.08.2014 20:24, Douglas N Greve wrote:
>
>> how about the ?h.orig.nofix
>>
>> On 08/26/2014 10:45 AM, Vincent Beliveau wrote:
>>> Dear Sebastian, Attached is the *.orig for both recon (green being 
>>> the one with wm error and red being the one with error). 
>>> Unfortunately they are not identical; a section of the dura is 
>>> misclassified as wm in the red delineation. As mentionned before, 
>>> both orig.mgz are numerically identical in that area. As I also 
>>> mentionned before, the recon were ran on the same machine, same os, 
>>> same binaries. You expressed some confusion as to what were trying 
>>> to achieve. We want to figure out why, given numerically almost 
>>> identical inputs, Freesurfer correctly delineates wm in one case but 
>>> fails in the other. Unfortunately this type of error appears to be 
>>> systematic in some of our data. Vincent. On 26.08.2014 16:22, 
>>> Sebastian Moeller wrote:
 Hi Vincent hi Melanie, please show us the *.orig surfaces on the 
 critical slice. I predict that these will be identical, If so you 
 can ignore everything except brain.finalsurfs.mgz. Are the two 
 versions of this file identical around the area of mis-classified 
 tissue? I predict that there will be a slight difference. Also if 
 you take Vincent’s brain.finalsurf.mgz and put this into Melanie’s 
 recon and redo the generation of the wm surfaces I predict that now 
 Melinie’s version will show the same problem. On Aug 26, 2014, at 
 16:08 , Melanie Ganz >>> melanie.g...@nru.dk>> wrote:
> Hi Sebastian, I'm afraid that the problem is slightly more 
> complicated. The inputs to recon-all are almost numerically 
> identical (to the 4th decimal); when converted to orig.mgz, all 
> voxels which are not identical (about only 700 of all the 1677216 
> voxels) vary only by 1 due to rounding. Their distribution is 
> sparse and do not overlap with the white matter errors. Can such a 
> small source of variation give this kind of difference? Ok, 
> Freesurfer uses some random initialization, however as far as I 
> know the seed is not random and set to 1234. We have looked at all 
> the outputs created before wm.mgz 
> (orig,nu,T1,brainmask,norm,nu_noneck,aseg,brain,wm,filled) and the 
> only one showing a differences overlapping the wm errors is 
> filled.mgz;
 I think the filled.mgz is changed during the generation of the wm 
 surfaces (at least temporarily)...
> in all the other images the differences are minor.
 Are you running the analyses on exactly the same machine and get 
 different results or are you using two “identical” computers? I ask 
 as I think there is a paper about the reproducibility of freesurfer 
 reconstructions 
 (http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0038234)
  
 with different freesurfer versions or different hardware/operating 
 systems that might explain a bit of systematic variance. But I 
 guess I still do not exactly understand what the problem is that 
 you want to solve here …. Best Regards Sebastian
> Thanks. Vincent. P.S.: I keep sending the mails, since Vincent has 
> problems posting to the list. ;-) On 26-08-2014 15:32, Sebastian 
> Moeller wrote:
>> Hi Melanie, I guess your post got me confused then, since you did 
>> not really explain what your figure shows. With the information 
>> from this post I assume that red and yellow are wm and pia 
>> respectively from and recon and blue and green are from the 
>> second. On Aug 26, 2014, at 15:16 , Melanie Ganz 
>> > melanie.g...@nru.dk>> wrote:
>>> Hi Sebastian, it is clear to us how to fix this, this is not the 
>>> issue here. The issue is that my colleague and I ran the same 
>>> image, he used the original dicom as source and I a nifti 
>>> version prepared for other processing,
>> Plain conversion of dicim to nifty or further processing?
>>> and we get very different results! And this even thought the 
>>> actual images vary quite a bit.
>> Well some processes use random seeds, so if t

[Freesurfer] watershed surface to volume rendering

[Sherwood, Matt]

Freesurfer,
We have scans that have recon-all completed. Following 
recon-all, we completed watershed (under the MNE toolbox) to extract skull and 
scalp from the T1 scans. The outputs of this algorithm are outer brain, inner 
skull, outer skull and outer scalp surfaces. We are particularly interested in 
these volumes for our study. Is there a way to convert these surface to volumes 
representative of CSF (layer between brain/skull), skull (inner to outer skull 
surface) and skin (outer skull to outer scalp)?

Matthew Sherwood
Medical Research Engineer

Wright State Research Institute
4035 Colonel Glenn Hwy.
Dayton, OH 45431

PH: 937.705.1025
FAX: 937.705.1095
EMAIL: matt.sherw...@wright.edu

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


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

[Freesurfer] Color scale in tksurfer

[Katharina Zech]

Dear all,

I've got a question: is the color that I get for significant clusters in
tksurfer depending on the contrast vector specified? For example: when I
get a red cluster and my question of interest would be: "is there a
difference between Males and Females regressing out the effect of age and
handedness?", then the clusters would pop-up in red for Males being bigger
then Woman. Is that correct?

Thanks!

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


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

Re: [Freesurfer] ERROR: cannot find AFNI command 3dvolreg.afni

[Z K]

Hello Robby,

You can download the 3dvolreg.afni file using the following link:

ftp://surfer.nmr.mgh.harvard.edu//pub/dist/freesurfer/5.3.0-patch/lion/

Please download it and copy it to your "/Applications/freesurfer/bin" 
directory.

-Zeke

On 08/26/2014 10:42 AM, Robby De Pauw wrote:
> Dear FreeSurfer
>
> As I am trying to preprocess my fMRI data through FsFast, I came across
> this error:
>
> ERROR: cannot find AFNI command 3dvolreg.afni
>
> I’m using a mac and bash-shell. I’ve also attached the log-file.
>
> This is the command I used:
>
> preproc-sess -s GEZ_004_HACO/ -surface fsaverage -mni305 -fwhm 5
> -per-run -fsd bold -stc up
>
> Regards
>
> Robby
>
>
>
>
>
> Robby De Pauw, dra.
> *Ghent University*
> Department of Physiotherapy and Rehabilitation Sciences
> 3B3
> De Pintelaan 185
> B-9000 Ghent
>
> robby.dep...@ugent.be 
>
>
>
>
>
>
>
> ___
> 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] freesurfer version vs cvs version

[Joel R Pieper]

Hello,

I have 80 subjects' MRIs that were segmented in 2009 with a version of 
freesurfer that included this (cvs_version $Id: mri_segstats.c,v 1.11.2.5 
2006/04/13 18:57:07 nicks Exp $) in the aseg.stats output. The other 19 of my 
subjects segmented in 2013 display this (cvs_version $Id: mri_segstats.c,v 
1.33.2.5 2009/02/11 22:38:51 nicks Exp $) in the output. I think this latest 
version the 19 subjects were run on is freesurfer 4.4.0 but I'm not sure which 
freesurfer version the older segmentations were run on. The volumes I am 
looking at are significantly different between the subjects segmented in 2009 
and those segmented in 2013. I would like to remove any bias in my data due to 
different software versions. Is there a way to know which freesurfer version 
output the older cvs_version so I can download that and resegment my 19 
subjects to remove version bias? This would be much quicker than running all 
100 subjects on the newest freesurfer version.

Joel Pieper
___
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] success and failure of wm surfaces in (almost) identical structural image

[Douglas N Greve]

how about the ?h.orig.nofix

On 08/26/2014 10:45 AM, Vincent Beliveau wrote:
>
> Dear Sebastian,
>
> Attached is the *.orig for both recon (green being the one with wm 
> error and red being the one with error). Unfortunately they are not 
> identical; a section of the dura is misclassified as wm in the red 
> delineation. As mentionned before, both orig.mgz are numerically 
> identical in that area. As I also mentionned before, the recon were 
> ran on the same machine, same os, same binaries.
>
> You expressed some confusion as to what were trying to achieve. We 
> want to figure out why, given numerically almost identical inputs, 
> Freesurfer correctly delineates wm in one case but fails in the other. 
> Unfortunately this type of error appears to be systematic in some of 
> our data.
>
> Vincent.
>
> On 26.08.2014 16:22, Sebastian Moeller wrote:
>
>> Hi Vincent hi Melanie,
>> please show us the *.orig surfaces on the critical slice. I predict 
>> that these will be identical, If so you can ignore everything except 
>> brain.finalsurfs.mgz. Are the two versions of this file identical 
>> around the area of mis-classified tissue? I predict that there will 
>> be a slight difference. Also if you take Vincent’s 
>> brain.finalsurf.mgz and put this into Melanie’s recon and redo the 
>> generation of the wm surfaces I predict that now Melinie’s version 
>> will show the same problem.
>>
>> On Aug 26, 2014, at 16:08 , Melanie Ganz > > wrote:
>>
>>> Hi Sebastian,
>>>
>>> I'm afraid that the problem is slightly more complicated. The inputs 
>>> to recon-all are almost numerically identical (to the 4th decimal); 
>>> when converted to orig.mgz, all voxels which are not identical 
>>> (about only 700 of all the 1677216 voxels) vary only by 1 due to 
>>> rounding. Their distribution is sparse and do not overlap with the 
>>> white matter errors. Can such a small source of variation give this 
>>> kind of difference? Ok, Freesurfer uses some random initialization, 
>>> however as far as I know the seed is not random and set to 1234. We 
>>> have looked at all the outputs created before wm.mgz 
>>> (orig,nu,T1,brainmask,norm,nu_noneck,aseg,brain,wm,filled) and the 
>>> only one showing a differences overlapping the wm errors is filled.mgz;
>> I think the filled.mgz is changed during the generation of the wm 
>> surfaces (at least temporarily)...
>>
>>> in all the other images the differences are minor.
>> Are you running the analyses on exactly the same machine and get 
>> different results or are you using two “identical” computers? I ask 
>> as I think there is a paper about the reproducibility of freesurfer 
>> reconstructions 
>> (http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0038234) 
>> with different freesurfer versions or different hardware/operating 
>> systems that might explain a bit of systematic variance.
>> But I guess I still do not exactly understand what the problem is 
>> that you want to solve here ….
>> Best Regards
>> Sebastian
>>
>>>
>>> Thanks.
>>>
>>> Vincent.
>>>
>>>
>>> P.S.: I keep sending the mails, since Vincent has problems posting 
>>> to the list. ;-)
>>>
>>> On 26-08-2014 15:32, Sebastian Moeller wrote:
 Hi Melanie,


 I guess your post got me confused then, since you did not really 
 explain what your figure shows. With the information from this post 
 I assume that red and yellow are wm and pia respectively from and 
 recon and blue and green are from the second.

 On Aug 26, 2014, at 15:16 , Melanie Ganz >>> > wrote:

> Hi Sebastian,
>
> it is clear to us how to fix this, this is not the issue here.
> The issue is that my colleague and I ran the same image, he used 
> the original dicom as source and I a nifti version prepared for 
> other processing,

 Plain conversion of dicim to nifty or further processing?

> and we get very different results! And this even thought the 
> actual images vary quite a bit.

 Well some processes use random seeds, so if these differs between 
 reckons and the intensity of the dura is close to threshold for 
 skull stripping you got your problem right there. Have a look at 
 the orig surfaces, if those do not show wrong wm-voxels in the dura 
 its the refinement process later on that introduces this problem. 
 You state in a later map that there are differences in brain 
 mask.mgz, which I believe to be the input for the volume to use for 
 image gradient based surface adjustments (actually brain mask.mgz 
 should be a start of a chain that ends in brain.finalsurfs.mgz I 
 believe). So from my understanding this makes all sense. But 
 unfortunately is not going to help you...

> So thanks for the input, but this does not explain our processing 
> difference. Especially not, since the wm.mgz files are basically 
> identical.
>>

Re: [Freesurfer] labelled tissue segmentation mask back to native

[Alejandra Machado]

thank you Bruce and Douglas for your reply!

Alejandra



2014-08-20 13:07 GMT+02:00 Alejandra Machado :

> Hello,
>
> I was wondering if FS has an output mask (labelled volume) for each tissue
> types (gm+wm+venctricular_csf) that I can then turn into each subject's
> native space. I understand I can use aseg.mgz or even aparc+aseg.mgz and
> then run mri_label2vol. But then how do I get correspondent labelling for
> each subject in it's own native space?
>
> Thanks,
> Alejandra
>
___
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] success and failure of wm surfaces in (almost) identical structural image

[Sebastian Moeller]

Hi Vincent,


On Aug 26, 2014, at 16:45 , Vincent Beliveau  wrote:

> Dear Sebastian,
> 
> Attached is the *.orig for both recon (green being the one with wm error and 
> red being the one with error).

I see, what about the *.orig.nofix? I just noticed that the *.orig are 
still run through the topology fixer… If I am right (and I guess my track 
record is murky by now) the question is why does the topology fixer do this.

> Unfortunately they are not identical; a section of the dura is misclassified 
> as wm in the red delineation. As mentionned before, both orig.mgz are 
> numerically identical in that area.
> As I also mentionned before, the recon were ran on the same machine, same os, 
> same binaries.

Thanks for making this unambiguously clear.

> 
> You expressed some confusion as to what were trying to achieve. We want to 
> figure out why, given numerically almost identical inputs, Freesurfer 
> correctly delineates wm in one case but fails in the other. Unfortunately 
> this type of error appears to be systematic in some of our data.

Well, if you always have cases of dura matter misclassified as wm, 
change your acquisition to have darker dura, or improve the skull stripping 
step of the recon and you should be set ;). Or use T2 images to refine the pia 
mater (I have not tested that, but I assume that would get rid of the 
artificial wm created by the process).
I guess, I am at the end of my wits here, and hope that some of the 
freesurfer developers can solve this riddle with you.

Best Regards
Sebastian

> 
> Vincent.
> 
>  
> On 26.08.2014 16:22, Sebastian Moeller wrote:
> 
>> Hi Vincent hi Melanie,
>> please show us the *.orig surfaces on the critical slice. I predict that 
>> these will be identical, If so you can ignore everything except 
>> brain.finalsurfs.mgz. Are the two versions of this file identical around the 
>> area of mis-classified tissue? I predict that there will be a slight 
>> difference. Also if you take Vincent’s brain.finalsurf.mgz and put this into 
>> Melanie’s recon and redo the generation of the wm surfaces I predict that 
>> now Melinie’s version will show the same problem.
>> 
>> On Aug 26, 2014, at 16:08 , Melanie Ganz  wrote:
>> 
>>> Hi Sebastian,
>>> 
>>> I'm afraid that the problem is slightly more complicated. The inputs to 
>>> recon-all are almost numerically identical (to the 4th decimal); when 
>>> converted to orig.mgz, all voxels which are not identical (about only 700 
>>> of all the 1677216 voxels) vary only by 1 due to rounding. Their 
>>> distribution is sparse and do not overlap with the white matter errors. Can 
>>> such a small source of variation give this kind of difference? Ok, 
>>> Freesurfer uses some random initialization, however as far as I know the 
>>> seed is not random and set to 1234. We have looked at all the outputs 
>>> created before wm.mgz 
>>> (orig,nu,T1,brainmask,norm,nu_noneck,aseg,brain,wm,filled) and the only one 
>>> showing a differences overlapping the wm errors is filled.mgz;
>>  I think the filled.mgz is changed during the generation of the wm surfaces 
>> (at least temporarily)...
>> 
>>> in all the other images the differences are minor.
>>  Are you running the analyses on exactly the same machine and get different 
>> results or are you using two “identical” computers? I ask as I think there 
>> is a paper about the reproducibility of freesurfer reconstructions 
>> (http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0038234) 
>> with different freesurfer versions or different hardware/operating systems 
>> that might explain a bit of systematic variance.
>>  But I guess I still do not exactly understand what the problem is that you 
>> want to solve here ….
>> Best Regards
>>  Sebastian
>> 
>>> 
>>> Thanks.
>>> 
>>> Vincent.
>>> 
>>> 
>>> P.S.: I keep sending the mails, since Vincent has problems posting to the 
>>> list. ;-)
>>> 
>>> On 26-08-2014 15:32, Sebastian Moeller wrote:
 Hi Melanie,
 
 
 I guess your post got me confused then, since you did not really explain 
 what your figure shows. With the information from this post I assume that 
 red and yellow are wm and pia respectively from and recon and blue and 
 green are from the second.
 
 On Aug 26, 2014, at 15:16 , Melanie Ganz  wrote:
 
> Hi Sebastian,
> 
> it is clear to us how to fix this, this is not the issue here.
> The issue is that my colleague and I ran the same image, he used the 
> original dicom as source and I a nifti version prepared for other 
> processing,
 
  Plain conversion of dicim to nifty or further processing?
 
> and we get very different results! And this even thought the actual 
> images vary quite a bit.
 
  Well some processes use random seeds, so if these differs between reckons 
 and the intensity of the dura is close to threshold for skull stripping 
 you got your problem

Re: [Freesurfer] success and failure of wm surfaces in (almost) identical structural image

[Vincent Beliveau]

 

Dear Sebastian, 

Attached is the *.orig for both recon (green being
the one with wm error and red being the one with error). Unfortunately
they are not identical; a section of the dura is misclassified as wm in
the red delineation. As mentionned before, both orig.mgz are numerically
identical in that area. As I also mentionned before, the recon were ran
on the same machine, same os, same binaries. 

You expressed some
confusion as to what were trying to achieve. We want to figure out why,
given numerically almost identical inputs, Freesurfer correctly
delineates wm in one case but fails in the other. Unfortunately this
type of error appears to be systematic in some of our data. 

Vincent.


On 26.08.2014 16:22, Sebastian Moeller wrote: 

> Hi Vincent hi
Melanie, 
> please show us the *.orig surfaces on the critical slice. I
predict that these will be identical, If so you can ignore everything
except brain.finalsurfs.mgz. Are the two versions of this file identical
around the area of mis-classified tissue? I predict that there will be a
slight difference. Also if you take Vincent's brain.finalsurf.mgz and
put this into Melanie's recon and redo the generation of the wm surfaces
I predict that now Melinie's version will show the same problem. 
> 
>
On Aug 26, 2014, at 16:08 , Melanie Ganz 
wrote:
> 
>> Hi Sebastian,
>> 
>> I'm afraid that the problem is
slightly more complicated. The inputs to recon-all are almost
numerically identical (to the 4th decimal); when converted to orig.mgz,
all voxels which are not identical (about only 700 of all the 1677216
voxels) vary only by 1 due to rounding. Their distribution is sparse and
do not overlap with the white matter errors. Can such a small source of
variation give this kind of difference? Ok, Freesurfer uses some random
initialization, however as far as I know the seed is not random and set
to 1234. We have looked at all the outputs created before wm.mgz
(orig,nu,T1,brainmask,norm,nu_noneck,aseg,brain,wm,filled) and the only
one showing a differences overlapping the wm errors is filled.mgz;
> 
>
I think the filled.mgz is changed during the generation of the wm
surfaces (at least temporarily)... 
> 
>> in all the other images the
differences are minor.
> 
> Are you running the analyses on exactly the
same machine and get different results or are you using two "identical"
computers? I ask as I think there is a paper about the reproducibility
of freesurfer reconstructions
(http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0038234
[4]) with different freesurfer versions or different hardware/operating
systems that might explain a bit of systematic variance. 
> But I guess
I still do not exactly understand what the problem is that you want to
solve here …. 
> Best Regards 
> Sebastian 
> 
> Thanks.
> 
> Vincent.
>

> P.S.: I keep sen
> 
>> stian Moeller wrote:
>> 
>>> Hi Melanie,
>>>

>>> I guess your post got me confused then, since you did not really
explain what your figure shows. With the information from this post I
assume that red and yellow are wm and pia respectively from and recon
and blue and green are from the second.
>>> 
>>> On Aug 26, 2014, at
15:16 , Melanie Ganz  wrote:
>>> 
 Hi
Sebastian,
 
 it is clear to us how to fix this, this is not the
issue here.
>>> 
 The issue is that my colleague and I ran the same
image, he used the original dicom as source and I a nifti version
prepared for other processing,
>>> 
>>> Plain conversion of dicim to
nifty or further processing?
>> 
>> -- 
>> Melanie Ganz, MSc, Ph.D. 
>>
Neurobiology Research Unit 
>> University of Copenhagen 
>>
Rigshospitalet 
>> Rockefeller Center 
>> Juliane Maries Vej 28/30, 3.

>> DK-2100 Copenhagen 
>> Denmark 
>> phone: +45 3545 6718 
>> e-mail:
melanie.g...@nru.dk [2] 
>> web: http://melanie.clausundmelanie.de/
>>
___
>> 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.

 

Links:
--
[1] mailto:melanie.g...@nru.dk
[2]
mailto:melanie.g...@nru.dk
[3] mailto:melanie.g...@nru.dk
[4]
http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0038234
___
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, p

[Freesurfer] ERROR: cannot find AFNI command 3dvolreg.afni

[Robby De Pauw]

Dear FreeSurferAs I am trying to preprocess my fMRI data through FsFast, I came across this error:ERROR: cannot find AFNI command 3dvolreg.afniI’m using a mac and bash-shell. I’ve also attached the log-file.This is the command I used:preproc-sess -s GEZ_004_HACO/ -surface fsaverage -mni305 -fwhm 5 -per-run -fsd bold -stc upRegardsRobby

preproc-GEZ_004_HACO-bold.log
Description: Binary data

Robby De Pauw, dra.Ghent UniversityDepartment of Physiotherapy and Rehabilitation Sciences3B3De Pintelaan 185B-9000 Ghentrobby.dep...@ugent.be

___
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] problemi with mri_glmfit-sim

[angela . favaro]

thank you!
that solved my problem!


>
> I think this has something to do with the unix LOCALE because it is
> interpreting the "2.0" as "2,0" using the comma "," instead of the "."
> I actually don't know how to fix this. If you run
>
> echo $LANG
>
> does it return
>
> en_US.UTF-8
>
> if not, as a test, try
> setenv LANG en_US.UTF-8
>
> Then run mri_glmfit-sim
>
> doug
>
> On 8/24/14 1:00 PM, angela.fav...@unipd.it wrote:
>> Hi Doug,
>> already done!
>>
>> mri_glmfit-sim --glmdir glm.lh.lh-rh.thickness.sm10 --cwpvalthresh .5
>> --cache 2.0 abs
>>
>> printf: 2.0: not completely converted
>> ERROR: thresh = 2,0, must be 1.3, 2.0, 2.3, 3.0, 3.3, 4.0
>>
>> what does it mean?
>> I am using a MacOSX 10.6.8
>> thank you for your help
>>
>> Angela
>>
>>
>>> Try using --cache 2.0 abs
>>>
>>> On 8/24/14 9:41 AM, angela.fav...@unipd.it wrote:
 Hi all,
 I am having a problem with mri_glmfit-sim:

 my command was:
 mri_glmfit-sim --glmdir glm.lh.lh-rh.thickness.sm10 --cwpvalthresh .5
 --cache 2 abs

 and this is the only output:

 ERROR: thresh = 2,0, must be 1.3, 2.0, 2.3, 3.0, 3.3, 4.0

 I am not able to understand which is the source of this error. Can
 somebody help me?

 thank you

 Angela


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


>>> ___
>>> Freesurfer mailing list
>>> Freesurfer@nmr.mgh.harvard.edu
>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>>
>>>
>>> The information in this e-mail is intended only for the person to whom
>>> it
>>> is
>>> addressed. If you believe this e-mail was sent to you in error and the
>>> e-mail
>>> contains patient information, please contact the Partners Compliance
>>> HelpLine at
>>> http://www.partners.org/complianceline . If the e-mail was sent to you
>>> in
>>> error
>>> but does not contain patient information, please contact the sender and
>>> properly
>>> dispose of the e-mail.
>>>
>>>
>>>
>>
>>
>> ___
>> Freesurfer mailing list
>> Freesurfer@nmr.mgh.harvard.edu
>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>
>>
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>



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

Re: [Freesurfer] asymmetry analyses

[angela . favaro]

thank you!
Angela

>
> You can use --paired-diff-norm instead of --paired-diff, this will compute
>
> (L-R)/((L+R)/2)
>
> You can then divide the output by 2, eg,
>
> fscalc output.mgh div 2 -o output.div2.mgh
>
> doug
>
>
>
>
> On 8/24/14 9:52 AM, angela.fav...@unipd.it wrote:
>> Hi all,
>> I have a question about hemispheric asymmetry analyses. The example
>> given
>> in the wiki shows how to compare lh and rh using a paired t-test. Is it
>> right?
>> But how can I calculate (and then compare groups) the laterality index
>> (L-R)/(L+R)?
>> Thank you very much for any help
>>
>> Angela
>>
>>
>>
>>
>> ___
>> Freesurfer mailing list
>> Freesurfer@nmr.mgh.harvard.edu
>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>
>>
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
>
>



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

[Freesurfer] Fwd: Re: success and failure of wm surfaces in (almost) identical structural image

[Melanie Ganz]

Thanks to Eugenio, for the tip!

We did look at (orig,nu,T1,brainmask,norm,nu,noneck, aseg, wm, 
filled).mgz. The only one showing a difference where our white matter 
error occurs is filled.mgz.
In some of the other previous images are minor differences around that 
area, but not overlapping the area. This starts with the brainmask.mgz. 
The wm.mgz looks almost identical though and this is what is used in 
making filled.mgz, right?


Cheers,
Mel and Vincent

P.S.: Here's a quick script to visualize all differences:

recon1='/data1/vbeliveau/atlas/proc/MR/recon/v0013_good'; %change this
recon2='/data1/vbeliveau/atlas/proc/MR/recon/v0013_bad'; %change this
dest='/data1/vbeliveau/atlas/test'; %change this

img1=MRIread([recon1 '/mri/orig/001.mgz']);
img2=MRIread([recon2 '/mri/orig/001.mgz']);
img1.vol=img1.vol-img2.vol;
MRIwrite(img1,[dest '/diff_raw.mgz']);
disp('raw');
sum(img1.vol(:)>10e-4)

vol={'orig','nu','T1','brainmask','norm','nu_noneck','aseg','brain','wm','filled'};

for n=1:numel(vol)
img1=MRIread([recon1 '/mri/' vol{n} '.mgz']);
img2=MRIread([recon2 '/mri/' vol{n} '.mgz']);
img1.vol=img1.vol-img2.vol;
MRIwrite(img1,[dest '/diff_' vol{n} '.mgz']);
disp(vol{n});
sum(img1.vol(:)>10e-4)
end




 Original Message 
Subject: 	Re: [Freesurfer] success and failure of wm surfaces in 
(almost) identical structural image

Date:   Tue, 26 Aug 2014 14:05:19 +0200 (CEST)
From:   Eugenio Iglesias 
To: Melanie Ganz 



It'd be really helpful if you looked at where the two pipelines start to 
diverge. It's apparent that the origs are the same, and that the surfaces are 
different, but where does the divergence begin? Are the nu.mgz's similar? How 
about the the brainmask.mgz's?
Here's the recon table: 
https://surfer.nmr.mgh.harvard.edu/fswiki/ReconAllDevTable

Best,
/E


Juan Eugenio Iglesias
Postdoctoral researcher BCBL
www.jeiglesias.com
www.bcbl.eu

Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer


- Original Message -
From: "Melanie Ganz" 
To: freesurfer@nmr.mgh.harvard.edu
Sent: Tuesday, August 26, 2014 7:50:23 AM
Subject: [Freesurfer] success and failure of wm surfaces in (almost) identical 
structural image

Dear Freesurfer community,

We've encountered a strange situation where the pial and wm surface
delineation is successful for one image but contains wm (and subsequent
pial) errors for another, almost identical structural image (see
attached image, red and yellow are for the successful surface and blue
and green are for the failed one). We've tried to identify the source
for this discrepancy but I'm at a loss. All voxels of the original input
images are identical to the 4th decimal and when converted to orig.mgz
only a few voxels appear to be different due to rounding, none of which
overlap with the wm surface errors. Both images were processed on the
same setup (hardware and software, Freesurfer stable 5.3).
Unfortunately, this error is quite systematic in my dataset; about 10%
of the images show this type of error. Any suggestions on how to
investigate this? I've uploaded example of good and bad at
recon ftp://surfer.nmr.mgh.harvard.edu/transfer/incoming/failed_wm_recon.tar.gz
in case you'd like to have a closer look.

Thanks for your help.

Vincent and Melanie




___
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] matrix is ill-conditioned or badly scaled

[Jürgen Hänggi]

Hi Doug

Thanks a lot for your answer

Cheers
Jürgen

---
-
Jürgen Hänggi, Ph.D.
Division Neuropsychology
Institute of Psychology
University of Zurich
Binzmuehlestrasse 14, PO Box 25
8050 Zurich, Switzerland
0041 44 635 73 97 (phone office)
0041 76 445 86 84 (phone mobile)
0041 44 635 74 09 (fax office)
BIN 4.D.04 (office room number)
j.haenggi[at]psychologie.uzh.ch (email)
http://www.psychologie.uzh.ch/neuropsy/ (website)
http://www.juergenhaenggi.ch (private website)

This e-mail (and any attachment/s) contains confidential and/or privileged
information. If you are not the intended recipient (or have received this
e-mail in error) please notify the sender immediately and destroy this
e-mail. Any unauthorised copying, disclosure or distribution of the
material in this e-mail is strictly forbidden.
---
-





Am 22.08.14 18:36 schrieb "Douglas N Greve" unter
:

>
>Looks like your fsgd file was created under a windows machine or old
>macos, try converting the fsgd like this
>
>cat old.fsgd | sed 's/\\r/\\n/g' > new.fsgd
>
>
>
>
>On 08/22/2014 02:51 AM, Jürgen Hänggi wrote:
>> Dear FS experts
>>
>> We run mri_glmfit and encountered the following error:
>>
>> INFO: gd2mtx_method is doss
>> Saving design matrix to
>> LTHV_Thickness_LH_correlation_memory2.glmdir/Xg.dat
>> Normalized matrix condition is 1e+08
>> Design matrix --
>> 
>> ERROR: matrix is ill-conditioned or badly scaled, condno = 1e+08
>>
>> The command line is as follow:
>>
>> mri_glmfit --y LTHV_lh_thickness.15.mgh --fsgd
>> LTHV_fsgd_correlation_memory2.txt doss --glmdir
>> LTHV_Thickness_LH_correlation_memory2.glmdir --surf average_LTHV_TP1
>> lh --C LTHV_Design_corr.mat ‹cortex
>>
>> The FSGD and Design files are attached
>>
>> We did not find the problem.
>>
>> Thanks in advance for your help.
>>
>> Regards
>> Jürgen Hänggi
>>
>> 
>>-
>>---
>> Jürgen Hänggi, Ph.D.
>> Division Neuropsychology
>> Institute of Psychology
>> University of Zurich
>> Binzmuehlestrasse 14, PO Box 25
>> 8050 Zurich, Switzerland
>> 0041 44 635 73 97 (phone office)
>> 0041 76 445 86 84 (phone mobile)
>> 0041 44 635 74 09 (fax office)
>> BIN 4.D.04 (office room number)
>> j.haenggi[at]psychologie.uzh.ch (email)
>> http://www.psychologie.uzh.ch/neuropsy/ (website)
>> http://www.juergenhaenggi.ch (private website)
>>
>> This e-mail (and any attachment/s) contains confidential and/or
>>privileged
>> information. If you are not the intended recipient (or have received
>>this
>> e-mail in error) please notify the sender immediately and destroy this
>> e-mail. Any unauthorised copying, disclosure or distribution of the
>> material in this e-mail is strictly forbidden.
>> 
>>-
>>---
>>
>>
>>
>> ___
>> 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.
>



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

[Freesurfer] trac-all bvec (nifti & many subjects)

[Barbara Kreilkamp]

Dear Freesurfers,

I am trying to run trac-all with many subjects through a configuration file.
The first subject gets processed without error, but after that I keep
getting errors, that the dwi_orig_flip.mghdti.bvecs file cannot be found.

This is my command with the output (below configuration file and the log
file)

trac-all -prep -c dmrirc_bonn_running2only.txt -no-isrunning
INFO: SUBJECTS_DIR is
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients
INFO: Diffusion root is
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients
Actual FREESURFER_HOME /Applications/freesurfer
trac-preproc -c
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/scripts/dmrirc.local
-log
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/scripts/trac-all.log
-cmd
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/scripts/trac-all.cmd
-no-isrunning
#-
/Applications/freesurfer/bin/trac-preproc
#-
#@# Image corrections Tue 26 Aug 2014 10:34:54 BST
mri_convert
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/data.nii.gz
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/dmri/dwi_orig.nii.gz
mri_convert
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/data.nii.gz
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/dmri/dwi_orig.nii.gz
$Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $
reading from
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/data.nii.gz...
TR=1000.00, TE=0.00, TI=0.00, flip angle=0.00
i_ras = (-0.999333, -0.0350092, 0.0104045)
j_ras = (-0.0349891, 0.999385, 0.00210945)
k_ras = (0.010472, -0.001744, 0.44)
writing to
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/dmri/dwi_orig.nii.gz...
flip4fsl
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/dmri/dwi_orig.nii.gz
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/dmri/dwi_orig_flip.nii.gz
INFO: input image orientation is LAS
INFO: input image determinant is -5.02198
fslswapdim
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/dmri/dwi_orig.nii.gz
x y z
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/dmri/dwi_orig_flip.nii.gz
fslorient -forceradiological
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/dmri/dwi_orig_flip.nii.gz
mv -f
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/dmri/dwi_orig_flip.mghdti.bvecs
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/dmri/bvecs
mv: rename
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/dmri/dwi_orig_flip.mghdti.bvecs
to
/Users/NEURO-220/Desktop/Neuroimaging/KREILKAMP/Freesurfer_test_data_results/Bonn/all_controls_patients/4099/dmri/bvecs:
No such file or directory
Darwin NEURO-220.local 13.1.0 Darwin Kernel Version 13.1.0: Wed Apr  2
23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64


Thanks in advance for all your help!
All the best,
Barbara



My configuration file looks like this:
#
# This file contains commands that will be run by trac-all before an
analysis.
# It is used to set all parameters needed for the analysis.
#
# Remove a parameter from your dmrirc file if you want use the default
value.
# Parameters that don't have default values must be specified.
#
# Any other commands that you might want to run before an analysis can be
added
# to this file.
#
# Original Author: Anastasia Yendiki
# CVS Revision Info:
#$Author: ayendiki $
#$Date: 2013/02/16 22:49:06 $
#$Revision: 1.3.2.4 $
#
# Copyright © 2011 The General Hospital Corporation (Boston, MA) "MGH"
#
# Terms and conditions for use, reproduction, distribution and contribution
# are found in the 'FreeSurfer Software License Agreement' contained
# in the file 'LICENSE' found in the FreeSurfer distribution, and here:
#
# https://surfer.nmr.mgh.harvard.edu/fswiki/FreeSurferSoftwareLicense
#
# Reporting: freesurfer@nmr.mgh.harvard.edu
#
#

# FreeSurfer SUBJECTS_DIR
# T1 images and FreeSurfer segmentations are expected to be found here
#
setenv SUBJECTS_DIR
/User

Re: [Freesurfer] tracula: bvec-error

[Robby De Pauw]

Hi Anastasia,I’m using this version of tracula.trac-all,v 1.22.2.12 2013/02/23 02:01:02 ayendiki ExpI’ve attached the log-file you requested.
Robby De Pauw, dra.Ghent UniversityDepartment of Physiotherapy and Rehabilitation Sciences3B3De Pintelaan 185B-9000 Ghentrobby.dep...@ugent.be

trac-all.log
Description: Binary data


dmrirc.info
Description: Binary data
0 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 
1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 
1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 
1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 1200 
1200 


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