Re: [Freesurfer] T2 voxel size needed for recon_all

[Erik O'Hanlon]

Thanks Bruce,

Much appreciated.

Cheers

Erik

Erik O'Hanlon 

Postdoctoral researcher



RCSI Psychiatry
Royal College of Surgeons in Ireland
Beaumont Road, Beaumont, D9, Ireland
T: 8093740

E: erikohan...@rcsi.ie W: www.rcsi.ie

RCSI DEVELOPING HEALTHCARE LEADERS
WHO MAKE A DIFFERENCE WORLDWIDE  

 


From: freesurfer-boun...@nmr.mgh.harvard.edu [freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Bruce Fischl [fis...@nmr.mgh.harvard.edu]
Sent: 16 January 2017 15:41
To: Freesurfer support list
Subject: Re: [Freesurfer] T2 voxel size needed for recon_all

Hi Erik

it's all empirical, but I would think much over 1.5mm in and direction
would make it of limited value
Bruce


On Mon, 16 Jan 2017, Erik O'Hanlon wrote:

> Dear Freesurfer experts,
>
> I'm wondering if there is a minimum voxel size for the T2 iamge to be
> included in the recon_all. My T1 is .9mm isotropic but the T2 available is
> 0.5mmx0.5mmx3mm. Would this voxel size offer any benefit or would it be best
> just to run the recon_all with only the T1 image.
>
> Thanks in advance and apologies for this basic question.
>
> Kind regards
>
> Erik
>
>
___
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] ROI with precise coordinates

[Dr. M. Shahid]

Hi,

Yes you can use fslmaths and Ants ImageMath to make an ROI from the given
mni coordinates. The command is like
fslmaths MNI_T1...gz -mul 0 -add 1 roi xmin xsize ymin ysize zmin zsize
tmin tsize ROI_name.
For a box of 10mm , you can use fslmaths kernel boxv...
or for a sphere you can use  ImageMath MD input sphere-radius

Best regards,

--
Shahid.


On Mon, Jan 9, 2017 at 3:46 PM, Lisa Delalande 
wrote:

> Dear all,
>
>
> I would like to know how to make an ROI an FreeSurfer/QDEC with precise
> coordinates. More precisely, I want an ROI called IFC consisting of
> combined pars opercularis and pars triangularis and with a box of 10 x 10 x
> 10 mm size, centered at MNI coordinates 10, -15,- 5. Does a command line
> exists for that ? It is possible without drawing the label ?
>
>
>
> Thanks in advance for your help,
>
> Best regards.
>
> And I wish you a Happy New Year 2017 !
>
>
> Lisa
>
>
> ___
> 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] V6beta: recon-all --noasegfusion does not initialize using longbase aseg.mgz; how to handle aseg edits in longitudinal stream

[Martin Reuter]

Hi Antonin, 

