Re: [Freesurfer] Building from source #2 -- dynamic binding

2016-02-21 Thread Yaroslav Halchenko
On Sun, 21 Feb 2016, R Edgar wrote: > On 21 February 2016 at 22:33, wrote: > > Intolerable differences have not been found. They are always minor <%5 and > > their source can come from several places. For example, different > > compilers (or even different

Re: [Freesurfer] Building from source #2 -- dynamic binding

2016-02-21 Thread Yaroslav Halchenko
On Sun, 21 Feb 2016, zkauf...@nmr.mgh.harvard.edu wrote: > This topic gets brought up occasionally and their are valid arguments > to both sides. One reason we have hesitated to use dynamic libs is the > partly due to freesurfers long release cycle (all subjects that are > part of a study need

Re: [Freesurfer] Building from source #2 -- dynamic binding

2016-02-21 Thread R Edgar
On 21 February 2016 at 22:33, wrote: > Intolerable differences have not been found. They are always minor <%5 and > their source can come from several places. For example, different > compilers (or even different versions of the same compiler) can have > different

Re: [Freesurfer] Building from source -- [wishlist] please version the -packages.tar.gz

2016-02-21 Thread zkaufman
Yes this is a good idea. All subsequent 3rd party bundles will be versioned as (or similar to) the way you describe below. Which is good because a new one will be released soon. Thanks for the input. -Zeke > ATM >

Re: [Freesurfer] Building from source #2 -- dynamic binding

2016-02-21 Thread zkaufman
Intolerable differences have not been found. They are always minor <%5 and their source can come from several places. For example, different compilers (or even different versions of the same compiler) can have different sorting behavior when presented with objects that have equivalent comparators.

Re: [Freesurfer] Building from source #2 -- dynamic binding

2016-02-21 Thread zkaufman
This topic gets brought up occasionally and their are valid arguments to both sides. One reason we have hesitated to use dynamic libs is the partly due to freesurfers long release cycle (all subjects that are part of a study need to be performed all on the same version). This long release cycle

[Freesurfer] Ris: eTIV question

2016-02-21 Thread angela.fav...@unipd.it
<<< text/html; charset=utf-8: Unrecognized >>> ___ 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

Re: [Freesurfer] eTIV question

2016-02-21 Thread Bruce Fischl
yes, it's a somewhat different and more conservative test. I guess you could check the talairach transforms of some of your subjects with eTIVs that don't make sense (or change the most over time) to try to see why this is happening. Or take Mike's suggestion and test a different (but probably

Re: [Freesurfer] eTIV question

2016-02-21 Thread Angela Favaro
Hi, thank you I think this would test something different: 'how much a brain area is atrophic controlling for the average brain atrophy' and not 'how much a brain area is atrophic controlling for the individual differences in head size'. Doesn't it? Angela "Harms, Michael" ha

[Freesurfer] Building from source -- [wishlist] please version the -packages.tar.gz

2016-02-21 Thread Yaroslav Halchenko
ATM ftp://surfer.nmr.mgh.harvard.edu/pub/dist/fs_supportlibs/prebuilt/centos6_x86_64/centos6-x86_64-packages.tar.gz has no versioned counterpart. Could you please provide some versioning e.g. by actually having centos6-x86_64-packages-0.0.20151104.tar.gz (based on its modification date, 0.0. to

Re: [Freesurfer] eTIV question

2016-02-21 Thread Angela Favaro
there is a mistake in the graph, hippocampal volume is TIV2 I apologize for that! Angela Favaro ha scritto: > Hi Bruce, > please find attached the graph of the correlation between the two time > point. I did not find outliers or failures. However the discrepancy >

[Freesurfer] R: Re: R: Re: FS-FAST using MRS voxel or .label as seed

2016-02-21 Thread stdp82
I have checked MRS_MASK.mg and all its voxels have a value=1. All voxels contains in the mask are well overlapped on f.nii. The registration is accurate: the MRS mask is located on the vmPFC and its is equally distributed on left and right hemisphere. The orig.nii.gz and f.nii.gz is well