the -noasegfusion is not really supported and a left over from initial testing 
when we first developed the stream. I will take a look at it and probably 
remove the flag (or implement it in a way that it really initializes with the 
aseg from the base, although I think this is not desirable, unless one really 
assumes there is no/ or very little change between time points. 

About aseg edits in longitudinal processing, please look at our edit wiki page:
https://surfer.nmr.mgh.harvard.edu/fswiki/LongitudinalEdits#aseg.mgz 
 

“
ASEG edits can be done in cross, base and long. 

Recommendation: Edit in long only if you want to correct the volume of 
important structures. Edit in base if surfaces need to be changed due to 
incorrect labeling of aseg. Not necessary to edit in cross. 

The segmentation in the long runs is initialized with a fused aseg (a weighted 
average of the cross sectional asegs). Thus any edits done to the cross 
sectionals are incorporated indirectly into the long stream. But since the 
fused aseg is used only for the initialization, it can happen that manual edits 
from the cross get removed again. Therefore, to correct the volume, just edit 
the long."

So for your ventricle correction, you could either clean up the cross data and 
hope it caries over to the long (it should), or directly edit the long aseg. 

Best, Martin


> On 16 Jan 2017, at 23:23, Antonin Skoch  wrote:
> 
> Dear experts,
> 
> I am testing the longitudinal stream with V6beta version. 
> 
> The recon-all -help says for -noasegfusion:
> 
> Do not create 'fused' aseg from the longbase timepoints, which would normally
> be used to initialize the ca_labeling.  Instead, initialize using the longbase
> aseg.mgz.
> 
> As I looked to recon-all code it seems that in case of -noasegfusion there is 
> no use of -r and -ri parameters and therefore no "initialization".  Could you 
> please comment on?
> 
> My second query is regarding manual edits:
> 
> In one subject the manual editing of aseg was necessary due to ventricle 
> mislabeling. I edited the aseg.presurf in base template and subsequently run 
> longitudinal stream via
> 
> recon-all -long tpID templateID -noasegfusion -all
> 
> From the last sentence of -noasegfusion help I (wrongly) expected that my 
> aseg.presurf edits in base template would be incorporated for -long recon. 
> However, this was not the case, the edits have not been incorporated at all. 
> Looking at the recon-all code the aseg.presurf from base is never used for 
> -long.
> 
> I thought that I could incorporate manual edits from base by manual copying 
> of aseg.presurf from base to long directory. As I looked for the way how the 
> manual aseg edits are handled in recon-all, they are identified by using the 
> difference between the files aseg.auto and aseg.manedit which contains manual 
> edits. Therefore I think that the copying from base is not an option, I 
> expect that this would replace segmentations not only in manual edit regions, 
> but in all regions where the aseg.auto of base and aseg.auto of -long differs 
> (they do not have the same input) which is undesirable. So I think I do not 
> have any other option than to edit aseg.presurf in -long again.
> 
> Could you please comment on how to optimally handle such situations?
> 
> 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.

[Freesurfer] installation fail :(

[Shapiro, Allison L]

Dear FreeSurfer support,

I am a new user of the Freesurfer program and attempted to install everything 
this morning on my Mac OSx 10.11.6 (El Capitan). To preface everything, I 
updated my XQuartz program before installing, and I do not have Matlab on this 
computer and understand that I can’t use the fMRI functionality without this, 
but this is not my goal.

The installation appeared to go as planned, but when I went to test the 
installation with the commands:

$> 
$> freeview -v $SUBJECTS_DIR/bert/mri/brainmask.mgz -v 
$SUBJECTS_DIR/bert/mri/aseg.mgz:colormap=lut:opacity=0.2 -f 
$SUBJECTS_DIR/bert/surf/lh.white:edgecolor=yellow -f 
$SUBJECTS_DIR/bert/surf/rh.white:edgecolor=yellow -f 
$SUBJECTS_DIR/bert/surf/lh.pial:annot=aparc:edgecolor=red -f 
$SUBJECTS_DIR/bert/surf/rh.pial:annot=aparc:edgecolor=red

I received the following error:

-bash: $: command not found

I was not able to decipher this error with The Google, so I am hoping that you 
can help.

Thank you so much for your time!

Best Wishes,
Allie

Allison L B Shapiro, MPH, PhD
Postdoctoral Research Fellow
LEAD Center | Colorado School of Public Health
Office 303.724.7708

“Those who dare to fail miserably can achieve greatly” - JFK



___
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 volume from masked region

[Eli Johnson]

Hi all,


I am trying to extract the volume from a FreeSurfer segmented scan within a 
pre-registered mask region, but only within the cortex, and wanted to check my 
command.


The mask is a binary mask (value of 1 across the mask) and is in the same space 
as the orig.mgz file. It covers part of the frontal lobe.


I have run:

mri_segstats --seg ./scan500_std/mri/500_lobes_1-in-fs.mgz --id 1 --i 
./scan500_std/mri/aparc+aseg.mgz --accumulate --sum test.reg1.sum


This has output a text file with a value of 495563 mm3 in the last row.


I wanted to check whether this is the correct command to extract only cortical 
GM within this mask. If this is correct, should be adding other flags (e.g. 
-pv). I have searched the mailing list and the options for mri_segstats, but 
I'm not 100% confident in what I've done - so any tips would be greatly 
appreciated.


Many thanks
Eli
___
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] TRACULA in FreeSurfer 6.0 trac-paths error

[Yendiki, Anastasia]

Hi Derek - There's an inconsistency among the output volumes that are supposed 
to be in diffusion space; some have 2mm iso resolution and some have .9x.9x3mm. 
From the logs it looks like you reran some of the pre-processing steps 
separately. If you ran some before resampling and some after, this may be 
causing the mix-up. I would just start from scratch in a new subject directory 
and see if that fixes it.

Best,
a.y


From: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Derek A Pisner 
[dpis...@utexas.edu]
Sent: Sunday, January 15, 2017 3:01 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] TRACULA in FreeSurfer 6.0 trac-paths error

Uploaded:

https://gate.nmr.mgh.harvard.edu/filedrop2/index.php?p=6cwuw1zwaag

Also, I've included a dwi_TRfixed.nii.gz file with the TR in the header fixed. 
Curious to see if that one works!

mri_convert --in_type nii --out_type nii --out_orientation RAS dwi.nii.gz -tr 
1000 dwi_TRfixed.nii.gz

On Sun, Jan 15, 2017 at 1:44 PM, Yendiki, Anastasia 
mailto:ayend...@mgh.harvard.edu>> wrote:
Hi Derek - It looks like it fails, but I suspect that it may be something 
unrelated to the warning. Can you please upload a zip file with this subject's 
TRACULA directories (dmri, dmri.bedpostX, dlabel, dpath, scripts) for me here:

https://gate.nmr.mgh.harvard.edu/filedrop2/

Thanks!

a.y


From: 
freesurfer-boun...@nmr.mgh.harvard.edu
 
[freesurfer-boun...@nmr.mgh.harvard.edu]
 on behalf of Derek A Pisner [dpis...@utexas.edu]
Sent: Sunday, January 15, 2017 2:36 PM
To: Freesurfer support list

Subject: Re: [Freesurfer] TRACULA in FreeSurfer 6.0 trac-paths error


Hi Anastasia,



See attached log. Hard to tell, but it does seem that trac-all fails after this 
warning.



Thanks for taking a look!



Derek Pisner

Doctoral Student

CLA 4.600

Mood Disorders Laboratory (MDL)

Department of Psychology | The University of Texas at Austin



On Sun, Jan 15, 2017 at 1:27 PM, Yendiki, Anastasia 
mailto:ayend...@mgh.harvard.edu>> wrote:
Hi Derek - It sounds like the programs that you used to convert from dicom to 
nifti and to resample from anisotropic nifti to isotropic nifti don't copy the 
TE and TR info in the header correctly. This information is not needed to run 
-paths, however. Does trac-all stop running after this warning, or does it keep 
going? Can you attach your entire trac-all.log file? Thanks!

a.y


From: 
freesurfer-boun...@nmr.mgh.harvard.edu
 
[freesurfer-boun...@nmr.mgh.harvard.edu]
 on behalf of Derek A Pisner [dpis...@utexas.edu]
Sent: Sunday, January 15, 2017 11:47 AM
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] TRACULA in FreeSurfer 6.0 trac-paths error


Hi Anastasia,

Thanks for the quick response!

The TE and the TR are both listed as 0.00 with mri_info. Of note, these dwi 
images have been resampled from anisotropic to isotropic voxels using an 
in-house python script. I noticed that this error comes up only for the 
resampled, but not the original image. I am guessing this is the underlying 
source of the problem and has less to do with trac-all.  What does trac-all 
need from the header to successfully run -paths? How can the header be 
corrected in freesurfer so that it will run successfully? Strangely, the TE 
also comes up as being equal to 0 in the original, anisotropic, image... The TR 
is what appears to be different and perhaps that is the source of the niiRead() 
warning? See below.

Many Thanks,

Derek

vlogin03.ls5(69)$ mri_info dwi.nii.gz

niiRead(): NIFTI_UNITS_UNKNOWN, assuming mm

WARNING: niiRead(): unknown time units 0 in 
/work/04171/dpisner/data/ABM/TRACULA/tractography_output/s002/dmri/dwi.nii.gz

Volume information for dwi.nii.gz

  type: nii

dimensions: 115 x 115 x 56 x 55

   voxel sizes: 2.00, 2.00, 2.00

  type: FLOAT (3)

   fov: 230.000

   dof: 0

xstart: -115.0, xend: 115.0

ystart: -115.0, yend: 115.0

zstart: -56.0, zend: 56.0

TR: 0.00 msec, TE: 0.00 msec, TI: 0.00 msec, flip angle: 0.00 
degrees

   nframes: 55

   PhEncDir: UNKNOWN

   FieldStrength: 0.00

ras xform present

xform info: x_r =  -1., y_r =   0., z_r =   0., c_r =-0.4490

  : x_a =   0., y_a =   1., z_a =   0., c_a =40.5440

  : x_s =   0., y_s =   0., z_s =   1., c_s =55.0398

Orientation   : LAS

Primary Slice Direction: axial


voxel to ras transform:

   -2.   0.   0.   114.5510

0.   2.   0.   -74.

Re: [Freesurfer] TRACULA in FreeSurfer 6.0 trac-paths error

[Derek A Pisner]

Thanks Anastasia! You seemed to have caught the issue. the dtifit files
were mistakenly generated from the anisotropic preprocessed image. I will
ensure the same voxel dimensions among all inputs and re-run. Will let you
know if that doesn't fix it!

All the best,
Derek

On Tue, Jan 17, 2017 at 10:31 AM, Yendiki, Anastasia <
ayend...@mgh.harvard.edu> wrote:

> Hi Derek - There's an inconsistency among the output volumes that are
> supposed to be in diffusion space; some have 2mm iso resolution and some
> have .9x.9x3mm. From the logs it looks like you reran some of the
> pre-processing steps separately. If you ran some before resampling and some
> after, this may be causing the mix-up. I would just start from scratch in a
> new subject directory and see if that fixes it.
>
> Best,
> a.y
>
> --
> *From:* freesurfer-boun...@nmr.mgh.harvard.edu [
> freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Derek A Pisner [
> dpis...@utexas.edu]
> *Sent:* Sunday, January 15, 2017 3:01 PM
>
> *To:* Freesurfer support list
> *Subject:* Re: [Freesurfer] TRACULA in FreeSurfer 6.0 trac-paths error
>
> Uploaded:
>
> https://gate.nmr.mgh.harvard.edu/filedrop2/index.php?p=6cwuw1zwaag
>
> Also, I've included a dwi_TRfixed.nii.gz file with the TR in the header
> fixed. Curious to see if that one works!
>
> mri_convert --in_type nii --out_type nii --out_orientation RAS dwi.nii.gz
> -tr 1000 dwi_TRfixed.nii.gz
>
> On Sun, Jan 15, 2017 at 1:44 PM, Yendiki, Anastasia <
> ayend...@mgh.harvard.edu> wrote:
>
>> Hi Derek - It looks like it fails, but I suspect that it may be something
>> unrelated to the warning. Can you please upload a zip file with this
>> subject's TRACULA directories (dmri, dmri.bedpostX, dlabel, dpath, scripts)
>> for me here:
>>
>> https://gate.nmr.mgh.harvard.edu/filedrop2/
>>
>> Thanks!
>>
>> a.y
>>
>> --
>> *From:* freesurfer-boun...@nmr.mgh.harvard.edu [
>> freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Derek A Pisner [
>> dpis...@utexas.edu]
>> *Sent:* Sunday, January 15, 2017 2:36 PM
>> *To:* Freesurfer support list
>>
>> *Subject:* Re: [Freesurfer] TRACULA in FreeSurfer 6.0 trac-paths error
>>
>> Hi Anastasia,
>>
>>
>>
>> See attached log. Hard to tell, but it does seem that trac-all fails
>> after this warning.
>>
>>
>>
>> Thanks for taking a look!
>>
>>
>>
>> Derek Pisner
>>
>> Doctoral Student
>>
>> CLA 4.600
>>
>> Mood Disorders Laboratory (MDL)
>>
>> Department of Psychology | The University of Texas at Austin
>>
>>
>>
>> On Sun, Jan 15, 2017 at 1:27 PM, Yendiki, Anastasia <
>> ayend...@mgh.harvard.edu> wrote:
>>
>>> Hi Derek - It sounds like the programs that you used to convert from
>>> dicom to nifti and to resample from anisotropic nifti to isotropic nifti
>>> don't copy the TE and TR info in the header correctly. This information is
>>> not needed to run -paths, however. Does trac-all stop running after this
>>> warning, or does it keep going? Can you attach your entire trac-all.log
>>> file? Thanks!
>>>
>>> a.y
>>>
>>> --
>>> *From:* freesurfer-boun...@nmr.mgh.harvard.edu [
>>> freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Derek A Pisner [
>>> dpis...@utexas.edu]
>>> *Sent:* Sunday, January 15, 2017 11:47 AM
>>> *To:* freesurfer@nmr.mgh.harvard.edu
>>> *Subject:* Re: [Freesurfer] TRACULA in FreeSurfer 6.0 trac-paths error
>>>
>>> Hi Anastasia,
>>>
>>> Thanks for the quick response!
>>>
>>> The TE and the TR are both listed as 0.00 with mri_info. Of note, these
>>> dwi images have been resampled from anisotropic to isotropic voxels using
>>> an in-house python script. I noticed that this error comes up only for the
>>> resampled, but not the original image. I am guessing this is the underlying
>>> source of the problem and has less to do with trac-all.  What does trac-all
>>> need from the header to successfully run -paths? How can the header be
>>> corrected in freesurfer so that it will run successfully? Strangely, the TE
>>> also comes up as being equal to 0 in the original, anisotropic, image...
>>> The TR is what appears to be different and perhaps that is the source of
>>> the niiRead() warning? See below.
>>>
>>> Many Thanks,
>>>
>>> Derek
>>>
>>> *vlogin03.ls5(69)$ *mri_info dwi.nii.gz
>>>
>>> niiRead(): NIFTI_UNITS_UNKNOWN, assuming mm
>>>
>>> WARNING: niiRead(): unknown time units 0 in
>>> /work/04171/dpisner/data/ABM/TRACULA/tractography_output/s00
>>> 2/dmri/dwi.nii.gz
>>>
>>> Volume information for dwi.nii.gz
>>>
>>>   type: nii
>>>
>>> dimensions: 115 x 115 x 56 x 55
>>>
>>>voxel sizes: 2.00, 2.00, 2.00
>>>
>>>   type: FLOAT (3)
>>>
>>>fov: 230.000
>>>
>>>dof: 0
>>>
>>> xstart: -115.0, xend: 115.0
>>>
>>> ystart: -115.0, yend: 115.0
>>>
>>> zstart: -56.0, zend: 56.0
>>>
>>>   *  TR: 0.00 msec, TE: 0.00 msec,* TI: 0.00 msec, flip angle:
>>> 0.00 degrees
>>>
>>>nframes: 55
>>>
>>>P

[Freesurfer] PETSURFER Tutorial Problems

[Anderson Napolitano]

Good Afternoon Support Team,

Per step one of your PETSURFER tutorial, the command:  gtmseg --s ?, 
where the  is the name of the subject that we had ran recon-all, 
outputs the error as described in out.txt attached in this email. If you have 
the time, it would be much appreciated if you can help us resolve this issue. 
Thank you for your time.

Warmest Regards,
Anderson Napolitano?

Mon Jan  9 13:19:45 MST 2017

setenv SUBJECTS_DIR /usr/local/freesurfer/subjects
cd /usr/local/freesurfer
/usr/local/freesurfer/bin/gtmseg --s M87151031-2016002-BL

freesurfer-Darwin-OSX-stable-v6-beta-20161116-5037eae
$Id: FreeSurferEnv.csh,v 1.89 2016/06/09 14:54:31 zkaufman Exp $
Darwin ripl4.health.unm.edu 16.0.0 Darwin Kernel Version 16.0.0: Mon Aug 29 
17:56:20 PDT 2016; root:xnu-3789.1.32~3/RELEASE_X86_64 x86_64
xcerebralseg --s M87151031-2016002-BL
Mon Jan  9 13:19:45 MST 2017

setenv SUBJECTS_DIR /usr/local/freesurfer/subjects
cd /usr/local/freesurfer
/usr/local/freesurfer/bin/xcerebralseg --s M87151031-2016002-BL

freesurfer-Darwin-OSX-stable-v6-beta-20161116-5037eae
$Id: xcerebralseg,v 1.11 2016/03/04 23:05:31 greve Exp $
Darwin ripl4.health.unm.edu 16.0.0 Darwin Kernel Version 16.0.0: Mon Aug 29 
17:56:20 PDT 2016; root:xnu-3789.1.32~3/RELEASE_X86_64 x86_64
mri_ca_label -align -nobigventricles 
/usr/local/freesurfer/subjects/M87151031-2016002-BL/mri/nu.mgz 
/usr/local/freesurfer/subjects/M87151031-2016002-BL/mri/transforms/talairach.m3z
 /usr/local/freesurfer/average/aseg+spmhead+vermis+pons.ixi.gca 
/usr/local/freesurfer/subjects/M87151031-2016002-BL/tmp/tmpdir.xcerebralseg.41283/seg1.mgh
sysname  Darwin
hostname ripl4.health.unm.edu
machine  x86_64

setenv SUBJECTS_DIR /usr/local/freesurfer/subjects
cd /usr/local/freesurfer
mri_ca_label -align -nobigventricles 
/usr/local/freesurfer/subjects/M87151031-2016002-BL/mri/nu.mgz 
/usr/local/freesurfer/subjects/M87151031-2016002-BL/mri/transforms/talairach.m3z
 /usr/local/freesurfer/average/aseg+spmhead+vermis+pons.ixi.gca 
/usr/local/freesurfer/subjects/M87151031-2016002-BL/tmp/tmpdir.xcerebralseg.41283/seg1.mgh
 

dyld: lazy symbol binding failed: Symbol not found: ___emutls_get_address
  Referenced from: /usr/local/freesurfer/bin/../lib/gcc/lib/libgomp.1.dylib
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: ___emutls_get_address
  Referenced from: /usr/local/freesurfer/bin/../lib/gcc/lib/libgomp.1.dylib
  Expected in: /usr/lib/libSystem.B.dylib

Abort 
ERROR:
ERROR: xcerebralseg --s M87151031-2016002-BL
gtmseg exited with errors
___
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] question about cortical volume group analyses

[Ritobrato Datta]

Hi All,

I have a analysed data from AD patients and healthy controls and want to do a 
group analyses of cortical volume. 

I have run qcache on each subject. 

In the lh.volume.fsaverage.mris_preproc.log file,

mri_surf2surf --srcsubject AD1 --srchemi lh --srcsurfreg sphere.reg 
--trgsubject fsaverage --trghemi lh --trgsurfreg sphere.reg --tval 
./tmp.mris_preproc.76769/AD1.1.mgh --sval 
/Applications/freesurfer5.1/subjects/AD1/surf/lh.volume --jac --sfmt curv 
--noreshape --no-cortex

what does -jac jacobian correction mean ? Is it accounting/correcting for 
differences in hemispheric volume ?

I want to do a group analyses between AD and controls for cortical volume, can 
I just use the lh.volume.fwhm??.fsaverage.mgh at different smoothing kernels ? 
Do I need to correct for whole brain volume or some scaling or is it already 
taken care of ?

Are there references that have used free surfer to report group analyses for 
cortical volume ? Can someone point to a few ?

Thanks

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


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

Re: [Freesurfer] V6beta: recon-all --noasegfusion does not initialize using longbase aseg.mgz; how to handle aseg edits in longitudinal stream

[Antonin Skoch]

Dear Martin,

thank you for the feedback. I read the wiki but the instructions concerning 
aseg edits were not much clear for me. And, I was misinformed by -noasegfusion 
option.

The pity with aseg errors is that with the current design and when the error is 
large to affect surfaces in base, it is necessary to edit the same error twice. 
Since the aseg of base is not initialized from cross, and long is not 
initialized from base, then one has to edit the same error both in base and in 
long (or cross). 

If there is a systematic error which affects all timepoints (as it is in my 
case - I have 2 points), I effectively have to edit the same error 3 times. It 
is quite large error affecting whole posterior part of lateral ventricle (see 
screenshot).

Therefore, I thought that best option would be to edit the base and initialize 
long from base using -noasegfusion. I tried to do that by manually copying aseg 
from base and manually running mri_ca_label with -r and -ri option (and and the 
error is (almost) cleaned in long.

Why do you think that the initialization from base is worse/undesirable than 
initialization from fused aseg from cross? It seems to me that to initialize 
from fused (averaged) asegs of cross or initialize from aseg of base (which is 
averaged template of cross) is methodologically quite similar, should produce 
similar results and in terms of edits it is much more convenient way.

Regards,

Antonin

Hi Antonin, 

the -noasegfusion is not really supported and a left over from initial testing 
when we first developed the stream. I will take a look at it and probably 
remove the flag (or implement it in a way that it really initializes with the 
aseg from the base, although I think this is not desirable, unless one really 
assumes there is no/ or very little change between time points. About aseg 
edits in longitudinal processing, please look at our edit wiki page:
https://surfer.nmr.mgh.harvard.edu/fswiki/LongitudinalEdits#aseg.mgz 
 

“
ASEG edits can be done in cross, base and long. 

Recommendation: Edit in long only if you want to correct the volume of 
important structures. Edit in base if surfaces need to be changed due to 
incorrect labeling of aseg. Not necessary to edit in cross. 

The segmentation in the long runs is initialized with a fused aseg (a weighted 
average of the cross sectional asegs). Thus any edits done to the cross 
sectionals are incorporated indirectly into the long stream. But since the 
fused aseg is used only for the initialization, it can happen that manual edits 
from the cross get removed again. Therefore, to correct the volume, just edit 
the long."

So for your ventricle correction, you could either clean up the cross data and 
hope it caries over to the long (it should), or directly edit the long aseg. 

Best, Martin


> On 16 Jan 2017, at 23:23, Antonin Skoch  wrote:
> 
> Dear experts,
> 
> I am testing the longitudinal stream with V6beta version. 
> 
> The recon-all -help says for -noasegfusion:
> 
> Do not create 'fused' aseg from the longbase timepoints, which would normally
> be used to initialize the ca_labeling.  Instead, initialize using the longbase
> aseg.mgz.
> 
> As I looked to recon-all code it seems that in case of -noasegfusion there is 
> no use of -r and -ri parameters and therefore no "initialization".  Could you 
> please comment on?
> 
> My second query is regarding manual edits:
> 
> In one subject the manual editing of aseg was necessary due to ventricle 
> mislabeling. I edited the aseg.presurf in base template and subsequently run 
> longitudinal stream via
> 
> recon-all -long tpID templateID -noasegfusion -all
> 
> From the last sentence of -noasegfusion help I (wrongly) expected that my 
> aseg.presurf edits in base template would be incorporated for -long recon. 
> However, this was not the case, the edits have not been incorporated at all. 
> Looking at the recon-all code the aseg.presurf from base is never used for 
> -long.
> 
> I thought that I could incorporate manual edits from base by manual copying 
> of aseg.presurf from base to long directory. As I looked for the way how the 
> manual aseg edits are handled in recon-all, they are identified by using the 
> difference between the files aseg.auto and aseg.manedit which contains manual 
> edits. Therefore I think that the copying from base is not an option, I 
> expect that this would replace segmentations not only in manual edit regions, 
> but in all regions where the aseg.auto of base and aseg.auto of -long differs 
> (they do not have the same input) which is undesirable. So I think I do not 
> have any other option than to edit aseg.presurf in -long again.
> 
> Could you please comment on how to optimally handle such situations?
> 
> Regards,
> 
> Antonin Skoch
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.ha

[Freesurfer] FS Anatomic ROIs Atlas

[Da, Xiao]

Dear Freesurfer Community,

I am wondering if you have these anatomic ROIs 
(https://surfer.nmr.mgh.harvard.edu/fswiki/CorticalParcellation) already done 
for the 3D volumetric standard MNI brain (either ch2 single subject 
brain(preferred) or 152 average brain)

Greatly appreciated it.

Thanks and best regards,

Xiao Da
Biomedical Engineer - Programmer Analyst II
Functional Neuroimaging Laboratory
Brigham and Women's Hospital
221 Longwood Avenue, Braunwald Building, Room LM116
Boston, MA 02115
x...@bwh.harvard.edu






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


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

[Freesurfer] Anatomical ROI parcellation

[Aya Kabbara]

Dear Freesurfer team,


I am wondering is there a way using tksurfer to edit a given atlas (for 
example: destrieux atlas).

I would like to parcellate the superior temporal region into three regions .


Is there a way to do that?


Thank you

Aya
___
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] Anatomical ROI parcellation

[Anthony Dick]

https://surfer.nmr.mgh.harvard.edu/fswiki/tksurfer_labeledit


On 1/17/17 4:47 PM, Aya Kabbara wrote:


Dear Freesurfer team,


I am wondering is there a way using tksurfer to edit a given atlas 
(for example: destrieux atlas).


I would like to parcellate the superior temporal region into three 
regions .



Is there a way to do that?


Thank you

Aya



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


--
Anthony Steven Dick, Ph.D.
Associate Professor
Director, Cognitive Neuroscience Program and Graduate Certificate in Cognitive 
Neuroscience
Department of Psychology
Florida International University Modesto A. Maidique Campus AHC4 454
11200 S.W. 8th Street
Miami, FL 33199
Ph: 305-348-4202; Lab Ph: 305-348-9055; Fx: 305-348-3879
Email: ad...@fiu.edu
Webpage: http://myweb.fiu.edu/adick
Join the Society for the Study of Human Development: http://www.sshdonline.org

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


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

Re: [Freesurfer] FS Anatomic ROIs Atlas

[Douglas N Greve]

Try running recon-all on the mni152 brain


On 01/17/2017 04:35 PM, Da, Xiao wrote:
>
> Dear Freesurfer Community,
>
> I am wondering if you have these anatomic ROIs 
> (https://surfer.nmr.mgh.harvard.edu/fswiki/CorticalParcellation) 
> already done for the 3D volumetric standard MNI brain (either ch2 
> single subject brain(preferred) or 152 average brain)
>
> Greatly appreciated it.
>
> Thanks and best regards,
>
> *Xiao Da*
>
> Biomedical Engineer - Programmer Analyst II
>
> Functional Neuroimaging Laboratory
>
> Brigham and Women’s Hospital
>
> 221 Longwood Avenue, Braunwald Building, Room LM116
>
> Boston, MA 02115
>
> /x...@bwh.harvard.edu /
>
> //
>
> //
>
> //
>
>
>
> ___
> 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] V6beta: recon-all --noasegfusion does not initialize using longbase aseg.mgz; how to handle aseg edits in longitudinal stream

[Antonin Skoch]

Dear Martin,

one more thing: When the error is large and present in both timepoints (as is 
my case), I think that necessity of editing the same error in both timepoints 
can easily lead to error (maybe even demonstrated as false positive effect) 
caused by non-systematic editing. When editing comprises many voxels one cannot 
realistically assure the perfect consistence in editing.

Editing only once (in base) and initialize mri_ca_label in long from base can 
avoid this problem. So I think the initialization of mri_ca_label from base is 
not a bad option for such cases.

What do you think?

Antonin

Hi Antonin, 

the -noasegfusion is not really supported and a left over from initial testing 
when we first developed the stream. I will take a look at it and probably 
remove the flag (or implement it in a way that it really initializes with the 
aseg from the base, although I think this is not desirable, unless one really 
assumes there is no/ or very little change between time points. About aseg 
edits in longitudinal processing, please look at our edit wiki page:
https://surfer.nmr.mgh.harvard.edu/fswiki/LongitudinalEdits#aseg.mgz 
 

“
ASEG edits can be done in cross, base and long. 

Recommendation: Edit in long only if you want to correct the volume of 
important structures. Edit in base if surfaces need to be changed due to 
incorrect labeling of aseg. Not necessary to edit in cross. 

The segmentation in the long runs is initialized with a fused aseg (a weighted 
average of the cross sectional asegs). Thus any edits done to the cross 
sectionals are incorporated indirectly into the long stream. But since the 
fused aseg is used only for the initialization, it can happen that manual edits 
from the cross get removed again. Therefore, to correct the volume, just edit 
the long."

So for your ventricle correction, you could either clean up the cross data and 
hope it caries over to the long (it should), or directly edit the long aseg. 

Best, Martin


> On 16 Jan 2017, at 23:23, Antonin Skoch  wrote:
> 
> Dear experts,
> 
> I am testing the longitudinal stream with V6beta version. 
> 
> The recon-all -help says for -noasegfusion:
> 
> Do not create 'fused' aseg from the longbase timepoints, which would normally
> be used to initialize the ca_labeling.  Instead, initialize using the longbase
> aseg.mgz.
> 
> As I looked to recon-all code it seems that in case of -noasegfusion there is 
> no use of -r and -ri parameters and therefore no "initialization".  Could you 
> please comment on?
> 
> My second query is regarding manual edits:
> 
> In one subject the manual editing of aseg was necessary due to ventricle 
> mislabeling. I edited the aseg.presurf in base template and subsequently run 
> longitudinal stream via
> 
> recon-all -long tpID templateID -noasegfusion -all
> 
> From the last sentence of -noasegfusion help I (wrongly) expected that my 
> aseg.presurf edits in base template would be incorporated for -long recon. 
> However, this was not the case, the edits have not been incorporated at all. 
> Looking at the recon-all code the aseg.presurf from base is never used for 
> -long.
> 
> I thought that I could incorporate manual edits from base by manual copying 
> of aseg.presurf from base to long directory. As I looked for the way how the 
> manual aseg edits are handled in recon-all, they are identified by using the 
> difference between the files aseg.auto and aseg.manedit which contains manual 
> edits. Therefore I think that the copying from base is not an option, I 
> expect that this would replace segmentations not only in manual edit regions, 
> but in all regions where the aseg.auto of base and aseg.auto of -long differs 
> (they do not have the same input) which is undesirable. So I think I do not 
> have any other option than to edit aseg.presurf in -long again.
> 
> Could you please comment on how to optimally handle such situations?
> 
> 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.

[Freesurfer] WM lobes and Corpus Callosum

[Bharadwaj, Pradyumna - (prad)]

Hi,


I've been trying to create WM lobes using the following steps:


1) mri_annotation2label --lobesStrict

2) Outputting the labels from step 1, & creating a simpler annotation without 
limbic and insular lobes

3) Labeling the WM using mri_aparc2aseg (mri_aparc2aseg --s MySub --annot 
Step2AnnotationFile --labelwm --hypo-as-wm --wmpar-dmax 20 --rip-unknown


However, as the corpus callosum is not labelled as wm, it is not included in 
any WM lobe.


Is there any workaround to assigning the corpus callosum to the different WM 
lobes or do I have to manually edit aseg.mgz to change the corpus callosum's 
value to match that of WM ?



Thanks,

-Prad

___
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] WM lobes and Corpus Callosum

[Yendiki, Anastasia]

Hi Prad - mri_aparc2aseg assigns WM voxels to the nearest cortical region from 
the cortical parcellation. Which cortical region would you want to assign the 
corpus callosum to? What's labeled as corpus callosum in the aseg is the part 
of the corpus callosum between the 2 hemis.

Best,
a.y


From: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Bharadwaj, Pradyumna - 
(prad) [p...@email.arizona.edu]
Sent: Tuesday, January 17, 2017 5:37 PM
To: freesurfer@nmr.mgh.harvard.edu
Subject: [Freesurfer] WM lobes and Corpus Callosum


Hi,


I've been trying to create WM lobes using the following steps:


1) mri_annotation2label --lobesStrict

2) Outputting the labels from step 1, & creating a simpler annotation without 
limbic and insular lobes

3) Labeling the WM using mri_aparc2aseg (mri_aparc2aseg --s MySub --annot 
Step2AnnotationFile --labelwm --hypo-as-wm --wmpar-dmax 20 --rip-unknown


However, as the corpus callosum is not labelled as wm, it is not included in 
any WM lobe.


Is there any workaround to assigning the corpus callosum to the different WM 
lobes or do I have to manually edit aseg.mgz to change the corpus callosum's 
value to match that of WM ?



Thanks,

-Prad

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


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

Re: [Freesurfer] mri_vol2surf

[Zhivago]

Hi,

>From whatever I read, there seem to be 2 ways for overlaying activation
maps on surfaces.

1) automatic/manual registration of activation volume to orig.mgz and usage
of mri_vol2surf to create the overlay, say ?h.sig.mgh, which can then be
overlaid on an inflated surface in freeview or tksurfer using the
register.dat.

2) automatic/manual registration of activation volume to orig.mgz and
overlay the activation volume on the inflated surface in tksurfer using the
register.dat

I want to know if both these are valid methods and if so, what are the pros
and cons of each.  Seems like mri_vol2surf lets us decide what part of the
volume should be projected on the surface using the projfac arguments.  But
the direct volume overlay in tksurfer doesn't provide that option.  In that
case what part of the volume is projected on to the surface?

Thanks,
Zhivago...

On Sun, Jan 15, 2017 at 10:12 PM, Zhivago  wrote:

> Thanks Bruce!  Appreciate all the help,
>
> On Sun, Jan 15, 2017 at 10:02 PM, Bruce Fischl  > wrote:
>
>> 1) This is up to you. Jon Polimeni had a nice paper describing the
>> trade-off between accurately representing the local neural response (which
>> is best at the white border) and statistical power (which is best nearer
>> the pial surface).
>>
>> 2) This is also up to you.Read the help in mri_vol2surf. e.g.:
>>
>> mri_vol2surf --help
>> .
>> .
>> .
>>--projfrac-avg min max del : average along normal
>>
>> 3) it is the way that we support.
>>
>>
>> cheers
>> Bruce
>>
>>
>> On Sun, 15 Jan 2017, Zhivago wrote:
>>
>> Hey Bruce,
>>>
>>> Thank you very much for the responses!  Had posted a couple of more
>>> questions, but looks like it hasn't gone across.  Will really appreciate
>>> it
>>> if you can provide some answers to these.
>>>
>>> 1) The mri_vol2surf is used to project the activations from the GM onto
>>> an
>>> inflated surface, which is usually the inflated smoothwm surface output
>>> from
>>> reconall.  Will it be more accurate to use the inflated version of the
>>> intermediate surface, like halfway between the white and pial matter?
>>> Will
>>> it make any kind of sense?
>>>
>>> 2) When mri_vol2surf projects a volume to a surface, does it average the
>>> activation values of voxels along the cortical depth or sum it?  What
>>> really
>>> happens beneath?  Any amount of insight will be helpful.
>>>
>>> 3) Is mri_vol2surf the only way to view activation maps on inflated
>>> surfaces
>>> or any surface?
>>>
>>> Cheers,
>>> Zhivago...
>>>
>>> On Sun, Jan 15, 2017 at 9:23 PM, Bruce Fischl <
>>> fis...@nmr.mgh.harvard.edu>
>>> wrote:
>>>   Hi Zhivago
>>>
>>>   1) You can project from inside the ?h.white surface if
>>>   projfrac<0 and outside pial if projfrac>1. <<0 and >>1 won't
>>>   make much sense though as it starts to get arbitrary.
>>>
>>>   2) The default projfrac, as documented in the -help response, is
>>>   0.
>>>
>>>   3) Yes, 0-->white matter boundary. 1--> pial boundary.
>>>
>>>   4) The .mgh/.mgz file create by vol2surf is an nvertices x 1 x 1
>>>   vector, which is a scalar field over the surface.
>>>
>>>   cheers
>>>   Bruce
>>>
>>>
>>>
>>>   On Sun, 15 Jan 2017, Zhivago wrote:
>>>
>>> Hi,
>>>
>>>
>>> I do not have a good understanding of the
>>> mri_vol2surf command.
>>>
>>> 1) Can this only project the part of the volume that
>>> lies between the white
>>> & pial matter?
>>> 2) What is the default projection parameter that it
>>> uses?
>>> 3) Does projection always start from the white
>>> matter, i.e. is 0 the white
>>> matter surface?
>>> 4) What is the nature of the mgh file that is
>>> created by:
>>> mri_vol2surf --src mri/spmT_0002.img --regheader
>>> s04  --interp nearest
>>> --hemi lh --o lh.sig.mgh
>>>
>>> Thanks,
>>> Zhivago...
>>>
>>>
>>> ___
>>> 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

[Freesurfer] 'nuisance factors adjusted' values

[hiroki.sato]

Dear experts,

I have some questions.
I did Qdec group analysis with three nuisance factors. And one region
remained after FDR correction.
Then I did 'mri_surfcluster' specifying the FDR-determined voxel-wise
threshold as the --thmin.
After that I ran 'mri_segstats' and got the values.

1)Are these values 'nuisance factors adjusted' values?

2)If not, is there a way to get 'nuisance factors adjusted' values using
FreeSurfer?

Best Regards,
Hiroki

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