[Freesurfer] beta testing FreeSurfer v7 beta: recon-all-status.log, samseg

[Antonin Skoch]

External Email - Use Caution

Dear experts,


I began to test beta v7 version of FreeSurfer.


I noticed that some entries in recon-all-status.log seem missing (i.e. white 
and pial surface placement - there is entry Cortical Parc while following entry 
is Refine Pial Surfs).


Running 

samseg` --t1w $s/mri/T1.mgz --t2w $s/mri/T2.mgz --s $s --refmode t1w
exits with error in samseg2recon since command



set segvol = `find "$samsegdir" -iname "*crispSegmentation.nii" -print`


results with empty string set to segvol variable.


Antonin

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

Re: [Freesurfer] DWI EPI correction

[Antonin Skoch]

External Email - Use Caution


Hi, 



according to help, bbregister is rigid:



bbregister --help                Help

NAME
    bbregister

SYNOPSIS
    bbregister --s  --mov  --reg  \
        --

DESCRIPTION
    This program performs within-subject, cross-modal registration using a
    boundary-based cost function. The registration is constrained to be 6 
    DOF (rigid). It is required that you have an anatomical scan of the 
    subject that has been analyzed in freesurfer.





And, the distortions due to magnetic fields inhomogeneities are IMHO typically 
nonlinear, so even using affine registration would not suffice to precisely 
compensate for the distortion.



Antonin




 Od:   "Yendiki, Anastasia"  
 Komu:   "freesurfer@nmr.mgh.harvard.edu" , 
Antonin Skoch  
 Odesláno:   7.2.2020 23:44 
 Předmět:   Re: [Freesurfer] DWI EPI correction 


 
 Bbregister is affine, not rigid. Affine registration can account for the 
geometric distortion of EPIs along the phase encode direction (stretching or 
compression, depending on the polarity), if the target of the registration is 
an image that does not have that  distortion, such as an MPRAGE.
 
 

 
From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Antonin Skoch 

 Sent: Friday, February 7, 2020 5:38 PM
 To: freesurfer@nmr.mgh.harvard.edu 
 Subject: Re: [Freesurfer] DWI EPI correction 
  
 
External Email - Use Caution 
 Hi, Adam,

while reading this thread, I would like to clarify:

bbregister does rigid body registration, so you could use this tool for 
registering EPI to structurals, indeed.
But this tool only registers, it does not unwarp the distortions in the EPI 
images, it leaves images distorted.

For preprocessing of DWI data, I would recommend the "dwipreproc" wrapper 
script for FSL tools topup and eddy. This is part of mrtrix3 tool:

https://mrtrix.readthedocs.io/en/latest/reference/scripts/dwipreproc.html

Antonin Skoch



I guess there's a 3rd option: you can correct EPI geometric distortions by 
registering the EPI to a structural scan of the same subject. You can do that 
in FS with bbregister, which uses the surfaces from recon-all to align any scan 
to the T1 of the same subject.

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Adam Rytina 

Sent: Thursday, February 6, 2020 3:37 PM
To: Freesurfer support list 
Subject: Re: [Freesurfer] DWI EPI correction External Email - Use 
Caution

Yes, I know this option exists in FSL. I was just wondering whether there are 
some possibilities to perform diffusion data correction in Freesurfer, too.



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10




From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Yendiki, Anastasia 

Sent: Thursday, February 6, 2020 9:35:16 PM
To: Freesurfer support list 
Subject: Re: [Freesurfer] DWI EPI correction

In that case, you'll want to use the topup tool in FSL.

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Adam Rytina 

Sent: Thursday, February 6, 2020 3:32 PM
To: Freesurfer support list 
Subject: Re: [Freesurfer] DWI EPI correction


External Email - Use Caution

I´m sorry I didn´t specify my data. I didn´t acquire a field map. I have two b0 
volumes with both polarities for a phase gradient. Is it possible to estimate a 
field map from two b0 volumes in Freesurfer? And afterwards apply the fieldmap 
on other b values volumes to correct susceptibility artefacts?



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10




From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Yendiki, Anastasia 

Sent: Thursday, February 6, 2020 9:27:51 PM
To: freesurfer@nmr.mgh.harvard.edu 
Subject: Re: [Freesurfer] DWI EPI correction

The answer depends on how you want to correct susceptibility artifacts. Do you 
have a field map, or do you have DWIs acquired with reverse polarities?

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Adam Rytina 

Sent: Thursday, February 6, 2020 2:02 PM
To: freesurfer@nmr.mgh.harvard.edu 
Subject: [Freesurfer] DWI EPI correction


External Email - Use Caution

Hello all,

I have an input DWI dataset and wanna perform the diffusion data correction (mg 
susceptibility induced distortion correction, geometric correction...). Does 
Freesurfer enable to perform the diffusion correction? Does recon-all include 
this option?

Thanks a lot
Regards
Adam
 ___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] DWI EPI correction

[Antonin Skoch]

External Email - Use Caution

Hi, Adam,

while reading this thread, I would like to clarify:

bbregister does rigid body registration, so you could use this tool for 
registering EPI to structurals, indeed.
But this tool only registers, it does not unwarp the distortions in the EPI 
images, it leaves images distorted.

For preprocessing of DWI data, I would recommend the "dwipreproc" wrapper 
script for FSL tools topup and eddy. This is part of mrtrix3 tool:

https://mrtrix.readthedocs.io/en/latest/reference/scripts/dwipreproc.html

Antonin Skoch



I guess there's a 3rd option: you can correct EPI geometric distortions by 
registering the EPI to a structural scan of the same subject. You can do that 
in FS with bbregister, which uses the surfaces from recon-all to align any scan 
to the T1 of the same subject.

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Adam Rytina 

Sent: Thursday, February 6, 2020 3:37 PM
To: Freesurfer support list 
Subject: Re: [Freesurfer] DWI EPI correctionExternal Email - Use Caution

Yes, I know this option exists in FSL. I was just wondering whether there are 
some possibilities to perform diffusion data correction in Freesurfer, too.



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10




From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Yendiki, Anastasia 

Sent: Thursday, February 6, 2020 9:35:16 PM
To: Freesurfer support list 
Subject: Re: [Freesurfer] DWI EPI correction

In that case, you'll want to use the topup tool in FSL.

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Adam Rytina 

Sent: Thursday, February 6, 2020 3:32 PM
To: Freesurfer support list 
Subject: Re: [Freesurfer] DWI EPI correction


External Email - Use Caution

I´m sorry I didn´t specify my data. I didn´t acquire a field map. I have two b0 
volumes with both polarities for a phase gradient. Is it possible to estimate a 
field map from two b0 volumes in Freesurfer? And afterwards apply the fieldmap 
on other b values volumes to correct susceptibility artefacts?



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10




From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Yendiki, Anastasia 

Sent: Thursday, February 6, 2020 9:27:51 PM
To: freesurfer@nmr.mgh.harvard.edu 
Subject: Re: [Freesurfer] DWI EPI correction

The answer depends on how you want to correct susceptibility artifacts. Do you 
have a field map, or do you have DWIs acquired with reverse polarities?

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Adam Rytina 

Sent: Thursday, February 6, 2020 2:02 PM
To: freesurfer@nmr.mgh.harvard.edu 
Subject: [Freesurfer] DWI EPI correction


External Email - Use Caution

Hello all,

I have an input DWI dataset and wanna perform the diffusion data correction (mg 
susceptibility induced distortion correction, geometric correction...). Does 
Freesurfer enable to perform the diffusion correction? Does recon-all include 
this option?

Thanks a lot
Regards
Adam
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Change the subject ID after recon-all?

[Antonin Skoch]

External Email - Use Caution

Hi, Tim,

the subject ID can be also contained in the commandline history which is stored 
in .mgz files. This can be viewed using
mri_info file.mgz --cmds

I am not aware of any direct command which can strip out this info, but you 
surely could convert .mgz file to .nii and then (using path which does not 
contain subject ID) convert back to .mgz, if needed.

Antonin



Hi Doug,thanks for the mri_add_xform_to_header idea, I didn't know about that 
option!

Best,

Tim

> On January 21, 2020 at 4:24 PM "Greve, Douglas N.,Ph.D." 
>  wrote:
> 
> 
> 
> For the mgz volumes, you should be able to do something like
> mri_add_xform_to_header -c /new/path/to/xfm brain.mgz
> 
> For the labels you could just use something like
> sed s/oldsubjectname/newsubjectname
> 
> 
> 
> 
> On 1/17/2020 3:48 AM, Tim Schäfer wrote:
> >  External Email - Use Caution
> >
> > Hi Douglas,
> >
> > sure, you can get two example files here:
> >
> >  wget http://rcmd.org/tmp/brain.mgz
> >  wget http://rcmd.org/tmp/lh.BA1_exvivo.label
> >
> > The brain volume contains the ID because it stores the full path to the 
> > tairach xfm (which includes the folder name, so the ID). You can check by:
> >
> >  mri_info brain.mgz | grep talair
> >
> > (In this case the ID is 'tim').
> >
> > Without mri_info, you can get it as well:
> >
> >  mv brain.mgz brain.gz
> >  gunzip -c brain.gz | strings | grep talair
> >
> > The second file is an ASCII label from the same subject. You can get the ID 
> > by running:
> >
> >  head -n 1 lh.BA1_exvivo.label
> >
> > There are some other files which contain the ID, these are just 2 examples.
> >
> >
> > I am currently in contact with the people running the consortium server and 
> > I am not really sure whether the rule that the ID must not be in the files 
> > makes any sense at all. Maybe I can get around this.
> >
> >
> > Best,
> >
> > Tim
> >
> >
> >
> >
> >> On January 17, 2020 at 12:23 AM "Greve, Douglas N.,Ph.D." 
> >>  wrote:
> >>
> >>
> >> Hi Tim, can you send a list of files that have the identifier. For
> >> volumes and surfaces, it might be as easy as running
> >> mri_convert/mris_convert using the same file as input and output.
> >>
> >> On 1/13/2020 5:54 AM, Tim Schäfer wrote:
> >>>   External Email - Use Caution
> >>>
> >>> Dear FreeSurfer experts,
> >>>
> >>>
> >>> I have two questions on subject IDs in FreeSurfer output.
> >>>
> >>> 1) is it possible to change to subject identifier in the FreeSurfer 
> >>> output after recon-all has been run?
> >>>
> >>> Background: I would like to upload data pre-processed with FreeSurfer to 
> >>> a consortium server. The subject ID is a random identifier, but the 
> >>> upload guidelines say this identifier must only occur in certain file 
> >>> types (Excel files, .log files, and some more, but not in any other 
> >>> files).
> >>>
> >>> I noticed that a lot of the output files produced by FreeSurfer contain 
> >>> the subject identifier somewhere, including various binary files, so I 
> >>> guess there is no easy way to change it. But maybe there is? Like 
> >>> rerunning a part of recon-all?
> >>>
> >>>
> >>>
> >>> 2) If not, I could rename the source NIFTI files (e.g., from the 
> >>> identifiers to something like 'subject001', 'subject002', ...) and 
> >>> re-process everything. This would take some computational time for the > 
> >>> 500 subjects, but it would be okay I guess.
> >>>
> >>> But a large number of the subjects have manual edits applied already. Is 
> >>> there a way to keep the manual edits? E.g., I thought maybe I could 
> >>> rename the individual directories of the edited subjects, leave the 
> >>> edited files in there, and run recon-all again. But what would happen? 
> >>> Will the new output files have the renamed ID from the directory name 
> >>> (and thus the recon-all command line), or will they still use the old ID 
> >>> (from the header of the existing files)? Or will the existing, edited 
> >>> files which contain a different ID be ignored during the new run because 
> >>> the IDs do not match, and thus the existing edits would have no effect?
> >>>
> >>>
> >>> All the best,
> >>>
> >>> Tim
> >>>
> >>> --
> >>> Dr. Tim Schäfer
> >>> Postdoc Computational Neuroimaging
> >>> Department of Child and Adolescent Psychiatry, Psychosomatics and 
> >>> Psychotherapy
> >>> University Hospital Frankfurt, Goethe University Frankfurt am Main, 
> >>> Germany
> >>>
> >>> ___
> >>> 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:/

Re: [Freesurfer] Freeview - command-line label sub-option "opacity" does not work

[Antonin Skoch]

External Email - Use Caution

Hi Ruopeng,


the command is something like:


freeview  -f rh.inflated:label=my.label:opacity=0.5


I see now, that the reason of my problem is that the "opacity" flag is 
dedicated for volume labels (loaded by -l flag), not surface labels (loaded by 
sub-option :label=label_file ) isn't it?


Is it possible to control opacity of surface labels?



Antonin



 Od:   Ruopeng Wang  
 Komu:   Antonin Skoch , Freesurfer support list 
 
 Odesláno:   30.12.2019 19:50 
 Předmět:   Re: [Freesurfer] Freeview - command-line label sub-option "opacity" 
does not work 


Can you post the full command?


Ruopeng 

On Dec 30, 2019, at 1:10 PM, Antonin Skoch  wrote:




External Email - Use Caution

Dear experts,


a freeview command-line label sub-option "opacity" does not work for me.


Freeview exits with error: Unrecognized sub-option flag 'opacity'.



I am using most recent dev version (30 dec 2019).


Could you please check that?

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

[Freesurfer] Freeview - command-line label sub-option "opacity" does not work

[Antonin Skoch]

External Email - Use Caution

Dear experts,


a freeview command-line label sub-option "opacity" does not work for me.


Freeview exits with error: Unrecognized sub-option flag 'opacity'.



I am using most recent dev version (30 dec 2019).


Could you please check that?

Regards,


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

Re: [Freesurfer] Running FSL randomise on FS cortical thickness data

[Antonin Skoch]

External Email - Use Caution

Dear Mark,

I would suggest to use PALM instead:

https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/PALM/UserGuide

PALM supports surface-based data. Each vertex has different area, which has to 
be accounted when the cluster size is computed.

Antonin Skoch



Dear Freesurfer experts,Hi.  We are analyzing cortical thickness data in 
Freesurfer, longitudinal data 
in 55 subjects using the linear mixed effects package.  We are finding a number 
of siginificant clusters, and would like to correct for multiple comparisons 
with permutation testing.  We have already run about 2000 permutations, and 
would like to use TFCE available in randomise rather than empirical methods to 
set parameters such as the cluster forming threshold.

So, the simple question is, how do we convert our FS format data (these are F 
statistics at each vertex) into a format which can be read into randomise?

Thanks for any advice you can provide.

Best,

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

Re: [Freesurfer] nii to gii conversion

[Antonin Skoch]

External Email - Use Caution

Hi Jan,

mri_vol2surf is not the correct command to achieve this.

Use mri_mc or mri_tesselate.

See also

https://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg61335.html

Antonin Skoch


Dear Freesurfer experts,
I would like to run tractography using probtrackx2 tool from one seed ROI 
(cortex) through another waypoint ROI. I need both these masks (ROIs) in gii 
format. Seed ROI I extracted using Freesurfer (recon-all, mri_convert and 
label2surf functions). Then I drew second waipoint ROI using FSLeyes edit tool, 
saved it as binary nii.gz file and tried to convert it to surface gii file 
using mri_vol2surf:mri_vol2surf --src mask.nii.gz --out mask.gii --regheader 
 --reg 
fsl2freesurfer.dat --sd /surf --hemi rh --surf pial --projfrac-max 0 1 
0.05 --out_type gii

But, converted ROI looks empty. Do I have any mistake in command above or is 
there any another way how to convert nii -> gii?

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

Re: [Freesurfer] Undefined function or variable called 'fspecial'

[Antonin Skoch]

External Email - Use Caution

Hello, Vittal,

do you have image processing toolbox of MATLAB installed? The function fspecial 
is part of this toolbox.

Antonin


Hello FS experts,I am trying to run the gyrification index and not able to move 
in the right
direction.
When execute this command "recon-all -s CSRI005 -localGI" and here is the
output copied from the terminal
"#@# Local Gyrification Index lh Wed Jul 10 13:15:03 IST 2019

 mris_compute_lgi --i lh.pial

=
rm -Rf
/usr/local/freesurfer/subjects/CSRI005/surf/tmp-mris_compute_lgi-lh.pial
=
rm: cannot remove
'/usr/local/freesurfer/subjects/CSRI005/surf/tmp-mris_compute_lgi-lh.pial/lh.pial.filled.mgz':
Permission denied
=
mkdir -p
/usr/local/freesurfer/subjects/CSRI005/surf/tmp-mris_compute_lgi-lh.pial
=
=
mris_fill -c -r 1 lh.pial
/usr/local/freesurfer/subjects/CSRI005/surf/tmp-mris_compute_lgi-lh.pial/lh.pial.filled.mgz
=
reading surface from lh.pial...
writing filled volume to
/usr/local/freesurfer/subjects/CSRI005/surf/tmp-mris_compute_lgi-lh.pial/lh.pial.filled.mgz...
mghWrite(/usr/local/freesurfer/subjects/CSRI005/surf/tmp-mris_compute_lgi-lh.pial/lh.pial.filled.mgz,
-1): could not open file
conforming output volume
setting resolution for intermediate calculations to 1.
=
make_outer_surface('/usr/local/freesurfer/subjects/CSRI005/surf/tmp-mris_compute_lgi-lh.pial/lh.pial.filled.mgz',15,'/usr/local/freesurfer/subjects/CSRI005/surf/tmp-mris_compute_lgi-lh.pial/lh.pial-outer');
exit
=

Academic License

>> reading filled volume...
closing volume...
Undefined function or variable 'fspecial'.

Error in make_outer_surface (line 31)
Gaussian = fspecial('gaussian',[2 2],1);

>>
ERROR: make_outer_surface did not create output file
'/usr/local/freesurfer/subjects/CSRI005/surf/tmp-mris_compute_lgi-lh.pial/lh.pial-outer'!
Linux naren123 4.15.0-54-generic #58~16.04.1-Ubuntu SMP Mon Jun 24 13:21:41
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

recon-all -s CSRI005 exited with ERRORS at Wed Jul 10 13:15:10 IST 2019"

Also I have set the MATLAB path for freesurfer and here is the startup.m
file

"% FreeSurfer -%
fshome = getenv('FREESURFER_HOME');
fsmatlab = sprintf('%s/matlab',fshome);
if (exist(fsmatlab) == 7)
addpath(genpath(fsmatlab));
end
clear fshome fsmatlab;
%-%

% FreeSurfer FAST %
fsfasthome = getenv('FSFAST_HOME');
fsfasttoolbox = sprintf('%s/toolbox',fsfasthome);
if (exist(fsfasttoolbox) == 7)
path(path,fsfasttoolbox);
end
clear fsfasthome fsfasttoolbox;
%-% "

I guess the error is because of 2 different user name: I have matlab
license in X name and FreeSurfer can only be executed with root i.e. say Y.
I mentioned both the information above. Wanna know the way to sort out this
issue asap.

Waiting for your reply.

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

Re: [Freesurfer] Doubts in hippocampal subfields labeling

[Antonin Skoch]

External Email - Use Caution

Dear Eugenio,

I have uploaded the subject as file hippocampal_subfields_labeling.tar.gz to 
your server surfer.nmr.mgh.harvard.edu.
RAS coordinates of the unlabeled area are -31,-27,-9.
Thank you in advance,

Antonin



Dear Antonin,
It is difficult to see what’s going on in the images you sent. Would you mind 
uploading the subject, or at least sending us the image without the 
segmentation overlaid (and ideally, a sagittal view as well)?
Cheers,
/Eugenio--
Juan Eugenio Iglesias
Senior research fellow
CMIC (UCL), MGH (HMS) and CSAIL (MIT)
http://www.jeiglesias.com


From:  on behalf of Antonin Skoch 

Reply-To: Antonin Skoch , Freesurfer support list 

Date: Tuesday, 2 July 2019 at 21:43
To: "freesurfer@nmr.mgh.harvard.edu" 
Subject: [Freesurfer] Doubts in hippocampal subfields labeling


External Email - Use Caution
Dear experts,

I noticed that systematically in most of my subjects there is area in 
hippocampal region, labeled in aseg as hippocampus, but NOT labeled as 
hippocampus in hippocampal subfields segmentation (it has zero value there).
See screenshots with norm.mgz overlaid by 1) aseg, 2) hippocampal subfields 
segmentation.

According to T1 and T2 signal, it should neither be white matter and also 
probably not a ventricle/CSF. Neocortex is not located here.
It has similar signal intensity as hippocampus, so I think that it should be 
hippocampus, but I am puzzled by hippocampal subfields segmentation results 
there. Why it is not labeled?

Could you please help me to clarify this? My concern is to correctly label this 
area.
I could upload the example subject if it is of any help.

Regards,

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

[Freesurfer] implausible values of BrainSegVolNotVent

[Antonin Skoch]

  492.8  CC_Mid_Anterior   94.3931    
14.5866    28.   119.    91. 
 45 255  2421  802.6  CC_Anterior   98.2759    
13.0648    29.   118.    89. 


It is in all my processed subjects. Could you please comment on?


Thank you in advance,


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

Re: [Freesurfer] Fwd: Overall maxima is high and still no significant cluster

[Antonin Skoch]

External Email - Use Caution

Dear Martin,

actually, when your primary problem is very high local maxima on p-map, but no 
significant cluster-wise p after thresholding, I guess, that you should try the 
opposite, i.e. increase cluster forming threshold.
This will increase sensitivity to clusters with smaller extent but comprising 
larger p-values before thresholding.

Antonin Skoch



did you do this?

First, install a new version of mri_glmfit-sim from 
ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/6.0.0-patch/mri_glmfit-sim 
(copy it to $FREESURFER_HOME/bin and make it executable with chmod a+rx 
mri_glmfit-sim).On 12/06/2018 01:28 PM, Martin Juneja wrote:
>
> External Email - Use Caution
>
> Thanks Dough for your suggestions. I tried to use permutation method, 
> but its giving me following error:
>
> ERROR: design matrix is not orthogonal, cannot be used with permutation.
>
> If this something you really want to do, run with --perm-force
>
>
> Can you please tell me how can I fix this issue or if I can run with 
> --perm-force?
>
>
> Thanks for the help.
>
>
> On Thu, Dec 6, 2018 at 9:37 AM Greve, Douglas N.,Ph.D. 
> mailto:dgr...@mgh.harvard.edu>> wrote:
>
> For it to show up in the output file, the cluster-wise pvalue must
> be <
> .05 (CWT). To see all the clusters regardless of significance, run it
> with a CWT of 1. If you want to run with a more liberal cluster
> forming
> threshold (CFT), you can try using permutation. See
> http://freesurfer.net/fswiki/FsTutorial/MultipleComparisonsV6.0Perm
>
> On 12/05/2018 11:44 PM, Martin Juneja wrote:
> >
> > External Email - Use Caution
> >
> >
> > Dear experts,
> >
> > Could you please help me in resolving following issue?
> >
> > Thanks.
> > -- Forwarded message -
> > From: *Martin Juneja*  <mailto:mj70...@gmail.com> <mailto:mj70...@gmail.com
> <mailto:mj70...@gmail.com>>>
> > Date: Wed, Nov 28, 2018 at 2:23 PM
> > Subject: Overall maxima is high and still no significant cluster
> > To: Freesurfer support list  <mailto:freesurfer@nmr.mgh.harvard.edu>
> > <mailto:freesurfer@nmr.mgh.harvard.edu
> <mailto:freesurfer@nmr.mgh.harvard.edu>>>
> >
> >
> > Hi FS experts,
> >
> > I am estimating the group-behavioral thickness interaction using
> > contrast 2 FSGD file:
> > https://surfer.nmr.mgh.harvard.edu/fswiki/Fsgdf2G2V at CFT <
> 0.01 and
> > CWT < 0.05 at FWHM of 12 mm.
> >
> > I do not find any significant clusters and my output summary
> text file
> > looks like the following. This file shows that overall maxima is
> > 4.58212 (which corresponds to p < 0.0001 because -log (0.0001) =
> 4, so
> > I am just wondering despite the fact that maxima is > 4, why I
> do not
> > see this cluster in the summary/output *.mgh file?
> >
> > I would really appreciate any clarification and tips to modify my
> > input thresholds so that I do not miss any significant findings
> here.
> >
> > Thanks.
> > -
> >
> > # SearchSpace_mm2 76467.1
> > # SearchSpace_vtx 149953
> > # Bonferroni 2
> > # Minimum Threshold 2
> > # Maximum Threshold infinity
> > # Threshold Sign    abs
> > # AdjustThreshWhenOneTail 1
> > # CW PValue Threshold: 0.05
> > # Area Threshold    0 mm^2
> > # CSD thresh  2.00
> > # CSD nreps    1
> > # CSD simtype  null-z
> > # CSD contrast NA
> > # CSD confint  90.00
> > # Overall max 4.58212 at vertex 10608
> > # Overall min -2.84277 at vertex 75476
> > # NClusters          0
> > # FixMNI = 0
> > #
> > # ClusterNo  Max   VtxMax   Size(mm^2)  MNIX  MNIY  MNIZ    CWP
> > CWPLow    CWPHi   NVtxs   WghtVtx   Annot
> >
> >
> > ___
> > Freesurfer mailing list
> > Freesurfer@nmr.mgh.harvard.edu
> <mailto:Freesurfer@nmr.mgh.harvard.edu>
> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Lacunes

[Antonin Skoch]

External Email - Use Caution

Dear Emily,

similar errors I usually try to correct by editing wm.mgz (fill the spots by 
intensity 255). But it does not work always (mainly when the hypointensities 
are of large extent, it often does not help either).

Antonin


Hi Emily

it's going to be tough to get it past the gray matter lesions. If you  have 
labels we could implement something to fill them in with surrounding  tissue 
intensities I suppose, but we don't have anything at the moment sorry
Bruce
On  Wed, 31 Oct 2018, Emily Schwartz wrote: External Email - Use 
Caution

Hi Freesurfer team,

I was wondering if there is a way to edit incorrect surfaces due to lacunes? As 
you can see in the
image the surfaces are incorrect. I tried editing the aseg, but this did not 
work. I have attached
both images in the coronal and axial view as well as FLAIR (obviously there are 
other errors that
need to be fixed in this subject as well).

I am using version 6.0 
(freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0-2beb96c).

Any guidance is appreciated.

Thank you,

Emily

Emily Schwartz, B.A.
Research Assistant
Department of Neurology -- Cognitive and Motor Aging
Albert Einstein College of Medicine

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

Re: [Freesurfer] segmentHA_T1.sh exits with error

[Antonin Skoch]

External Email - Use Caution

Dear Eugenio,

here it is:

asegModBinDilated.mgz
asegModBinDilatedResampled.mgz
asegModCHA.mgz
asegMod.mgz
asmr1.mgz
asmr2.mgz
asmr3.mgz
compressionLookupTable.txt
discreteLabels_all.mgz
discreteLabelsMergedBodyHead.mgz
discreteLabels.mgz
discreteLabelsWholeBodyHead.mgz
error.log
hippoAmygBinaryMask_autoCropped.mgz
hippoAmygBinaryMask.mgz
hippoMaskDilated5mm.mgz
hippoMask.mgz
hippoMaskResampledDilated.mgz
hippoMaskResampled.mgz
imageDump.mgz
image.mgz
T1resampled.mgz
trash.lta
volumesAmygdala.txt
volumesHippo.txt
warpedMeshNoAffine.txt.gz
warpedMesh.txt.gz
warpedOriginalMesh.txt.gz

Antonin


Dear Antonin,
Can you please send me a listing of the files in:
/hydra-db/hydra_io/vypocty/freeSurfer/A_analysis_HPC_PFC/A_links_all/ESO_C00577_20160303_1246_1/tmp/hippoSF_T1_v21_right/
Kind regards,
/Eugenio--
Juan Eugenio Iglesias
ERC Senior Research Fellow
Centre for Medical Image Computing (CMIC)
University College London
http://www.jeiglesias.com
http://cmictig.cs.ucl.ac.uk/


From:  on behalf of Antonin Skoch 

Reply-To: Freesurfer support list 
Date: Friday, 17 August 2018 at 18:16
To: "freesurfer@nmr.mgh.harvard.edu" 
Subject: [Freesurfer] segmentHA_T1.sh exits with error


External Email - Use Caution
Dear experts,

I am running segmentHA_T1.sh. In about 3 subjects from 200, the script exits 
with following error:

In an assignment  A(:) = B, the number of elements in A and B must be the same.

Error in segmentSubjectT1_autoEstimateAlveusML (line 1856)

MATLAB:subsassignnumelmismatch
Command exited with non-zero status 255

Full log file is attached. I have also uploaded whole subject (named 
segmentHA_T1_error.tar.gz ), including content of temporary directory  
hippoSF_T1_v21_right, to your server.

I am using dev version, build 2018-07-28. I am using customized recon-all, but 
it should not relate to this error. Could you please look at this issue?

Regards,

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


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

Re: [Freesurfer] non-stationarity in CTh maps

[Antonin Skoch]

External Email - Use Caution


Dear experts,


following on this old thread, do you have any new knowledge on the possible 
severity of non-stationarity in cortical-thickness maps and its effect on 
permutation-based cluster-extent inference? Given current status of 
development, is here a possibility to estimate it/correct for it?


Regards,


Antonin Skoch



Hi Hugo, they are assumed to be stationary. I've never tried to figure out how 
much of a problem this is.doug

On 7/25/12 6:03 PM, Hugo Baggio wrote:
Dear all,I have been performing cortical thickness analyses and as far as I 
understand the thickness maps are non-stationary (please correct me if I'm 
wrong). I have two questions: 1. How susceptible is Monte Carlo clusterwise 
correction to this(should I expect clusters at smoother areas to be bigger?)? 
2. Does FS perform some sort of correction to this non-stationarity or are 
images assumed to be stationary at statistical analyses?Thanks a lot for your 
help!

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


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

Re: [Freesurfer] recon-all error: mri_label2label.bin: could not open label file lh.BA1_exvivo.label

[Antonin Skoch]

External Email - Use Caution

Hi Naomi,


does the symbolic link


/panfs/pan.fsl.byu.edu/scr/usr/74/intj5/analyses/ACAP-BRAVOS/freesurfer/fsaverage


exist in your filesystem?


Antonin Skoch



Hello FreeSurfer Developers, 

I'm attempting to run FreeSurfer but I get the following error when I run the 
recon-all command: 

> ERROR reading 
> /panfs/pan.fsl.byu.edu/scr/usr/74/intj5/analyses/ACAP-BRAVOS/freesurfer/fsaverage/label/lh.BA1_exvivo.label
>  <" target="_blank" id="ext-gen1283" style="box-sizing: 
> border-box;">http://pan.fsl.byu.edu/scr/usr/74/intj5/analyses/ACAP-BRAVOS/freesurfer/fsaverage/label/lh.BA1_exvivo.label>;
>  

I've searched the list and no similar errors have been reported. Does anyone 
have any thoughts on how to trouble-shoot this one? Also, Ive attached the 
recon-all.log in case it's of any use. 

1) FreeSurfer version: 
freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0-2beb96c 
2) Platform: Red Hat Enterprise Linux Server release 6.6 (Santiago) 
3) uname -a: Linux m8-8-5 2.6.32-696.18.7.el6.x86_64 #1 SMP Thu Dec 28 20:15:47 
EST 2017 x86_64 x86_64 x86_64 GNU/Linux 
4) recon-all.log: see attached 

Thanks, 

Naomi ___
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_compute_volume_fractions

[Antonin Skoch]

External Email - Use Caution

Dhivya,

this syntax works for me with version 6. With version 5.3.0 I am getting the 
same error mesage. I do not know how the correct syntax is with version 5.3.0.
Antonin Skoch

Yep , I am using  "o"  .I am running it on Ubuntu 16.04 and my freesurfer 
version is ,

freesurfer/5.3.0/bin/freesurfer

mri_compute_volume_fractions --o test --regheader 002_S 002_S/mri/norm.mgz

still I am getting , unknown option --o

Trying to give as per documentation, which is 

--o outstem --regheader subject 

I am really sorry to bother you with so many questions. Is it something to do 
with version of freesurfer?

From: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Bruce Fischl 
[fis...@nmr.mgh.harvard.edu]
Sent: Thursday, April 26, 2018 11:13 AM
To: Freesurfer support list
Subject: Re: [Freesurfer] mri_compute_volume_fractions

hmmm, are you sure you are using an  "o" and not a "0"? And the --regheader
syntax different than I thought, it requires two argments, a subject name
and a template volume (if you are using the anatomical space, any of the
conformed volumes such as the norm.mgz should be fine). For example, I run:

mri_compute_volume_fractions --o test --regheader bruce.dev 
bruce.dev/mri/norm.mgz
$Id: mri_compute_volume_fractions.c,v 1.22 2015/09/14 12:25:01 fischl Exp $
sysname  Linux
hostname sulc.nmr.mgh.harvard.edu
machine  x86_64
user fischl
setenv SUBJECTS_DIR /homes/4/fischl/links/subjects
cd /autofs/space/tiamat_003/users/subjects
mri_compute_volume_fractions --o test --regheader bruce.dev
bruce.dev/mri/norm.mgz
outstem test
regfile (null)
regtype 0
segfile aseg.mgz
.
.
.


On Thu, 26 Apr 2018, Srinivasan, Dhivya wrote:

>External Email - Use Caution
>
> mri_compute_volume_fractions --o test --regheader
> unknown option --o
>
> If I am not giving any input before arguments, it is not taking them.
>
> Thanks,
> Dhivya
> 
> From: freesurfer-boun...@nmr.mgh.harvard.edu 
> [freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Bruce Fischl 
> [fis...@nmr.mgh.harvard.edu]
> Sent: Thursday, April 26, 2018 10:52 AM
> To: Freesurfer support list
> Subject: Re: [Freesurfer] mri_compute_volume_fractions
>
> just run the command as I sent it:
>
>  mri_compute_volume_fractions --o test --regheader
>
> the aseg is the default name. You are putting it in the wrong place and it
> thinks the aseg is a registration file
>
> On Thu, 26 Apr 2018, Srinivasan, Dhivya wrote:
>
>>External Email - Use Caution
>>
>> I am getting same Error with many permutations of arguments,
>>
>> mri_compute_volume_fractions 002_S/mri/aseg.mgz --o test --regheader 
>> identity.nofile
>>
>> arg = 6
>> reading registration file 002_S/mri/aseg.mgz
>> regio_read_register(): Success
>> Error reading inplaneres from 002_S/mri/aseg.mgz
>> regio_read_register(): Success
>> Error reading inplaneres from 002_S/mri/aseg.mgz
>> mri_compute_volume_fractions: could not load registration file from 
>> 002_S/mri/aseg.mgz
>>
>>
>> Thanks,
>> Dhivya
>>
>>
>>
>> 
>> From: freesurfer-boun...@nmr.mgh.harvard.edu 
>> [freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Bruce Fischl 
>> [fis...@nmr.mgh.harvard.edu]
>> Sent: Wednesday, April 25, 2018 6:21 PM
>> To: Freesurfer support list
>> Subject: Re: [Freesurfer] mri_compute_volume_fractions
>>
>> try
>>
>> mri_compute_volume_fractions --o test --regheader
>>
>> On Wed, 25 Apr 2018, Srinivasan, Dhivya wrote:
>>
>>>External Email - Use Caution
>>>
>>> Thanks Bruce!
>>>
>>> I even tried with --regheader
>>>
>>> mri_compute_volume_fractions mri/aseg.mgz --o test --regheader 
>>> identity.nofile
>>>
>>> It gives me below error,
>>>
>>> arg = 6
>>> reading registration file mri/aseg.mgz
>>> regio_read_register(): Success
>>> Error reading inplaneres from mri/aseg.mgz
>>> regio_read_register(): Success
>>> Error reading inplaneres from mri/aseg.mgz
>>> mri_compute_volume_fractions: could not load registration file from 
>>> mri/aseg.mgz
>>>
>>> Thanks,
>>> Dhivya
>>> 
>>> From: freesurfer-boun...@nmr.mgh.harvard.edu 
>>> [freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Bruce Fischl 
>>> [fis...@nmr.mgh.harvard.edu]
>>> Sent: Wednesday, April 25, 2018 6:01 PM
>>>

[Freesurfer] Segmentation of anterior and posterior commissures

[Antonin Skoch]

Dear experts,


a question was raised whether it is possible to automatically segment anterior 
and posterior commissures. Do you think that it is achievable with reasonable 
accuracy, using in-vivo data of 0.7 mm3 resolution?


I was thinking what would be the best way:
a) Is it possible to customize Hippocampal subfields segmentation framework to 
achieve this goal?


b) I considered the most straightforward option to extend current 
RB_all_2016-05-10.vc700.gca atlas to include also labels of anterior and 
posterior commisure. However, this would need to have labeled source subjects 
for this atlas. Is it publicly available? If yes, do you think that it makes 
sense to do it this way?


c) In case of source subjects for RB_all_2016-05-10.vc700.gca are not 
available, then there would be option to create the atlas from scratch. Does it 
make sense to do it like following:
Take let's say 10 representative subjects, run them through recon-all, take 
their aseg.mgz, manually label their commissures (only, other stuff in aseg.mgz 
leave as is) and run rebuild_gca_atlas.sh on relabeled aseg.mgz? This (in 
contrast to do the manual labeling of whole brain) seems doable to me. I do not 
know how the resolution of subjects constituting RB_all_2016-05-10.vc700.gca 
was, so maybe doing labeling on our 0.7mm3 subjects could lead to even more 
accurate results, than option b)? Could you please comment on?


Regards,


Antonin Skoch

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


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

Re: [Freesurfer] recon-all | ln -s error

[Antonin Skoch]

Dear Pradeep,
this issue has appeared several times already here. See following thread:
https://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52560.html
Antonin Skoch

Hello All, My $SUBJECTS_DIR is located on an external disk that was mounted and 
recon-all exited with errors at ln -s lh.white.preaparc.H lh.white.HI was not 
able to perform this operation with sudo as well 4172_vsl/surf$ sudo ln -s 
lh.white.preaparc.H lh.white.H ln: failed to create symbolic link 'lh.white.H': 
Operation not supported but cp works 4172_vsl/surf$ cp lh.white.preaparc.H 
lh.white.H has any one come across this problem and what is the best way to fix 
this? Thanks, Pradeep


Hello All,

My $SUBJECTS_DIR is located on an external disk that was mounted and
recon-all exited with errors at ln -s lh.white.preaparc.H lh.white.HI was not 
able to perform this operation with sudo as well

4172_vsl/surf$ sudo ln -s lh.white.preaparc.H lh.white.H
ln: failed to create symbolic link 'lh.white.H': Operation not supported

but cp works
4172_vsl/surf$ cp lh.white.preaparc.H lh.white.H

has any one come across this problem and what is the best way to fix this?

Thanks,
Pradeep___
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] analysing scans other than brain

[Antonin Skoch]

Dear Matyas,

this (not brain-specific) R package will be maybe more suitable for your 
purpose:

http://onlinelibrary.wiley.com/doi/10./2041-210X.12035/full
https://cran.r-project.org/web/packages/geomorph/index.html

I generally would recommend to rather look for packages used in community of 
anthropologists or evolutional biologists.

Antonin


Hi Matyas

we have online tutorials on our wiki and data you can download. Not sure  how 
easy it will be though - a lot of what we do is brain specific Bruce
On Mon, 5 Mar 2018, Matyas Varga wrote:

Dear Bruce,

Thank you for your quick reply.  I think that whatever software I am going to 
use, it will require some coding as most similar software are brain specific.
I use Matlab on a regular basis, and am happy to learn c in order to complete 
this project. My ultimate aim is to create a software or adapt an existing one 
for use on feet, for podiatrist and researchers.
I was wondering if you could give me some suggestions as to where to start this 
using Free Surfer?

Thank you.

Best Regards

Matyas Varga
School of Health Sciences Research
University of Brighton
Aldro Building, 49 Darley Road
Eastbourne, BN20 7UR

-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Bruce Fischl
Sent: 05 March 2018 17:05
To: Freesurfer support list 
Subject: Re: [Freesurfer] analysing scans other than brain

Hi Matyas

it is possible, but will be a fair amount of work, probably including some c 
coding since many of our tools are brain-specific

cheers
Bruce


On Mon, 5 Mar 2018, Matyas Varga wrote:

Dear Free Surfer,

 

I was wondering if it was possible to analyse (surface-based morphometry and 
SPM) NOT brain scans.

I am doing my PhD looking at how the shape of children’s feet change
as they get older (2-7 years old).

 

I will use a 3D scanner which will provide me with a mesh of triangles
of the foot and I am considering to create average age group foot
shapes and compare them using surface based morphometry and SPM.

I will obviously have to create my own foot ”atlas”. I was wondering
if this was possible in Free Surfer?

 

Please let me know if it is possible or if you have any suggestions if it is 
not.

 

Thank you.

 

Best Regards

 

Matyas Varga

PhD student

School of Health Sciences Research

University of Brighton

Aldro Building, 49 Darley Road

Eastbourne, BN20 7UR

Tel: 01273 644189

 


___
This email has been scanned by MessageLabs' Email Security System on
behalf of the University of Brighton. For more information see:
https://staff.brighton.ac.uk/is/computing/Pages/Email/spam.aspx


___
This email has been scanned by MessageLabs' Email Security System on behalf of 
the University of Brighton. For more information see:
https://staff.brighton.ac.uk/is/computing/Pages/Email/spam.aspx

___
This email has been scanned by MessageLabs' Email Security System
on behalf of the University of Brighton. For more information see:
https://staff.brighton.ac.uk/is/computing/Pages/Email/spam.aspx

___
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


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] Strange Segmentation

[Antonin Skoch]

Dear Arkadiy,

I see sometimes these kind of errors. I think they are caused by local 
mis-segmentation due to WM hypointensities (enlarged perivascular spaces or 
other lesions, usually benign) located just under GM. Sometimes it is hard to 
discern where it is a hypointensity and where it is just a sulcus. I recommend 
to assess them using all 3 slice orientations. I correct them by editing wm.mgz 
(filling in voxels by value 255).

Regards,

Antonin Skoch


Dear Experts, 
This brain looks a little bit strange to us, and I was wondering if  someone 
might be able to chime in about whether this is worth editing,  based on the 
screenshots of different slices from the sagittal view.. 
Thank you for your expertise. 
-Arkadiy ___
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] Incorrect display of control points when image geometries differ

[Antonin Skoch]

Dear experts,

I encountered a pitfall with displaying control points in freeView.
When the T1 and T2 geometry differs (which can occur for example in hires 
stream where data are not conformed to 1mm3), it depends on which volume is 
active when control.dat is loaded.
For example, when control.dat is loaded with active T2 (which has different 
geometry than T1/brainmask), the control points are displayed on the incorrect 
position of the volume. This affects also loading data on commandline. For 
example:
freeview -v T1.mgz -v T2.mgz -c control.dat
displays control points incorrectly.
freeview -v T2.mgz -v T1.mgz -c control.dat
displays control points correctly.

Note, also, that in case of differing geometry of loaded images, the user has 
to pay special attention to select proper reference volume (brainmask.mgz or 
other derived images) when control points are created. The choice of reference 
volume is noted in the official documentation but maybe it can be easily 
overlooked with serious consequences.

To summarize, 4 different cases can occur:

control.dat created with reference volume brainmask.mgz, loaded into freeView 
with active volume brainmask.mgz -> all OK - control points applied correctly 
and also displayed correctly
control.dat created with reference volume brainmask.mgz, loaded into freeView 
with active volume T2.mgz -> control points applied correctly, but displayed 
incorrectly (so issue only with display)
control.dat created with reference volume T2.mgz loaded into freeView with 
active volume T2.mgz -> control points applied incorrectly, but displayed 
correctly in freeView (serious case !!)
control.dat created with reference volume T2.mgz displayed with active volume 
brainmask.mgz -> control points applied incorrectly and also displayed 
incorrectly

Antonin Skoch

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


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

Re: [Freesurfer] FreeSurfer recon-all issue

[Antonin Skoch]

Dear Shadia,

please check, that you really edited your recon.all, as I suggested in my 
previous mail. Your recon-all file is located here:
/home/s1163658/freesurferv60/bin/recon-all

According to your recon-all.log, there is still an ln -s command invoked (which 
should be replaced by cp command).

It is normal that the log from new invocation of recon-all is appended to 
current recon-all.log.

As a test, you can try to run only the step which is currently failing:

recon-all -s your_subject -curvHK

Also, by default, recon-all invocation does not automatically account already 
finished steps.
To skip already successfully finished steps, you can try to run
recon-all -s your_subject -make all (not sure if it works OK in v6)

or explicitly list steps which need to be run:

recon-all -s your_subject -curvHK -curvstats -autorecon3

Antonin




Dear Antonin,  
 
Thank you for your suggestions at 
https://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/2017-December/055319.html 
. I've tried both, but the process still fails at the same point.  
 
It appears that I now am left with a recon-all log file (attached)  that is 
double in length (run 1 ending at line 4187, and run 2 ending at  8276), both 
of which have started from step 1, rather than run 2  resuming from where we 
last stopped.  
 
Should I be adding certain flags for recon-all to resume rather than  start 
from the beginning? The way I did it was the same as before, but  without the 
-I flag in the second run, as suggested by the recon-all  prompt.  
 
Thanks again.  
 
Shadia 
 
 
--  
The University of Edinburgh is a charitable body, registered in 
Scotland, with registration number SC005336. 
 
 
-Original Message- 
From: MIKHAEL Shadia  
Sent: 28 December 2017 10:12 
To: 'freesurfer@nmr.mgh.harvard.edu'  
Subject: FreeSurfer recon-all issue 
 
Hello all,  
 
I'm having trouble with recon-all on a Linux server, I'm running into the 
following error for all of my subjects:  
 
. 
 mris_curvature -w lh.white.preaparc 
 
total integrated curvature = 6.657*4pi (83.654) --> -6 handles  ICI = 129.9, FI 
= 1309.2, variation=20703.115 writing Gaussian curvature  to 
./lh.white.preaparc.K...done. 
writing mean curvature to ./lh.white.preaparc.H...done. 
rm -f lh.white.H 
ln -s lh.white.preaparc.H lh.white.H 
ln: creating symbolic link `lh.white.H': Operation not supported  Linux bsrv10 
. #1 SMP Tue Nov 15 14:13:21 CST 2016 x86_64 x86_64  x86_64 GNU/Linux 
 
I've tried to create a symbolic link as suggested in 
https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2014-September/040476.html
 , but I still get a message saying operation not supported 
 
ln -s /usr/local/freesurfer/subjects/fsaverage 
/home/s1163658/W/Cortical_analyses_for_ageing_and_dementia/NIH_Shadia 
ln: creating symbolic link  
`/home/s1163658/W/Cortical_analyses_for_ageing_and_dementia/NIH_Shadia/fsaverage':
  Operation not supported 
 
 
I've also tried to manually create the symbolic link in that last  line: ln -s 
lh.white.preaparc.H lh.white.H But again it says operation  not supported. 
 
Recon-all log: attached 
Freesurfer version: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0-2beb96c   
 
Any advice? 
 
Thank you 
 
Shadia  ___
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] Remove address

[Antonin Skoch]

Dear Antoine,

look here:
 http://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


Antonin



 
 Is it possible to quit the freesurfer mailing list ?

Best regards,
Antoine

___
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 recon-all issue

[Antonin Skoch]

Dear Shadia,

There are 2 spots in recon-all where symbolic link is created. 

The first you can overcome by:
find following line in your recon-all:

set cmd2 = (ln -s $hemi.white.preaparc.$suffix $hemi.white.$suffix)
and replace it by
set cmd2 = (cp $hemi.white.preaparc.$suffix $hemi.white.$suffix)

The second you overcome by copying the directory  
$FREESURFER_HOME/subjects/fsaverage and all its contents of to your 
$SUBJECTS_DIR.

Then rerun recon-all on your subject.

Antonin Skoch


Hello all,  
 
I'm having trouble with recon-all on a Linux server, I'm running into the 
following error for all of my subjects:  
 
. 
 mris_curvature -w lh.white.preaparc 
 
total integrated curvature = 6.657*4pi (83.654) --> -6 handles 
ICI = 129.9, FI = 1309.2, variation=20703.115 
writing Gaussian curvature to ./lh.white.preaparc.K...done. 
writing mean curvature to ./lh.white.preaparc.H...done. 
rm -f lh.white.H 
ln -s lh.white.preaparc.H lh.white.H 
ln: creating symbolic link `lh.white.H': Operation not supported 
Linux bsrv10 . #1 SMP Tue Nov 15 14:13:21 CST 2016 x86_64 x86_64 x86_64 
GNU/Linux 
 
I've tried to create a symbolic link as suggested in 
https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2014-September/040476.html
 , but I still get a message saying operation not supported 
 
ln -s /usr/local/freesurfer/subjects/fsaverage 
/home/s1163658/W/Cortical_analyses_for_ageing_and_dementia/NIH_Shadia 
ln: creating symbolic link  
`/home/s1163658/W/Cortical_analyses_for_ageing_and_dementia/NIH_Shadia/fsaverage':
  Operation not supported 
 
 
I've also tried to manually create the symbolic link in that last line: ln -s 
lh.white.preaparc.H lh.white.H 
But again it says operation not supported. 
 
Recon-all log: attached 
Freesurfer version: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0-2beb96c   
 
Any advice? 
 
Thank you 
 
Shadia  ___
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] bad midline cut

[Antonin Skoch]

Bruce, Gabor,

may I ask, does it ever matter where the midline surface lies? I thought that 
this does not affect anything in the analysis.

Antonin


hmmm, if you tar, gzip and upload the subject I'll take a look. 
 
Bruce 
On Tue, 26  
Sep 2017, Gabor Perlaki wrote: 
 
> I've already corrected aseg.presurf.mgz and the left and right lateral 
> ventricles are now correct in 
> the final aseg.mgz. However the pial surface is almost the same as earlier: 
>  
> https://mega.nz/#!XAZkWLZa!a6NgkEtiHzEqUkhZ6WimPgUKxytsGHKrgOLfyHdUuEM 
>  
> https://mega.nz/#!XRRHna7Q!vaeSLG5Cv-fGW-0xdEJlgFTNRPm7qGHOlShYh7y5z1g 
>  
>  ___
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] bad midline cut

[Antonin Skoch]

Dear Bruce, Gabor,

while reading this thread, I think that there is misunderstanding.

-noaseg flag of recon-all indeed disables using aseg.presurf,

 whereas -autorecon2-noaseg does the same thing as -autorecon2-cp

(at least in dev version, looking at the recon-all code). 

Antonin Skoch


Hi Gabor 
 
you don't want to specify -noaseg. That tells recon-all not to use the  
aseg. I think autorecon2-cp and autorecon3 should do the trick 
 
cheers 
Bruce 
On Tue, 26 Sep 2017, Gabor Perlaki wrote: 
 
> Dear Bruce, 
>  
> I've corrected the lateral ventricles in the aseg.presurf.mgz and ran 
> "recon-all -autorecon2-noaseg 
> -autorecon3 -subjid". Although the labels in aseg.mgz is fine the surfaces 
> (and midline cut) 
> remained bad. Any other idea how to correct this type of error? 
>  
> Best Regards, 
> Gabor 
>  
> ___
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] Antwort: Re: use manually defined talairach.xfm

[Antonin Skoch]

Dear Clemens,

I now see where is the problem:

The current implementation of recon-all -talairach step is quite complicated, 
as far as I understand:

The -talairach registration step produces talairach.auto.xfm. If the 
talairach.xfm exists, it is not overwritten by talairach.auto.xfm (unless 
-clean-tal is specified on the command line). For further recon-all processing 
steps the talairach.xfm is used. It assures that when talairach.xfm is edited 
(for example by tkregister2), the edits are not overwritten, but only IN THIS 
VERY STEP.

Further step is talairach failure detection, which uses talariach.xfm. When the 
failure detection passes, everything is ok and recon-all proceeds further 
(using talairach.xfm). However, when the failure detection indicates failure, 
the current implementation is to use alternative talairach registration 
procedures - first it is trying to align to 3T-based atlas and if it also 
fails, it is trying to use MINC mritotal tool. And here comes the problem: In 
both these steps the talairach.xfm is by default OVERWRITTEN by 
talairach.auto.xfm. This has consequence, that when user is modyfying 
talairach.xfm (i.e. by tkregister2) and this modified talairach.xfm also do not 
pass failure detection, it is OVERWRITTEN as indicates following lines in your 
recon-all.log code:
cp transforms/talairach.auto.xfm transforms/talairach.xfm I personally think 
that this is not very optimal behaviour and it deserves modification of the 
recon-all code by developers.

So the remedy for your case would be:

either
try to align better your data in tkregister2, and rerun trecon-all -s subj_id 
-all until you pass talairach failure detection of your customized 
talairach.xfm. If the talairach check failed and your talairach.xfm is 
overwritten, you will find it in the subdirectory transforms-bak.

or
after tkregister2, rerun your data by adding -notal-check to your recon-all:
recon-all -s subj_id -all -notal-check

Antonin





Dear Antonin 
 
Yes, that is the directory where - after failed recon-all - I  opened, manually 
registered, then saved the talairach.xfm file. Before I  re-ran recon-all, I 
reopened the modified talairach.xfm file with   tkregister2 to verify that it 
was my manual registration, which was  true. 
 
I attached the recon-all log and error files and the talairach and 
talairach-avi log file. 
 
Version: freesurfer-Darwin-OSX-stable-pub-v6.0.0-2beb96c 
 
Clemens 
 
 
-freesurfer-boun...@nmr.mgh.harvard.edu schrieb: - 
An: freesurfer@nmr.mgh.harvard.edu 
Von: Antonin Skoch  
Gesendet von: freesurfer-boun...@nmr.mgh.harvard.edu 
Datum: 16.08.2017 12:23 
Betreff: Re: [Freesurfer] Antwort: Re: use manually defined talairach.xfm 
 
Dear Clemens, 
 
I am almost out of ideas, since the behaviour is contrary to my expectations. 
 
I would expect that if you run your recon by  
 
recon-all -s subject_id -all 
 
the files you named  
 
before_recon-all_talairach.xfm and after_recon-all_alairach.xfm 
 
should be identical. 
 
Could you assure that after tkregister2, you saved the transform file under 
name talairach.xfm and put into directory  
 
/Volumes/PromisePegasus/HippocampusPreparedT1Data/subjects/x140214_b02_0917040_3_1_wipmp2rage0p8mmsenseV42_reOrient/mri/transforms
  ? 
What freeSurfer version are you using? Could you post full recon-all output? 
 
 
Antonin 
 


Hi Antonin

Thank you for your reply.Here is what I did:
1.  tkregister2 --mgz --s 
x140214_b02_0917040_3_1_wipmp2rage0p8mmsenseV42_reOrient --fstal
2.  manual registration (see attached file “before_recon-all_talairach.xfm”)
3.  re-run recon-all, which is: recon-all -s 
x140214_b02_0917040_3_1_wipmp2rage0p8mmsenseV42_reOrient -all 
-hippocampal-subfields-T1

This resulted in the following error message:
#@# Talairach Failure Detection Wed Aug 16 08:53:15 CEST 2017
/Volumes/PromisePegasus/HippocampusPreparedT1Data/subjects/x140214_b02_0917040_3_1_wipmp2rage0p8mmsenseV42_reOrient/mri
\n talairach_afd -T 0.005 -xfm transforms/talairach.xfm \n
ERROR: talairach_afd: Talairach Transform: transforms/talairach.xfm 
***FAILED*** (p=0.0622, pval=0.0034 < threshold=0.0050)
\nManual Talairach alignment may be necessary, or
include the -notal-check flag to skip this test,
making sure the -notal-check flag follows -all
or -autorecon1 in the command string.
See:\n
http://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/Talairach

\nERROR: Talairach failed!\n


The file that I now find in the “transforms” folder is attached 
(“after_recon-all_talairach.xfm”).

I also attached the two talairach.auto.xfm but I didn’t modify these at any 
point.
(Should I? If so, how do I?)

Clemens


-freesurfer-boun...@nmr.mgh.harvard.edu schrieb: -
An: freesurfer@nmr.mgh.harvard.edu
Von: Antonin Skoch 
Gesendet von: freesurfer-boun...@nmr.mgh.harvard.edu
Datum: 15.08.2017 16:46
Betreff: Re: [Freesurfer] use manually defined talairach.xfm

Dear Clemens,

this is very strange, since the talairach.xfm is not

Re: [Freesurfer] Antwort: Re: use manually defined talairach.xfm

[Antonin Skoch]

Dear Clemens,

I am almost out of ideas, since the behaviour is contrary to my expectations.

I would expect that if you run your recon by 

recon-all -s subject_id -all

the files you named 

before_recon-all_talairach.xfm and after_recon-all_alairach.xfm

should be identical.

Could you assure that after tkregister2, you saved the transform file under 
name talairach.xfm and put into directory 

/Volumes/PromisePegasus/HippocampusPreparedT1Data/subjects/x140214_b02_0917040_3_1_wipmp2rage0p8mmsenseV42_reOrient/mri/transforms
 ?
What freeSurfer version are you using? Could you post full recon-all output?


Antonin

___
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] Help with hippocampal subfield alignment

[Antonin Skoch]

Dear Elizabeth,

I would guess that something went seriously wrong in the recon-all with your 
data. Does Talairach registration and skull strip look reasonable? 


Antonin Skoch

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


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

Re: [Freesurfer] use manually defined talairach.xfm

[Antonin Skoch]

Dear Clemens,

this is very strange, since the talairach.xfm is not by default overwritten in 
recon-all (unless you specified -clean-tal to recon-all).

When you rerun your recon-all after modifying talairach.xfm, your automatic 
talairach registration will be saved into talairach.auto.xfm, therefore 
talairach.auto.xfm and talairach.xfm will be different (without editing they 
will be identical).

See the excerpt of the recon-all -help:

Talairach (-talairach)

This computes the affine transform from the orig volume to the MNI305
atlas using Avi Snyders 4dfp suite of image registration tools,
through a FreeSurfer script called talairach_avi. Several of the downstream
programs use talairach coordinates as seed points. You can/should check
how good the talairach registration is using
"tkregister2 --s subjid --fstal-avi". You must have an "fsaverage" subject in
your SUBJECTS_DIR. tkregister2 allows you to compare the orig volume
against the talairach volume resampled into the orig space. If you modify
the registration, it will change the talairach.xfm file. Your edits will
be *not* be overwritten unless you run recon-all specifying -clean-tal.
Run "tkregister2 --help" for more information.
Creates the files mri/transform/talairach.auto.xfm and talairach.xfm.
The flag -tal-check will check the registration against known-good transforms.
Adding the flag -use-mritotal after -talairach will use the MINC program
mritotal (see Collins, et al., 1994) to perform the transform.

Can you check that your edited talairach.xfm is indeed modified to default 
after recon-all rerun? Do the talairach.xfm and talairach.auto.xfm differ?

Antonin




___
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] info on samseg routines

[Antonin Skoch]

Dear experts,

I would like to ask, whether I could obtain a basic general info on samseg 
routines - what specifically are they doing (publication reference) and how to 
use them?

Regards,

Antonin Skoch


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


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

[Freesurfer] obtaining the most recent build of FreeSurfer development version

[Antonin Skoch]

Dear experts,

I would like to download the most recent build of FreeSurfer development 
version (linux 64 bit). 

The origin/dev git repository contains commit up to today (14.8.17), but last 
change of "daily build" of dev version is 28.7.17. 

ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/dev/freesurfer-Linux-centos6_x86_64-dev.tar.gz

How is the build of dev version sheduled?

Antonin Skoch


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


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

[Freesurfer] white surface contour discontinued in 2D display in freeView

[Antonin Skoch]

Dear experts,

In one subject I found discontinued white surface contour in 2D display in 
freeView. See the screenshot.

I have also uploaded the subject as discontinued_white_surf dir to your server 
so that you can take look and diagnose.
RAS coordinates: -19.52,37.81,22.53.


The discontinuity is only present in coronal view. Looking at the data in 3D 
display, I see nothing unusual except that the density of the vertices in that 
region is very low. Is it only an issue with freeView display?

Regards,

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


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

Re: [Freesurfer] Switch FreeSurfer Desikan-Killiany atlas to Civet

[Antonin Skoch]

Dear Trisanna,

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

Antonin



I believe the cortical thickness measures are taken slightly differently.
This paper might offer some 
insights.https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4408913/

Trisanna

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


On Fri, Jul 14, 2017 at 8:29 AM, Antonin Skoch  wrote:

> Dear Zhiquiang,
>
> as a regular user of FreeSurfer I am wondering, what is the advantage of
> using Civet instead of FreeSurfer?
>
> Are there some functionalities in Civet which are not available in
> FreeSurfer?
> Or does Civet offer better performance/accuracy/precision in estimation of
> surface models for some situations/datasets?
>
> Antonin Skoch
>
>
> Hello FreeSurfer Developers,
>
> I am attempting to switch the Desikan-Killiany atlas of FreeSurfer to Civet.
> But I have no idea to solve the problem. Would you like to give me some
> suggestions or some detailed steps to help me accomplish the tasks ?
>
>
> Best wishes,
> Zhiqiang Sha
>___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

Re: [Freesurfer] Switch FreeSurfer Desikan-Killiany atlas to Civet

[Antonin Skoch]

Dear Zhiquiang,

as a regular user of FreeSurfer I am wondering, what is the advantage of using 
Civet instead of FreeSurfer?

Are there some functionalities in Civet which are not available in FreeSurfer? 
Or does Civet offer better performance/accuracy/precision in estimation of 
surface models for some situations/datasets?

Antonin Skoch

Hello FreeSurfer Developers,
I am attempting to switch the Desikan-Killiany atlas of FreeSurfer to Civet. 
But I have no idea to solve the problem. Would you like to give me some 
suggestions or some detailed steps to help me accomplish the tasks ?


Best wishes,
Zhiqiang Sha___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

[Freesurfer] Regression diagnostic in context of surface-based analysis

[Antonin Skoch]

Dear experts,

I am looking for a way how to effectively run a regression model diagnostic in 
context of surface-based analysis.

My example case is the regression model where response variable is cortical 
thickness and explanatory variable is continuous (disease duration). The 
statistical linear modelling uses several principial approaches to find model 
which best describes the studied relation in the data, namely:

1. model simplification by elimination of insignificant effects
2. transformation of dependent variable to improve normality of residuals
3. transformation of explanatory variable to improve model fit or use of linear 
combination of various terms in explanatory variable (for example apart from 
linear term to include also quadratic and higher-order polynomial terms)

My question is, how to effectively exploit methods 2 and 3 in context of 
vertex-wise surface-based analysis? Could you please comment on what tools 
inside FreeSurfer framework can be used for this purpose? What is your common 
aproach to find regression model which best approximates the relation present 
in the data?

Thank you in advance for pointing me to right direction.

Regards,

Antonin Skoch

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


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

Re: [Freesurfer] Outputs from 5.3 to 6.0

[Antonin Skoch]

Dear Manuel,

I would chime in with my current experience with transfering v5.3 
reconstructions to v6.0: The wm segmentation results (and therefore white/pial 
surfaces, apart from other things) are different between versions, especially 
in ambiguous areas and especially if there is a difference in interpolation 
during conform step (in v 6.0 the cubic interpolation is off; if it is off or 
on in v5.3 it depends on whether you used patched version of recon-all or not). 
It of course also depends on the quality of your data.

In any case, my experience is, if you want to keep high quality of your 
results, you probably would need to re-inspect your data again and correct 
newly appeared errors in surfaces.

Antonin Skoch

all the edits will be taken into account regardless of what command line  args 
you use On 6/9/17 3:08 AM, Manuel Delgado wrote:
Dear all,

Regarding this issue:  
http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51931.html we 
have the same situation. We are going to reprocess data previously  processed 
with FS 5.3. If we proceed with *recon-all -all *will all the edits be taken 
into  account (i.e. skull strip, control points, wm and pial edits) or is it  
necessary to proceed with ordered steps (i.e -autorecon-pial, then  
-autorecon2-cp autorecon3, and so on)? Thanks in advance,

Manuel
___
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] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast

[Antonin Skoch]

Doug,

I tried to replicate again v5.3 results of subject 1.
I checked wm.mgz, orig.mgz, ?h.orig, ?h.pial, ?h.white and found everything 
identical (by using mri_diff and mris_diff) except FLAIR.mgz and ?h.pial (after 
FLAIRpial refinement).

The difference was small, I have traced it to the level of bbregister, namely 
to flirt.fsl.
I cannot trace the exact version of flirt used in the original data, neither 
cannot check contents of xyztrans.sch, but I suspect that this is the reason of 
difference.

My current version of flirt reads: FLIRT version 6.0.
I have uploaded the replicated subject 1 as file subj_1_v5.3_replicate_2.tar.gz 
to your server (fist upload attempt of file subj_1_v5.3_replicate_2.tar.gz was 
aborted). I have added also current xyztrans.sch.

Antonin



Doug,

did you process from scratch or did you retain edits to brainmask.mgz and 
wm.mgz?The -cubic should not be necessary, since recon-all (which I primarily 
obtained 
from https://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/5.3.0-patch/ has 
UseCubic=1 ).

I could try to replicate v5.3 again on my side.

Antonin



It is subject #1, trying to replicate in our version of 5.3 using the  
scripts/recon-all.local-copy ./recon-all.local-copy -all -FLAIRpial -s 
1.dng.v53.local-cubic -cubicThe results were close, but they were not exact



On 5/1/17 4:13 PM, Antonin Skoch wrote:
Dear Doug,

that is strange. What precisely you cannot replicate? The results with v5.3 or 
with v6.0? What subject from the group I uploaded you have tried?
I could try to run the comparison again but I have seen the results already in 
many subjects and the difference between -cubic and no cubic seems profound and 
systematic in favor of v5.3 in the aspect of wm.mgz leak ouside brain and GM/WM 
contrast.

Concerning the expert options file: Despite using flag -xopts-use in recon-all 
in v5.3, I did not use any expert option file in
the subject I have uploaded. The reason of using -xopts-use was that I was 
processing the subjects in batch where some of them had expert-options file 
with entry bbregister -init-header due to the fact that init-fsl failed in 
these subjects.
I wanted to make my life easier by processing all of them by identical 
recon-all command line parameters and added -xopts-use to all subjects (even in 
the subjects without expert option file). I supposed that this could not do any 
harm.

Antonin


I can't seem to replicate your results locally, even with the recon-all
you used. The one thing I'm missing is the expert options file. Can you
send that to me?
On 04/24/2017 12:49 PM, Antonin Skoch wrote:
> Dear Doug,
>
> the subject with leak of white surface outside brain (my first post with
> screenshots) is subject 1. Slice number (coronal) around 100.
> The subject in second post (with text below) is subject 2, slice number
> (coronal) also 100.
>
> I have processed the subjects with v 6.0 (in fact dev version from feb 2017,
> but this is irrelevant) with -cubic -no-mprage. It looks much like v5.3, i.e.
> the wm.mgz and surfaces are much better, but v5.3 looks still better, at
> least for subject 1.
> I have uploaded them as file v6.0_cubic_no_mprage.tar.gz to your ftp site.
>
> The optical difference in norm.mgz/brain.mgz between v5.3 and v6.0 with
> -cubic is very minor, but still there is some other thing which renders
> wm.mgz worse than with v5.3 for subject 1.
> The -cubic has profound effect, the images seem much smooth with lose of
> contrast without using -cubic.
>
> Regards,
>
> Antonin
>
>
> And what slice number?
> On 04/24/2017 11:16 AM, Douglas N Greve wrote:
> > Anonin, of the three subjects you sent, which one is shown in these
> > pictures?
> >
> >
> > On 04/19/2017 05:23 PM, Antonin Skoch wrote:
> >> Dear experts,
> >>
> >> I am sending just one more example to illustrate issue with white
> >> surface estimation in v6.0. See the attached screenshots: In v6.0
> >> there seems to be insufficient contrast in brain.finalsurfs.mgz, so
> >> the white surface is leaking at three spots dramatically outwards
> >> towards pial surface. The white surface in v5.3 looks much more
> >> anatomically relevant in the same spot.
> >>
> >> Could you please comment on how to avoid such issues in v.6.0?
> >>
> >> Regards,
> >>
> >> Antonin Skoch___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

Re: [Freesurfer] Skull stripping

[Antonin Skoch]

Dear John,

you can prepare expert options file with the entry:

mri_gcut -T 

and run recon-all -skullstrip -clean-bm -gcut -subjid  -expert 
expert_opts_file.txt

The mri_gcut help page reads:

-T 
set threshold to value (%) of WM intensity, the value should 
be >0 and <1; larger values would correspond to cleaner 
skull-strip but higher chance of brain erosion. Default is set
conservatively at 0.40, which provide approx. the same 
negligible level of brain erosion as 'mri_watershed'.


Antonin Skoch



Dear FS experts,
I want to inquire if there are any threshold for the flag "gcut " in the 
command:recon-all -skullstrip -clean-bm -gcut -subjid 

If this not available are there any tools that can help to control how much 
dura will be cut out

Thanks in advance!
John___
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] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast

[Antonin Skoch]

Doug,

did you process from scratch or did you retain edits to brainmask.mgz and 
wm.mgz?

The -cubic should not be necessary, since recon-all (which I primarily obtained 
from https://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/5.3.0-patch/ has 
UseCubic=1 ).

I could try to replicate v5.3 again on my side.

Antonin



It is subject #1, trying to replicate in our version of 5.3 using the  
scripts/recon-all.local-copy ./recon-all.local-copy -all -FLAIRpial -s 
1.dng.v53.local-cubic -cubicThe results were close, but they were not exact



On 5/1/17 4:13 PM, Antonin Skoch wrote:
Dear Doug,

that is strange. What precisely you cannot replicate? The results with v5.3 or 
with v6.0? What subject from the group I uploaded you have tried?
I could try to run the comparison again but I have seen the results already in 
many subjects and the difference between -cubic and no cubic seems profound and 
systematic in favor of v5.3 in the aspect of wm.mgz leak ouside brain and GM/WM 
contrast.

Concerning the expert options file: Despite using flag -xopts-use in recon-all 
in v5.3, I did not use any expert option file in
the subject I have uploaded. The reason of using -xopts-use was that I was 
processing the subjects in batch where some of them had expert-options file 
with entry bbregister -init-header due to the fact that init-fsl failed in 
these subjects.
I wanted to make my life easier by processing all of them by identical 
recon-all command line parameters and added -xopts-use to all subjects (even in 
the subjects without expert option file). I supposed that this could not do any 
harm.

Antonin


I can't seem to replicate your results locally, even with the recon-all
you used. The one thing I'm missing is the expert options file. Can you
send that to me?
On 04/24/2017 12:49 PM, Antonin Skoch wrote:
> Dear Doug,
>
> the subject with leak of white surface outside brain (my first post with
> screenshots) is subject 1. Slice number (coronal) around 100.
> The subject in second post (with text below) is subject 2, slice number
> (coronal) also 100.
>
> I have processed the subjects with v 6.0 (in fact dev version from feb 2017,
> but this is irrelevant) with -cubic -no-mprage. It looks much like v5.3, i.e.
> the wm.mgz and surfaces are much better, but v5.3 looks still better, at
> least for subject 1.
> I have uploaded them as file v6.0_cubic_no_mprage.tar.gz to your ftp site.
>
> The optical difference in norm.mgz/brain.mgz between v5.3 and v6.0 with
> -cubic is very minor, but still there is some other thing which renders
> wm.mgz worse than with v5.3 for subject 1.
> The -cubic has profound effect, the images seem much smooth with lose of
> contrast without using -cubic.
>
> Regards,
>
> Antonin
>
>
> And what slice number?
> On 04/24/2017 11:16 AM, Douglas N Greve wrote:
> > Anonin, of the three subjects you sent, which one is shown in these
> > pictures?
> >
> >
> > On 04/19/2017 05:23 PM, Antonin Skoch wrote:
> >> Dear experts,
> >>
> >> I am sending just one more example to illustrate issue with white
> >> surface estimation in v6.0. See the attached screenshots: In v6.0
> >> there seems to be insufficient contrast in brain.finalsurfs.mgz, so
> >> the white surface is leaking at three spots dramatically outwards
> >> towards pial surface. The white surface in v5.3 looks much more
> >> anatomically relevant in the same spot.
> >>
> >> Could you please comment on how to avoid such issues in v.6.0?
> >>
> >> Regards,
> >>
> >> Antonin Skoch___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

Re: [Freesurfer] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast

[Antonin Skoch]

Dear Doug,

that is strange. What precisely you cannot replicate? The results with v5.3 or 
with v6.0? What subject from the group I uploaded you have tried?
I could try to run the comparison again but I have seen the results already in 
many subjects and the difference between -cubic and no cubic seems profound and 
systematic in favor of v5.3 in the aspect of wm.mgz leak ouside brain and GM/WM 
contrast.

Concerning the expert options file: Despite using flag -xopts-use in recon-all 
in v5.3, I did not use any expert option file in 
the subject I have uploaded. The reason of using -xopts-use was that I was 
processing the subjects in batch where some of them had expert-options file 
with entry bbregister -init-header due to the fact that init-fsl failed in 
these subjects.
I wanted to make my life easier by processing all of them by identical 
recon-all command line parameters and added -xopts-use to all subjects (even in 
the subjects without expert option file). I supposed that this could not do any 
harm.

Antonin


I can't seem to replicate your results locally, even with the recon-all 
you used. The one thing I'm missing is the expert options file. Can you 
send that to me?
On 04/24/2017 12:49 PM, Antonin Skoch wrote:
> Dear Doug,
>
> the subject with leak of white surface outside brain (my first post with 
> screenshots) is subject 1. Slice number (coronal) around 100.
> The subject in second post (with text below) is subject 2, slice number 
> (coronal) also 100.
>
> I have processed the subjects with v 6.0 (in fact dev version from feb 2017, 
> but this is irrelevant) with -cubic -no-mprage. It looks much like v5.3, i.e. 
> the wm.mgz and surfaces are much better, but v5.3 looks still better, at 
> least for subject 1.
> I have uploaded them as file v6.0_cubic_no_mprage.tar.gz to your ftp site.
>
> The optical difference in norm.mgz/brain.mgz between v5.3 and v6.0 with 
> -cubic is very minor, but still there is some other thing which renders 
> wm.mgz worse than with v5.3 for subject 1.
> The -cubic has profound effect, the images seem much smooth with lose of 
> contrast without using -cubic.
>
> Regards,
>
> Antonin
>
>
> And what slice number?
> On 04/24/2017 11:16 AM, Douglas N Greve wrote:
> > Anonin, of the three subjects you sent, which one is shown in these
> > pictures?
> >
> >
> > On 04/19/2017 05:23 PM, Antonin Skoch wrote:
> >> Dear experts,
> >>
> >> I am sending just one more example to illustrate issue with white
> >> surface estimation in v6.0. See the attached screenshots: In v6.0
> >> there seems to be insufficient contrast in brain.finalsurfs.mgz, so
> >> the white surface is leaking at three spots dramatically outwards
> >> towards pial surface. The white surface in v5.3 looks much more
> >> anatomically relevant in the same spot.
> >>
> >> Could you please comment on how to avoid such issues in v.6.0?
> >>
> >> Regards,
> >>
> >> Antonin Skoch___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

Re: [Freesurfer] recon-all with error (mris_curvature -w lh.white.preaparc)

[Antonin Skoch]

Dear fwd9707,

see these threads:

http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52560.html

http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51797.html

Antonin Skoch




 Dear all 
   I performed the recon all in virtualbox (with centos 7), and there 
error and can not continue,the error information is that :#@# Curv .H and .K lh 
Sat Apr 29 21:06:24 CST 2017
/media/sf_VM_ShareFolders/Freesurfer_results/Sub_001/surf mris_curvature -w 
lh.white.preaparc 

total integrated curvature = 2.136*4pi (26.843) --> -1 handles
ICI = 184.8, FI = 2061.6, variation=32051.104
writing Gaussian curvature to ./lh.white.preaparc.K...done.
writing mean curvature to ./lh.white.preaparc.H...done.
rm -f lh.white.H
ln -s lh.white.preaparc.H lh.white.H
Linux localhost.localdomain 3.10.0-514.16.1.el7.x86_64 #1 SMP Wed Apr 12 
15:04:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

recon-all -s Sub_001 exited with ERRORS at Sat Apr 29 21:06:26 CST 2017

To report a problem, see http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
need your help ,thank you very much
___
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] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast

[Antonin Skoch]

Dear Doug,

the subject with leak of white surface outside brain (my first post with 
screenshots) is subject 1. Slice number (coronal) around 100.
The subject in second post (with text below) is subject 2, slice number 
(coronal) also 100.

I have processed the subjects with v 6.0 (in fact dev version from feb 2017, 
but this is irrelevant) with -cubic -no-mprage. It looks much like v5.3, i.e. 
the wm.mgz and surfaces are much better, but v5.3 looks still better, at least 
for subject 1. 
I have uploaded them as file v6.0_cubic_no_mprage.tar.gz to your ftp site.

The optical difference in norm.mgz/brain.mgz between v5.3 and v6.0 with -cubic 
is very minor, but still there is some other thing which renders wm.mgz worse 
than with v5.3 for subject 1.
The -cubic has profound effect, the images seem much smooth with lose of 
contrast without using -cubic.

Regards,

Antonin


And what slice number?
On 04/24/2017 11:16 AM, Douglas N Greve wrote:
> Anonin, of the three subjects you sent, which one is shown in these 
> pictures?
>
>
> On 04/19/2017 05:23 PM, Antonin Skoch wrote:
>> Dear experts,
>>
>> I am sending just one more example to illustrate issue with white 
>> surface estimation in v6.0. See the attached screenshots: In v6.0 
>> there seems to be insufficient contrast in brain.finalsurfs.mgz, so 
>> the white surface is leaking at three spots dramatically outwards 
>> towards pial surface. The white surface in v5.3 looks much more 
>> anatomically relevant in the same spot.
>>
>> Could you please comment on how to avoid such issues in v.6.0?
>>
>> Regards,
>>
>> Antonin Skoch___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

Re: [Freesurfer] volume in native space of .vtk file in mni152 space

[Antonin Skoch]

Dear Corinna,

I am not sure what is (or whether is) something wrong with your commands, but 
in any case I would be cautious of interpretation of results using such method, 
mainly from following reasons:

1.
mni152reg uses 12 DOF whole-brain registration. You cannot expect to get 
perfect alignment of subcortical regions using such crude transform. To obtain 
more precise transform, I would use either registration targeted specifically 
to subcortical regions (e.g. using first_flirt in FSL, which is, however, still 
affine only), or use mri_cvs_register.

2.
Due to no reasonable contrast within thalamus to allow to distinguish the 
nuclei using even state-of-the-art MR imaging, such registration-based atlas 
method would by necessity be a simple transfer of predefined atlas onto the 
subject space, with no information to guide the alignment within the thalamus 
itself (it would basically be a best-guiess of where these nuclei might be, 
with no scope for subject-specific refinement).

Antonin Skoch


Hi al, Just wondering if anyone has any suggestionsto my previous question 
as to why the volume from mni152 space would be rotated, even though the 
MNI152 to subject T1 alignment looks good? 
 
As a recap, here are my commands: 
 
  mni152reg --s ${subject} --1 
 
tkregister2 --mov ${subj_dir}/mri/mni152.orig.mgz --targ 
/usr/share/fsl/5.0/data/standard/MNI152_T1_1mm_brain.nii.gz --reg 
${reg_file} 
 
   mri_vol2vol --mov ${subj_dir}/mri/orig.mgz --targ 
/home/Documents/thalamus/AtlasMNI152/left-vols-1mm/global.nii.gz --reg 
${reg_file} --inv --o ${out_dir}/lh_global.nii.gz 
 
tkmedit -f subject/mri/orig.mgz -aux ${out_dir}/lh_global.nii.gz -ov 
${out_dir}/lh_global.nii.gz -fminmax .5 1 ___
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] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast

[Antonin Skoch]

Dear Bruce,

sorry for the confusion with xopts-use and recon-all editing.

I  have checked the xopts-use and the reason of this is that I run the  subject 
1 and 2 as a part of batch job on large amount of subjects,  where I rerun 
recon-all to anonymize them. Some of them had  expert-options file with 
bbregister --init-header from the initial run  (these were subjects where 
--init-fsl failed). I put -xopts-use to  invocation of all subjects (even for 
them without expert-option file) to  make my life easier. 
I did not put -cubic expert-options to any of my subjects.

Concerning  editing of my 5.3 version of recon-all: My only modification  in  
recon-all was -nsigma_above 8 for FLAIRpial and patch with .touch files  
recommended here:
http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg41284.html

Otherwise my recon-all corresponds to the 5.3.0-patch version.

It  seems that there was change in UseCubic wich 5.3.0-patch. Original  
recon-all from 5.3.0 has UseCubic=0, whereas recon-all from 5.3.0-patch  has 
UseCubic=1:

https://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/5.3.0-patch/recon-all

In my v6.0 recon-all I have UseCubic=0.

I am surprised that mere interpolation could have such profound effect ! 

I will try your suggestions and let you know.

Antonin



 From:   Bruce Fischl  
 To:   Antonin Skoch  
 Cc:
 Sent:   4/21/2017 1:00 AM 
 Subject:   Re: [Freesurfer] Worse determination of ?h.white with v6.0 in 
comparison to v5.3 - worse GM/WM contrast 

Hi Antonin

Doug points out to me that you edited your copy of recon-all in 5.3, which 
makes it really hard for me to track down any differences. For sure your 
recon-all used cubic interpolation for conforming by default, which 
introduces pretty big differences right at the start that I expect explain 
the majority of the differences in wm positioning that you are seeing. I 
guess I would suggest trying 6.0 with cubic on (-cubic) and see if they 
become more similar

cheers
Bruce





  On Thu, 20 Apr 2017, Antonin Skoch 
wrote:

> 
> Dear Bruce,
> I am uploading 3 example subjects processed both by v5.3 and v6.0 I referred
>  to in the screenshots in my previous posts:
> Subj 1 - large leak of white surface outside brain in v6.0, not present in v
> 5.3. RAS coords -53,-1,75
> Subj 2 - another measurement of identical subject - white surface is leaking
>  at three spots dramatically outwards
> towards pial surface in v6.0. RAS coords -48,-2,64
> Subj 3 - leak of white surface outside brain. Both v5.3 and v6.0 has error i
> n white surface, but the error is much larger in v6.0. RAS coords 48,5,78
> The v6.0 version is without removing -mprage. Removing -mprage in v6.0 cause
> d only very small change in brain.mgz, the filtering is still much higher th
> an in v5.3 and still causes the white matter surface leak.
> The subjects are in files mri_normalize_v5.3.tar.gz and mri_normalize_v6.0.t
> ar.gz.
> I would very welcome any suggestions how to:
> 1. Prevent new white surface errors in v6.0 in subjects previously processed
>  and edited by v5.3
> 2. How to make edits to modify white/pial surface location where wm.mgz edit
> ing is not sufficient.
> I tried workaround of directly editing 001.mgz as I discussed in thread http
> ://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52549.html
> This is very time consuming.
> Better way is maybe to consider implementation of option for mris_make_surfa
> ces similar to -overlay option for cases where wm.mgz voxels have value 1 as
>  I discussed here:
> http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52730.html
> Antonin
> Hi Antonin
> 
> yes, the -mprage flag is likely to be at least one source of the
> differences. It makes the normalization more aggressive (since mprage trades
> higher CNR for lower SNR). I'm surprised removing it didn't help. I think
> that changing things like wlo could also help depending on how wrong the
> normalization is. Upload a subject and I'll take a look
> 
> cheers
> Bruce
> 
> 
> On Thu, 20 Apr 2017, Antonin Skoch wrote:
> 
> Dear David,
> 
> thank you for the feedback; I saw your posts concerning edits and responded
> to them, see
> 
> http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52549.html
> 
> Just my case is not concerning poor response to the edits (which I believe
> is not systematically different between 5.3 and 6.0), my concern is that the
> data processed by v6.0 need much more wm.mgz edits than data processed by
> v5.3.
> 
> I think that my issue lies in -normalization2 step of recon-all. One of the
> difference between v5.3 and v6.0 is that by default the -mprage flag is
> passed to mri_normalize. This affects several parameters inside
> mri_normalize. I tried to reprocess my subjects using v6.0 with -no-mprage,
>

Re: [Freesurfer] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast

[Antonin Skoch]

Dear Bruce,

I am uploading 3 example subjects processed both by v5.3 and v6.0 I referred to 
in the screenshots in my previous posts:

Subj 1 - large leak of white surface outside brain in v6.0, not present in 
v5.3. RAS coords -53,-1,75
Subj 2 - another measurement of identical subject - white surface is leaking at 
three spots dramatically outwards
towards pial surface in v6.0. RAS coords -48,-2,64
Subj 3 - leak of white surface outside brain. Both v5.3 and v6.0 has error in 
white surface, but the error is much larger in v6.0. RAS coords 48,5,78

The v6.0 version is without removing -mprage. Removing -mprage in v6.0 caused 
only very small change in brain.mgz, the filtering is still much higher than in 
v5.3 and still causes the white matter surface leak.

The subjects are in files mri_normalize_v5.3.tar.gz and 
mri_normalize_v6.0.tar.gz.

I would very welcome any suggestions how to:

1. Prevent new white surface errors in v6.0 in subjects previously processed 
and edited by v5.3

2. How to make edits to modify white/pial surface location where wm.mgz editing 
is not sufficient.
I tried workaround of directly editing 001.mgz as I discussed in thread 
http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52549.html
This is very time consuming.
Better way is maybe to consider implementation of option for mris_make_surfaces 
similar to -overlay option for cases where wm.mgz voxels have value 1 as I 
discussed here:
http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52730.html

Antonin


Hi Antonin

yes, the -mprage flag is likely to be at least one source of the  differences. 
It makes the normalization more aggressive (since mprage  trades higher CNR for 
lower SNR). I'm surprised removing it didn't help. I  think that changing 
things like wlo could also help depending on how wrong  the normalization is. 
Upload a subject and I'll take a look cheers
Bruce


On Thu, 20 Apr 2017,  Antonin Skoch wrote: Dear David,

thank you for the feedback; I saw your posts concerning edits and responded
to them, see

http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52549.html

Just my case is not concerning poor response to the edits (which I believe
is not systematically different between 5.3 and 6.0), my concern is that the
data processed by v6.0 need much more wm.mgz edits than data processed by
v5.3.

I think that my issue lies in -normalization2 step of recon-all. One of the
difference between v5.3 and v6.0 is that by default the -mprage flag is
passed to mri_normalize. This affects several parameters inside
mri_normalize. I tried to reprocess my subjects using v6.0 with -no-mprage,
but unfortunately this did not help.

See the example screenshots processed by v5.3 and v6.0 with -no-mprage:

The brain.mgz is still more aggressively filtered in v6.0 and there is much
more prominent leak of ?h.white outside brain, which is probably caused by
extended filtration which affects GM/WM contrast.

Looking at the source code of mri_normalize.c I did not comprehend where the
basis of the issue lies, but in any case there are big differences in
mri_normalize.c code between versions.

Antonin

From: David Semanek 
To: Antonin Skoch , "freesurfer@nmr.mgh.harvard.edu"

Sent: 4/20/2017 3:41 PM
Subject: Re: [Freesurfer] Worse determination of ?h.white with v6.0 in
comparison to v5.3 - worse GM/WM contrast

  Agreed. A validated protocol run on a very large group of
  subjects in 5.3 was attempted with similar data in 6.0 and not
  only was the longitudinal edit stream nearly non-functional for
  white matter edits, cross edit performance was disappointing.

   

  I am currently waiting on a response to these potential issues
  before pursuing further work with 6.0.

   

  Best,

   

  David P. Semanek, HCISPP

  Research Technician, Posner Lab

  Division of Child and Adolescent Psychiatry

  Columbia University Medical Center

  New York State Psychiatric Institute

  1051 Riverside Drive, Pardes Bldg. Rm. 2424

  New York, NY 10032

  PH: (646) 774-5885

   

IMPORTANT NOTICE:  This e-mail is meant only for the use of the
intended recipient.  It may contain confidential information which is
legally privileged or otherwise protected by law.  If you received
this e-mail in error or from someone who was not authorized to send it
to you, you are strictly prohibited from reviewing, using,
disseminating, distributing or copying the e-mail.  PLEASE NOTIFY US
IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS MESSAGE FROM
YOUR SYSTEM.  Thank you for your cooperation.

 

From: Antonin Skoch 
Date: Wednesday, April 19, 2017 at 5:23 PM
To: 
Subject: [Freesurfer] Worse determination of ?h.white with v6.0 in
comparison to v5.3 - worse GM/WM contrast

 

Dear experts,

I am sending just one more example to illustrate issue with white
surface estimation in v6.0. See the attached screenshots: 

Re: [Freesurfer] Control point in WM regions

[Antonin Skoch]

Dear Shane,

could you please post screenshots of ?h.orig.nofix and ?h.orig in the 
problematic regions?

Antonin Skoch


Hello Freesurfer Team, 
I am trying to recover thin WM strands in the temporal lobe by using control 
points but to no avail (screenshot) 
 
 
Any suggestions please? These regions also appear to be classified  as WM 
(wm.mgz) but why are the surfaces inaccurate? Thanks for your  help. 
 
Best Wishes,Shane ___
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] Freeview - corrupted pixel values after saving volume (via save as) when images with mutually different geometry are simultaneously loaded

[Antonin Skoch]

Dear Ruopeng,

thank you for the feedback. Yes, the behavior is exacly like you described. I 
suspected that this has something to do with resampling but I was not sure.
The stripes were result of nearest-neighbor interpolation.

Antonin


Hi Antonin,

When you load two images like that, the second image will be resampled,  using 
nearest neighbor method by default. And when you save, it will be  resampled 
back to its original space. So there will be shifted voxels  depending how 
oblique it is to the first image. So I think what you  observe makes sense. 
That is also why you should always edit volumes in  their local space. I didn't 
find any screenshots in your last email but my guess is the  oblique strip is 
due to nearest neighbor resampling. You can choose  "-trilinear" or "-cubic" in 
the command line when you load the images. Best,
Ruopeng

On 04/13/2017 12:28 PM, Antonin Skoch wrote:
Dear experts,

I encountered following issue with freeview:

When two images with mutually different geometry are simultaneously  loaded and 
one of them is saved (via save as), its pixel values get  somewhat corrupted. 
There are strips in image with modified pixel  values. It seems to affect only 
the latter image in the pair. Example (001.mgz and brainmask.mgz have different 
geometry):

freeview brainmask.mgz orig/001.mgz

Then I saved 001.mgz as 001_2.mgz (using "save as") and loaded  001_2.mgz to 
freeview. The attached screenshots show original 001.mgz  and 001_2.mgz with 
corrupted pixels. Note new oblique strips. This is not only display issue. The 
mri_diff 001.mgz 001_2.mgz outputs:

diffcount 287447
Volumes differ in pixel data
maxdiff 966. at 171 255 30 0

I am using recent development version of freesurfer from 04/2017.

Regards,

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


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

Re: [Freesurfer] Fwd: wm edits not incorporated

[Antonin Skoch]

Dear Octavian,

the current philosophy with wm.mgz edits is not to directly affect voxel values 
in original T1 image.

The wm.mgz serves as starting point for the white surface estimation. The 
?h.white surface is estimated according gradient in voxel values in 
brain.finalsurfs.mgz (which is, basically, preprocessed T1 image) using 
basically preprocessed surfaces obtained from wm.mgz (?h.orig) as a starting 
position where to search for intensity gradient.
The editing of wm.mgz helps to find out the GM/WM itensity gradient and 
properly place ?h.white there.
Therefore, where there is insufficient GM/WM contrast, the wm.mgz cannot help 
out. I think that there is no change in the behavior between v5.3 and v6.0 in 
this aspect. I have seen many cases where wm.mgz edit does not help to improve 
?h.white surfaces in the data processed by v5.3. 

There is an -overlay option in mris_make_surfaces which explicitly modifies 
voxel values in input image for mris_make_surfaces (brain.finalsurfs.mgz as 
default in recon-all). However, this option only works for cases when wm.mgz is 
extended, not deleted: 
In voxels which have value 255 in wm.mgz, it replaces current voxel value in 
input image by desired value of white matter. This option is currently not used 
in recon-all. 
I would opt for implementation of similar option for deletion of voxels in 
wm.mgz: Where wm.mgz voxel values equal 1, to replace input image voxel values 
by desired values of GRAY matter. This should force ?h.white to directly follow 
edits of wm.mgz

As for editing of 001.mgz, beware the pitfall with editing images with mutually 
different geometry in FreeView I posted today:

http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52729.html

Antonin Skoch


Dear All,

Regarding wm.mgz edits not incorporated into wm surface, which seems to
have been reported on by several of us with FS 6.00. I followed Antonin's
idea of editing 001.mgz by switching wm-intensity voxels clearly not wm
(mostly in the subtemporal regions, at times close to bright dural portions
in the crown) to gm intensities and ran recon-all -all, and this time all
was OK. So it seems that the problem is that on re-initializing during
-autorecon2-wm rerun, the routine does not edit out high intensity voxels
even if manually excluded in wm.mgz. This seems to be different to some
extent with how FS 5.3 was reacting, although I did not look at this
systematically. There may be a reason that manual editing is just part of
the story during rerun and does not automatically override the recon
stream, but I do not know it.
Octavian


-- Forwarded message --
From: Octavian Lie 
Date: Sun, Apr 2, 2017 at 7:59 PM
Subject: wm edits not incorporated
To: octavian lie 



Dear Bruce,

I just transferred subject r02.tar.gz.

Again, wm.mgz edits (all deleted voxels, no additions) are not incorporated
on reruns using any of the
recon-all -autorecon-wm -aitorecon3
recon-all -autorecon2 -autorecon3
recon-all -make all

FOr example, the complete command line for  a rerun is

recon-all -autorecon2-wm -autorecon3 -3T -bigventricles -cw256 -subjid r02
-parallel > output.txt &


Here are some of the edited voxels which are not excluded from the wm on
rerun:


-40.14, -2.67, 116.29 coronal slice 132
12.73, -23.67, 126.16 coronal slice 171
14.05, 12.33, 11.61 coronal slice 147___
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] manual edits

[Antonin Skoch]

Dear John, David,

To great summarization of David, I would add following:

My personal preference is to run whole -autorecon2 -autorecon3 after editing of 
the brainmask.mgz. 
Early stages of -autorecon2 (normalization, registration, volumetric labeling) 
use brainmask.mgz, therefore I believe that their results can be improved when 
improved brainmask.mgz is provided (especially when the edits of the 
brainmask.mgz are of large extent).

When the pial surface extends to the cerebellum, different edits are needed as 
specified here:

http://freesurfer.net/fswiki/FsTutorial/PialEdits_freeview

Antonin Skoch



Hi David,
Thank you for the feedback! I followed your advice's and everything has been 
resolved. Highly appreciated!Cheers,
John

Sent with [ProtonMail](https://protonmail.com) Secure Email.

 Original Message 
Subject: Re: [Freesurfer] manual edits
Local Time: April 12, 2017 11:04 AM
UTC Time: April 12, 2017 3:04 PM
From: seman...@nyspi.columbia.edu
To: John Anderson , freesurfer@nmr.mgh.harvard.edu 


Hi John,

Yes understanding how freesurfer deals with edits can be a bit confusing. I 
have a lot of experience doing edits to the wm.mgz and brainmask.mgz for cross 
sectional data in Freesurfer 5.3 so perhaps I can help.

Recon-all is basically a script which runs a series of about 25 or so 
processing steps in a defined sequence. The software generally will be able to 
recognize when an edit has been done at a particular intervention point and 
will take those edits into account when running that step unless you 
specifically instruct it not to.

The most common types of edits are edits to the wm.mgz to fix white matter 
defects and tissue incorrectly identified as white matter, and edits to the 
brainmask.mgz to fix cases where the skull strip is insufficient to prevent 
dura and other non-cortical tissue from making it into the gray matter/pial 
surfaces. White matter edits need to be done directly on the wm.mgz and gray 
matter/skull strip edits need to be done on the brainmask.mgz. Editing those 
two files and saving them directly in freeview is sufficient to register those 
edits for recon-all.

If you have edited only the brainmask.mgz, it is sufficient to run 
–autorecon-pial since the white matter surfaces will not need to be 
regenerated. If you have edited the wm.mgz, you must run –autorecon2-wm (or 
–autorecon2-cp if you used control points as well as white matter edits). If 
you have edited both the brainmask.mgz and the wm.mgz, then you only need to 
run –autorecon2-wm since the pial surfaces will be regenerated taking into 
account the brainmask.mgz edits as part of that workflow. Keep in mind that you 
still need to run –autorecon3 to complete the reprocessing of these data 
(-autorecon-pial includes the steps from –autorecon3) but that can be done when 
you are happy with your final surfaces if you want to save processing time on 
iterative edits.

Here is the wiki page referring to edits: 
https://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/TroubleshootingData

I hope this is helpful.

Best,

David P. Semanek, HCISPP

Research Technician, Posner Lab

Division of Child and Adolescent Psychiatry

Columbia University Medical Center

New York State Psychiatric Institute

1051 Riverside Drive, Pardes Bldg. Rm. 2424

New York, NY 10032

PH: (646) 774-5885

IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
recipient. It may contain confidential information which is legally privileged 
or otherwise protected by law. If you received this e-mail in error or from 
someone who was not authorized to send it to you, you are strictly prohibited 
from reviewing, using, disseminating, distributing or copying the e-mail. 
PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS 
MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.

From:  John Anderson 
Reply-To: John Anderson 
Date: Wednesday, April 12, 2017 at 6:45 AM
To: "freesurfer@nmr.mgh.harvard.edu" 
Subject: [Freesurfer] manual edits

Dear Freesurfer experts,

I am not an expert in manual edits, so I highly appreciate any feedback 
regarding the issues in my questions below. I ran the following command line 
“recon-all -s subjid -all” on T1 image for one of the subjects. when reviewing 
the output images (i.e. wm.mgz, brainmask.mgz) I found issues as attached.

Attached is an output of the command: "Freeveiw orig.mgz wmparc.mgz wm.mgz"

1. When I reviewed “wm.mgz” I see interactions between the white matter (wm), 
and the cortex (yellow arrows). To fix this, I edited “wm.mgz” by removing the 
wm voxels from the cortex, and the data was saved in the file “wm.seg.mgz”

2. I found many holes in many slices similar to the (black arrow). I filled all 
these holes. The data saved in “wm.seg.mgz”

3. I fixed some issues related to dura and bad skullstipping

Then I ran the command:

“recon-all -autorecon2-wm -autorecon3 -subjid ” which output the file 
“brain

[Freesurfer] Freeview - corrupted pixel values after saving volume (via save as) when images with mutually different geometry are simultaneously loaded

[Antonin Skoch]

Dear experts,

I encountered following issue with freeview: 

When two images with mutually different geometry are simultaneously loaded and 
one of them is saved (via save as), its pixel values get somewhat corrupted. 
There are strips in image with modified pixel values. It seems to affect only 
the latter image in the pair.

Example (001.mgz and brainmask.mgz have different geometry):

freeview brainmask.mgz orig/001.mgz

Then I saved 001.mgz as 001_2.mgz (using "save as") and loaded 001_2.mgz to 
freeview. The attached screenshots show original 001.mgz and 001_2.mgz with 
corrupted pixels. Note new oblique strips.

This is not only display issue. The mri_diff 001.mgz 001_2.mgz outputs:

diffcount 287447
Volumes differ in pixel data
maxdiff 966. at 171 255 30 0

I am using recent development version of freesurfer from 04/2017.

Regards,

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


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

Re: [Freesurfer] -autorecon2-wm: Inconsistency between recon-all code and documentation

[Antonin Skoch]

Dear Doug,

do you think that it is necessary/useful to rerun

-normalization2
-maskbfs
-segmentation

steps after wm.mgz have been edited (that is what the -autorecon2-wm is used 
for I suppose)? The wm.mgz is not used in this steps as far as I can tell. 

In contrast, it seems to me that the documentation is more close to the optimum 
(the three steps: normalization, mask and segmentation steps are run only when 
it is needed - in -autorecon2-cp, not in -autorecon2-wm).

Antonin


I think the stages in the command line help are out of date
On 04/08/2017 05:58 PM, Antonin Skoch wrote:
> Dear experts,
>
> I noticed inconsistency between recon-all -help and actual code of 
> recon-all in -autorecon2-wm option.
> According to the recon-all --help the -autorecon2-wm processes stages 
> 15-23 (fill through make white surfaces) and -autorecon2-cp processes 
> stages 12-23 (normalization2 throuhgh make white surfaces). But, in 
> the code both -autorecon2-wm and -autorecon2-cp are equivalently 
> processing stages 12-23.
>
> It seems to me that the stages 12-14 are not needed to process again 
> in -autorecon2-wm (which is used for re-processing after editing wm.mgz).
>
> Could you please comment on?
>
> Regards,
>
> Antonin Skoch___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

[Freesurfer] -autorecon2-wm: Inconsistency between recon-all code and documentation

[Antonin Skoch]

Dear experts,

I noticed inconsistency between recon-all -help and actual code of recon-all in 
-autorecon2-wm option.
According to the recon-all --help the -autorecon2-wm processes stages 15-23 
(fill through make white surfaces) and -autorecon2-cp processes stages 12-23 
(normalization2 throuhgh make white surfaces). But, in the code both 
-autorecon2-wm and -autorecon2-cp are equivalently processing stages 12-23. 

It seems to me that the stages 12-14 are not needed to process again in 
-autorecon2-wm (which is used for re-processing after editing wm.mgz).

Could you please comment on? 

Regards,

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


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

Re: [Freesurfer] Fwd: recon-all error

[Antonin Skoch]

Dear Patricia,

this is I suppose the last issue concerning symbolic links, related with part 
of code starting with following comment:

 # if fsaverage is not in subjects dir, put it there

I think that the most straightforward  solution of this issue is to manually 
copy the fsaverage subject to $SUBJECTS_DIR before invocation of recon-all. 

Antonin



forgot to attach the printscreen 
 
2017-04-06 9:49 GMT+02:00 Patr?cia Klobu?iakov? < 
patricia.klobusiak...@gmail.com>: 
 
> Hi Antonin, 
> 
> I edited recon-all file, but another error was reported. This error 
> concerns symbolic links, too. Is there any way I could make it work on this 
> virtual machine? I coud try to substitute all ln commands with cp or 
> something like that. 
> 
> Thanks. 
> 
> Patricia 
> 
> 2017-04-04 13:43 GMT+02:00 Antonin Skoch : 
> 
>> Dear Patricia, 
>> 
>> see this thread: 
>> 
>> freesurfer@nmr.mgh.harvard.edu/msg51797.html" 
>> title="http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51797.html";
>>  
>> target="_blank">http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51797.html
>>  
>> 
>> Your working directory probably resides on the filesystem which does not 
>> support symbolic links. You probably could workaround this by editing your 
>> recon-all and replace line 
>> 
>> set cmd2 = (ln -s $hemi.white.preaparc.$suffix $hemi.white.$suffix) 
>> by 
>> 
>> set cmd2 = (cp $hemi.white.preaparc.$suffix $hemi.white.$suffix) 
>> 
>> Antonin Skoch 
>> 
>> 
>> 
>> Hello FreeSurfer Developers,  I have installed Freesurfer on Windows 
>> using VMware - CentOS 64-bit (the one from FSLuser Linux installation). 
>>  Everytime I run recon-all, there is an error. 
>>  The same error occurs  when I try to rum mri2mesh command in SIMNIBS 
>> toolbox which uses Fresurfer (recon-all), too. I'm sending screenshots and 
>> logfile attached. 
>>   Version: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0-2beb96c 
>> uname -a: Linux fslvm6.localdomain 2.6.32-431.5.1.el6.x86_64          #1 
>> SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux 
>>  Thanks for your help. 
>> 
>>  Best,  Patricia ___
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.mgz Edits Ignored With Current Dataset in FS 5.3/6 Cross and Long Streams

[Antonin Skoch]

Dear David,

I did not see your data, but maybe couple of relevant remarks could be useful:

1.
By default the wm.mgz edits are not propagated from cross to the base, but from 
the cross to long. And surfaces in long are initialized from the base. 
Therefore the wm.mgz has to be OK both in the cross and in the base. My view 
and current experience is, that this means that in many cases it is probably 
necessary to edit wm.mgz both in cross and base. This would explain your 
observation that the wm.mgz edits in cross are not propagated to the base and 
the edits in base (but not in cross) are not seen in the long. 

I implemented a custom script which transfers  INTERSECTION of the wm.mgz edits 
from all cross points to the base. I think that to transfer the intersection of 
edits is safe approach to prevent to introduce errors in wm.mgz in base due to 
the false propagation of wm.mgz edits from cross to base in case of significant 
changes in the anatomy between cross and base. My  preliminary testing shows 
that this approach works well and saves time in wm.mgz editing of large errors 
which are consistently present in all timepoints. But in case of significant 
errors, the wm.mgz in the base still needs some additional editing. Therefore I 
think that there is not any single intervention point in wm.mgz edits.

 I was discussing the approach of transferring wm.mgz edits with Martin Reuter 
in the following thread:

http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51092.html

2.
When there are spots in the cross, where wm.mgz edits do not take an effect, I 
would suggest to inspect the brain.finalsurfs.mgz to see if there is sufficient 
contrast of the white/gray matter. In many such cases where I observe my wm.mgz 
edits do not take an effect, there is local issue with insufficient white/gray 
matter contrast. The white surface placement is primarily driven by the local 
gradient of intensity in brain.finalsurfs.mgz, the boundaries/edits of wm.mgz 
play only supplementary role (as an starting point for gradient search, via 
?h.orig, at least in default invocation of mris_make_surfaces, AFAIK).

If I have enough clues where the white surface should lie (i.e. from FLAIR) and 
there is insufficient white/gray matter contrast (typically there are spots in 
gray matter with spuriously high signal intensity, similar to white matter), I 
am currently experimenting with workaround, by directly editing gray matter 
voxels of 001.mgz in problematic spots by setting their values to typical gray 
matter values to enforce better white surface placement.
I decided to place my edits just in the beginning to the recon-all stream 
(001.mgz) to ensure the edits are not overwritten in case of new recon-all 
rerun.

Maybe other experts could comment on my workaround approach, it would also help 
me out.

Regards,

Antonin Skoch



I believe what I am seeing in the long stream is the edits not properly taking 
effect.I uploaded a subject with two timepoints, and only baseline edits to the 
wm as 
dsemanek2.zip about a week and a half ago. There doesn’t seem to be any 
significant changes to the surfaces in the base or either of the long runs. I 
will redo this subject on my end with some more extreme edits for testing to 
see if I can “force” something.

Thanks again for looking,

David P. Semanek, HCISPP
Research Technician, Posner Lab
Division of Child and Adolescent Psychiatry
Columbia University Medical Center
New York State Psychiatric Institute
1051 Riverside Drive, Pardes Bldg. Rm. 2424
New York, NY 10032
PH: (646) 774-5885

IMPORTANT NOTICE:  This e-mail is meant only for the use of the intended 
recipient.  It may contain confidential information which is legally privileged 
or otherwise protected by law.  If you received this e-mail in error or from 
someone who was not authorized to send it to you, you are strictly prohibited 
from reviewing, using, disseminating, distributing or copying the e-mail.  
PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS 
MESSAGE FROM YOUR SYSTEM.  Thank you for your cooperation.

From: Martin Reuter 
Date: Wednesday, April 5, 2017 at 2:19 AM
To: David Semanek 
Cc: "freesurfer@nmr.mgh.harvard.edu" , "Hoopes, 
Andrew" 
Subject: Re: [Freesurfer] wm.mgz Edits Ignored With Current Dataset in FS 5.3/6 
Cross and Long Streams

Hi David,

so edits are affecting the surfaces in cross, just not as much as you would 
like. We need to check if there is a problem there.

For the longitudinal stream, edits in the base should affect surfaces in the 
base, which in turn will affect surfaces in the long. In long, surfaces would 
start from a better starting position. Furthermore, wm edits from cross should 
be propagated to long, to make sure that surfaces don’t move back to the wrong 
position. So far the theory.
If you don’t see any effect of WM edits (in the base) on surfaces (in the base) 
then there is a problem. This step should be ba

Re: [Freesurfer] mri_watershed seed point

[Antonin Skoch]

Dear Kristen,

looking at the source code of mri_watershed, the seed point has to be specified 
in the format:
-s i j k

and the option can be specified more than once when you want to add more seed 
points (30 seed points is maximum).

i.e., when you want to input seed points in coordinates 50,60,70, and 
80,90,100, the option would be:
-s 50 60 70 -s 80 90 100

Regards,

Antonin Skoch



Hello FreeSurfer Community,

I am attempting to use mri_watershed to create BEM surfaces, but for some of my 
subjects part of the cerebellum is being cut off.  Adjusting the threshold was 
not sufficient, so I attempted to add a seed point in the cerebellum using the 
following command:mri_watershed -atlas -useSRAS -surf ./surfout -s [105 182 81] 
./T1.mgz 
./brainvol

The coordinates for the seed point are from the T1.mgz image.  I reran 
mri_watershed and the seed point does not seem to be taken into consideration 
so I'm thinking that the input format I used may be wrong.  Could someone 
please tell me if I am not using the proper input format?  And what format to 
use if I wish to add multiple seed points?  Command output is attached.

Thanks in advance!

Kristen___
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] Fwd: recon-all error

[Antonin Skoch]

Dear Patricia,

see this thread:

http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51797.html

Your working directory probably resides on the filesystem which does not 
support symbolic links. You probably could workaround this by editing your 
recon-all and replace line

set cmd2 = (ln -s $hemi.white.preaparc.$suffix $hemi.white.$suffix)
by

set cmd2 = (cp $hemi.white.preaparc.$suffix $hemi.white.$suffix)

Antonin Skoch


Hello FreeSurfer Developers,  I have installed Freesurfer on Windows using 
VMware - CentOS 64-bit (the one from FSLuser Linux installation). 
 Everytime I run recon-all, there is an error.
 The same error occurs  when I try to rum mri2mesh command in SIMNIBS toolbox 
which uses Fresurfer (recon-all), too. I'm sending screenshots and logfile 
attached.
  Version: freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0-2beb96c  uname -a: 
Linux fslvm6.localdomain 2.6.32-431.5.1.el6.x86_64  #1 SMP Wed Feb 12 
00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux 
 Thanks for your help. 

 Best,  Patricia 

___
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] different filtering of brainmask.mgz in v5.3 and v6.0 - is it an issue to keep brainmask.mgz from v5.3?

[Antonin Skoch]

Dear experts,

I am reprocessing a group of subjects originally processed and edited in v5.3, 
by version v6.0. Due to the fact that some subjects had brainmask.mgz edited, I 
kept the brainmask.mgz from v5.3 to save time in editing (i.e. did not use 
-clean-bm in recon-all -all). I noticed that the brainmask.auto.mgz (from v6.0) 
is more aggresively  filtered than brainmask.mgz (from v5.3) in basal ganglia 
(they have intensity 110 in v6.0 in contrast  to v5.3) and also generally in 
white matter (much more voxels are 110 in  v6.0 than in v5.3). 
Is it an issue? As I looked to the recon-all stream, the brainmask.mgz is in 
fact probably used only as mask for mri_em_register, mri_ca_normalize, 
mri_ca_register and mri_normalize, so the voxel intensities does not matter. 
Could you confirm that?
Does it pose a problem to mix the subjects with brainmask.mgz created in v5.3 
(and edited) with new subjects processed from scratch by v6.0?

I considered to create v6.0 brainmask.mgz while keeping edits by remasking v6.0 
T1.mgz by v5.3 brainmask.mgz using mri_mask T1.mgz brainmask_v5.3.mgz 
brainmask.mgz -keep_mask_deletion_edits
but I do not know whether this is in fact necessary. Could you please comment 
on?

Regards,

Antonin Skoch

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


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

Re: [Freesurfer] wm.mgz Edits Ignored With Current Dataset in FS 5.3/6 Cross and Long Streams

[Antonin Skoch]

Dear David,

did you use

-uselongbasewmedits

in your recon-all -long run?

If this flag is not used, the wm edits are transfered to long from cross, not 
from the base.

Regards,

Antonin Skoch



Andrew, thanks for your response. I am still not seeing the white matter edit 
performance that I am expecting, or that I have seen from using the cross 
stream on 5.3 in the past with a different dataset.I started with a new subject 
with two timepoints. I ran recon-all on both for 
the cross stream with no edits, and then ran the base. I edited the wm.mgz for 
the base, then ran “recon-all –autorecon2-wm –autorecon3 –base xx_base –tp 
xx_t1 –tp xx_t2”. I noticed the surfaces didn’t really change in the base, but 
I went ahead and ran the two long runs using “recon-all –all –long xx_tx 
xx_base” and although there are minor differences in the base and time point 
surfaces, the white matter edits I did on the base were largely ignored, and 
none of them were included in the time point long run wm.mgz files.

I am tempted to try these same analyses using Linux (I am running this on OSX 
10.11 currently), as I experienced a completely different response from the 
surface generation modules to my edits in the past when using Linux. I’m 
thinking this is a real long shot, but I cannot otherwise figure out why the 
software would be behaving so differently from my past experiences.

Any thoughts? Thanks!

Best,

David P. Semanek, HCISPP
Research Technician, Posner Lab
Division of Child and Adolescent Psychiatry
Columbia University Medical Center
New York State Psychiatric Institute
1051 Riverside Drive, Pardes Bldg. Rm. 2424
New York, NY 10032
PH: (646) 774-5885

IMPORTANT NOTICE:  This e-mail is meant only for the use of the intended 
recipient.  It may contain confidential information which is legally privileged 
or otherwise protected by law.  If you received this e-mail in error or from 
someone who was not authorized to send it to you, you are strictly prohibited 
from reviewing, using, disseminating, distributing or copying the e-mail.  
PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS 
MESSAGE FROM YOUR SYSTEM.  Thank you for your cooperation.

From: "Hoopes, Andrew" 
Date: Wednesday, March 15, 2017 at 12:47 PM
To: Freesurfer support list , David Semanek 

Cc: Bruce Fischl 
Subject: Re: [Freesurfer] wm.mgz Edits Ignored With Current Dataset in FS 5.3/6 
Cross and Long Streams


Hi David



Try editing the base wm.mgz first instead of editing the long and cross wm 
files. Rerun autorecon2-wm and autorecon3 for the base dir, then completely 
rerun the longitudinals. The long surfaces are initialized from the base 
surfaces, so this could be why your wm fixes seem to have no effect.

You can find more info here:

https://surfer.nmr.mgh.harvard.edu/fswiki/LongitudinalEdits#CheatSheet<https://surfer.nmr.mgh.harvard.edu/fswiki/LongitudinalEdits>

If editing the base doesn't solve the problem, you can send me the commands you 
ran in order and I can look into this further.

best,
Andrew


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of David Semanek 

Sent: Monday, March 13, 2017 11:55 AM
To: Bruce Fischl; Freesurfer support list
Subject: Re: [Freesurfer] wm.mgz Edits Ignored With Current Dataset in FS 5.3/6 
Cross and Long Streams

Thanks, I have uploaded the cross and long stream processing from one subject 
which requires numerous white matter edits to correct defects in the white 
matter surfaces; the file is on the ftp server as dsemanek.zip.

Both of the cross subject folders, s02_t1 and s02_t2 have had edits done to 
both the brainmask as well as the wm files, and autorecon2-wm and autorecon-3 
have been run on them, as well as the long folder for the first time point, 
s02_t1.long.s02_base.

It was in working with the rerun results of s02_t1.long.s02_base that I noticed 
the white matter surfaces after being regenerated with the edited wm.mgz did 
not reflect any of the edits. The easiest way to see this is to load the wm.mgz 
with the white matter surfaces and scroll through the slices, there are 
numerous areas where the contours of the white matter surfaces do not follow 
the voxels of the wm.mgz volume, mostly near what should be identified as 
hyperintense gray matter. I’m fairly certain the white matter surfaces didn’t 
change at all after running autorecon2-wm with the wm.mgz edits.

Thanks for taking a look at our data.

Best,

David P. Semanek, HCISPP
Research Technician, Posner Lab
Division of Child and Adolescent Psychiatry
Columbia University Medical Center
New York State Psychiatric Institute
1051 Riverside Drive, Pardes Bldg. Rm. 2424
New York, NY 10032
PH: (646) 774-5885

IMPORTANT NOTICE:  This e-mail is meant only for the use of the intended 
recipient.  It may contain confidential information which is legally privileged 
or otherwise protected by law.  If you received this e-mail in error or from

Re: [Freesurfer] Can we use fressurfer 6 with the Human connectome project's pipeline ?

[Antonin Skoch]

Dear Doug,

I have uploaded 3 subjects with 0.7mm3 data so that you can take a look:
None of the subjects has macroscopical pathological changes, the juxtacortical 
hypointensities should be physiological finding.

1.
example_subject_0.7mm.tar.gz

This is subject processed by recon-all -all -T2pial -hires processed by dev 
version from 07/02/2017.

In this subject you can see the cutting of the pial surface in the midline (due 
to the wrong aseg labeling to contralateral gray matter) at the RAS coords

2,-70,17

and juxtacortical hypointensity affecting pial/white surface in 

7,29,43

2.
juxtacortical_hypointensities_0.7mm_HCP_pipeline.tar.gz

This is subject processed by HCP pipeline with quite large amount of 
juxtacortical hypointensities largely affecting pial/white surfaces, located 
for example at the RAS coords:

11,-64,54
15,-48,48

White surface produced by standard recon-all -hires -white is the file 
?h.white.prehires.

3.
test_first_wm_peak_HCP_pipeline_base.tar.gz

This is subject processed by HCP pipeline with combination with 2nd step of 
longitudinal stream (-base). 
In this subject I tested -first_wm_peak behavior (option for mris_make_surfaces 
used in FreeSurferHiResWhite.sh in HCP pipeline).  There has been change of 
implementation of -first_wm_peak in the December 2016. It seems that the recent 
implementation of -first_wm_peak positions the white surface too internally as 
I commented on here:

http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51414.html

White surface produced by standard recon-all -hires -white is the file 
?h.white.prehires.

Additionally, there are files
 lh.white.deformed_ver_201611  - file produced by using -first_wm_peak 
(original version before code change)
 lh.white.deformed_ver_201701 - file produced by using -first_wm_peak (version 
after code change with white surfaces positioned very internally, I consider it 
not anatomically relevant)
 lh.white.deformed_ver_201701_wo_first_wm_peak - file produced without using 
-first_wm_peak.

Thank you for your time and looking forward to your comments!

Regards,

Antonin



Hi Antonin, can you upload that subject? In one case using 700um, the  white 
surface looked fine, and I did not see much of a difference with  the 1mm scan. 
On 3/14/17 5:39 AM, Antonin Skoch wrote:
Dear experts,

can also be the difference between v5.3 and v6.0 behavior in HCP  pipeline and 
possible sub-optimal behavior of v6.0 with HCP pipeline  given by different in 
image input to mris_make_surfaces in HCP  pipeline (FreeSurferHiResWhite.sh) ? 
For white surface estimation the recon-all input is brain.finalsurfs,  which is 
very aggressively filtered so that the white matter voxels  have typically 
values 110 and the SNR in deep white matter areas  approach infinity. In 
contrast, for HCP pipeline the input  T1w_hires_masked_norm image is filtered 
no to such an extent.  Therefore there is much lower contrast-to-noise ratio in 
the region of  GM-WM interface for mris_make_surfaces in 
FreSurferHiResWhite.sh. This  maybe renders mris_make_surface more vulnerable 
to local deviations in  intensity in GM-WM interface. My observation (without 
any thorougful tests) is that with v6.0 in HCP  pipeline I had very often to 
edit wm.mgz in the region of GM-WM  interface in the areas of (physiological) 
perivascular subcortical T1  hypointensities due to the ?h.white "leak" to 
these areas. And also, as I wrote in some of my previous (unanswered) posts:

http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51414.html

the change of -first_wm_peak behaviour in v6.0 in fact worsened white  surface 
estimation in my data I tested with HCP pipelines. I could upload some example 
subjects if you are interested and have  time to dig in. In any case, it is 
probably hard to compare performance between  standard recon-all and HCP 
pipeline and different versions of  FreeSurfer due to different input to 
mris_make_surfaces and different  flags used. The HCP pipeline, as it currently 
stands, would probably  need different optimization of code or different 
command line options  due to the different input used. Regards,

Antonin Skoch



Hi Bruce,

I don¹t think the hires T1w and T2w stuff are as accurate as 5.3 in the
HCP 0.7mm data that I have looked at (and as I recall at least one other
user had some similar issues, as did one of my collaborators), but that
was all I meant to refer to.  Sorry if my reply came across more general
than that, as of course we want to move to using FreeSurfer V6+ in the
future.  It is the highres T1w and T2w stuff that my pipelines are
designed to exploit, however.  Also there are some changes I have to make
to the HCP Pipelines for FreeSurfer V6+ because of differing file names,
etc.
Best,

Matt.

On 3/13/17, 9:40 PM, "Bruce Fischl"
 wrote:

>Hi Matt
>
>To state without qualification that "6.0 has some regressions as far as
>surface placement" is incorrect. 

Re: [Freesurfer] Can we use fressurfer 6 with the Human connectome project's pipeline ?

[Antonin Skoch]

Dear experts,

can also be the difference between v5.3 and v6.0 behavior in HCP pipeline and 
possible sub-optimal behavior of v6.0 with HCP pipeline given by different in 
image input to mris_make_surfaces in HCP pipeline (FreeSurferHiResWhite.sh) ?

For white surface estimation the recon-all input is brain.finalsurfs, which is 
very aggressively filtered so that the white matter voxels have typically 
values 110 and the SNR in deep white matter areas approach infinity. In 
contrast, for HCP pipeline the input T1w_hires_masked_norm image is filtered no 
to such an extent. Therefore there is much lower contrast-to-noise ratio in the 
region of GM-WM interface for mris_make_surfaces in FreSurferHiResWhite.sh. 
This maybe renders mris_make_surface more vulnerable to local deviations in 
intensity in GM-WM interface. 

My observation (without any thorougful tests) is that with v6.0 in HCP pipeline 
I had very often to edit wm.mgz in the region of GM-WM interface in the areas 
of (physiological) perivascular subcortical T1 hypointensities due to the 
?h.white "leak" to these areas. 

And also, as I wrote in some of my previous (unanswered) posts:

http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51414.html

the change of -first_wm_peak behaviour in v6.0 in fact worsened white surface 
estimation in my data I tested with HCP pipelines.

I could upload some example subjects if you are interested and have time to dig 
in.

In any case, it is probably hard to compare performance between standard 
recon-all and HCP pipeline and different versions of FreeSurfer due to 
different input to mris_make_surfaces and different flags used. The HCP 
pipeline, as it currently stands, would probably need different optimization of 
code or different command line options due to the different input used.

Regards, 

Antonin Skoch



Hi Bruce,

I don¹t think the hires T1w and T2w stuff are as accurate as 5.3 in the
HCP 0.7mm data that I have looked at (and as I recall at least one other
user had some similar issues, as did one of my collaborators), but that
was all I meant to refer to.  Sorry if my reply came across more general
than that, as of course we want to move to using FreeSurfer V6+ in the
future.  It is the highres T1w and T2w stuff that my pipelines are
designed to exploit, however.  Also there are some changes I have to make
to the HCP Pipelines for FreeSurfer V6+ because of differing file names,
etc.Best,

Matt.

On 3/13/17, 9:40 PM, "Bruce Fischl"
 wrote:

>Hi Matt
>
>To state without qualification that "6.0 has some regressions as far as
>surface placement" is incorrect. We quantified its test-retest
>reliability, 
>accuracy and power to detect disease effects and all were improved
>relative 
>to 5.3. We tested V6 on hundreds of datasets across an array of
>pathologies 
>and different MR sequences, field strengths and scanners. We visually
>inspected dozens of brains multiple times in the process of improving
>accuracy and robustness. I can believe that on Wash U HCP data there
>could 
>be some specific issues, but to imply that V6 is generally less accurate
>is 
>simply incorrect.
>
>cheers
>Bruce
>
>
>On Mon, 13 Mar 2017, Matt Glasser wrote:
>
>> Not yet.  We are hoping FreeSurfer 6.1 will work nicely with the HCP
>> Pipelines.  For now version 6.0 has some regressions as far as surface
>> placement goes and there are also some adaptations we need to make to
>>the
>> pipelines.  
>> 
>> Peace,
>> 
>> Matt.
>> 
>> From:  on behalf of CAGNA
>>Bastien
>> 
>> Reply-To: Freesurfer support list 
>> Date: Monday, March 13, 2017 at 7:21 AM
>> To: "freesurfer@nmr.mgh.harvard.edu" 
>> Subject: [Freesurfer] Can we use fressurfer 6 with the Human connectome
>> project's pipeline ?
>> 
>> Dear freesurfer experts,
>> 
>> 
>> I'm wondering if it's possible to run the human connetome project's
>>minimal
>> processing pipeline using freesurfer 6 ?
>> 
>> 
>> Does it require some update of the pipeline or is there anybody that
>>have
>> already enjoyed the new freesurfer version with this pipeline ?
>> 
>> 
>> Thank you for your attention and your help,
>> 
>> Bastien Cagna
>> ___
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] incorrect surfaces and aseg labeling in subject with large occipital horns of lateral ventricle

[Antonin Skoch]

Dear experts,

in my longitudinal study with 2 timepoints I encountered issue with 
aseg.presurf labeling and white/pial surface estimation of one subject in 
region of occipital horns of lateral ventricle. The voxels in horns are 
mislabeled as either white or gray matter or contain zero values.
I am still in the stage 1 of longitudinal stream, so this is classical 
cross-sectional recon-all stream.

I tried to reprocess this subject by using recon-all -s subj -bigventricles 
-FLAIRpial (despite the fact that the subject does not have generally enlarged 
ventricles I thought that this could help nonlinear registration by 
mri_ca_register ). In case of timepoint 2 this helped to correctly label left 
occipital horn and corrected error with surfaces, but right occipital horn 
remained labeled as white matter.

In contrast, in case of timepoint 1 the -bigventricles did not help to label 
left occipital horn and additionally new massive error with white surface 
placement appeared in the region of occipital horn of left lateral ventricle. 
See the attached screenshots to ilustrate this issue:

tp1_nobigventricles_surface_OK
tp1_bigventricles_surface_error
tp2_nobigventricles_surface_error
tp2_bigventricles_surface_OK

I have uploaded file occipital_horn_ventricle_aseg_and_surf_error.tar.gz 
containing 4 recons (timepoint 1 and 2 with and withoug -bigventricles) to your 
server.

I suppose that the root of the problem is incorrect nonlinear registration. 
Could you please advise how to diagnose and solve the error?

I am using development version from beginning of february 2017.

Regards,

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


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

Re: [Freesurfer] Error viewing corrected results

[Antonin Skoch]

Dear Sahil,

-approx tail and -twotail are completely different things:

-approx tail switch on the tail approximation which speeds up the permutations.

-twotail switch on two-sided hypothesis, without -twotail the hypothesis is 
only one-sided.

It is reassuring that you see some clusters in _tstat_fwep.mgz now. I think 
that this starts to make sense: Since without -twotail there was no value in 
clustere_tstat_fwep.mgz, I think that your setup without -twotail was testing 
the opposite one-sided hypothesis. 

You have to decide which hypothesis you want to test. If you want to test 
one-sided hypothesis of negative correlation and use cluster forming threshold 
0.05 (~ 1.3 in FreeSurfer -log10(p) convention), then I think you should invert 
sign of your contrast vector in Contrast.csv. 

With one-sided hypothesis you can modify your cluster-forming threshold to 
qnorm(1-10^-1.3)=1.643704 to be consistent with the mri_glmfit-sim behaviour. 

If you are testing two-sided hypothesis, your command line is I think almost 
OK, with following recommendations

When not using -approx tail, I would increase number of permutations at least 
to 5000.
Or add -approx tail and then you are running with tail approximation. Then you 
can retain -n 500 as Anderson recommended and your execution time would be much 
shorter.

To report on cluster by use mri_surfcluster, you can use the code snippet I 
send in some of my earlier mails. You can also get cluster-wise p-value by 
loading the *clustere_tstat_fwep.mgz into freeview and clicking on the cluster. 
You can get cluster area by clicking on particular cluster in 
clustere_tstat.mgz.

For visualization purposes Anderson mentioned that it is better to use 
-log10(p) (use the option -logp). Then you can interactively threshold your 
clusters according to the cluster-wise p-values (put 1.3 to min to hide 
clusters not significant at cluster-wise p=0.05). 
Do not forget to apply Bonferroni correction on your p-values when you analyze 
both hemispheres.

To get *cope.mgz for the comparison, you should add -saveglm.

As for comparison of F.mgh and dpv_tstat.mgh: F should be (approximately?) 
square of _tstat at the same vertex, if your contrast vector has one row. The 
correspondence should be (almost?) exact in orthogonal design (as I wrote 
previously, I got exact correspondence in my testing orthogonal design). I am 
not sure for non-orthogonal but I think that this should approximately also 
correspond, so -2 in dpv_tstat.mgh and 12 in F.mgh in the same vertex is maybe 
OK, but I am not sure.

Antonin


Hi Antonin, 
 
Just quick updates and few more points: 
 
(A) Earlier, I was using "-approx tail" in my PALM command and I was not 
getting any thing close to that big cluster but I noticed that you 
mentioned '-twotail' in your last email. So I replaced "-approx tail" 
with ''-twotail'' 
so the command I am running now is: 
 
palm -i *.10.mgh -s fsaverage/surf/lh.white 
fsaverage/surf/lh.white.avg.area.mgh 
-d Xg.csv -t Contrast.csv -m mask.mgh -o Left_Hemi_results -C 1.95 -twotail 
-n 500 -nouncorrected 
 
and I found that I can see a cluster when I view *_culstere_tstat_fwep or 
_dpv_tstat_fwep (both positive magnitude), which are very identical to 
sig.mgh (negative magnitude) from mri_glmfit and big cluster of very high 
negative PCC which I sent earlier. 
 
Here, I am sending you a screen of *_culstere_tstat_fwep, *_dpv_tstat_fwep 
and sig.mgh. 
 
Could you please confirm if thats correct? If so, I have few more questions: 
- When reporting about this cluster for publication, how can I find the 
size, annotation etc. of this cluster? 
- What 'min' and 'max' range of color bar would you recommend when 
reporting *_culstere_tstat_fwep results for the best view possible (at p < 
0.05)? 
 
(B). Even though you said the matchings are valid for orthogonal design 
only, still I just check quickly and found that: 
 
1. Here, I could not find any file with name: *cope.mgh 
2. Here, clusters between F.mgh and *dpv_tstat.mgh are very similar but 
magnitude of dpv_tstat.mgh is very small and negative (~ -2) and of F.mgh 
is very high and positive (~ +12) 
3. Here, magnitude of sig.mgh is roughly same as *dpv_tstat_uncp.mgh: both 
negative and similar big cluster (I am assuming that *dpv_tstat_uncp.mgh 
represents uncorrected p here and is same as *dpv_tstat.mgh, somehow I do 
not see *_uncp.mgh in my outputs). 
 
Thanks a lot for Antonin, 
Sahil 
 
 
On Fri, Mar 10, 2017 at 1:58 AM, Antonin Skoch  wrote: 
 
> Dear Sahil, 
> 
> thinking of that, the comparisons I suggested in previous mail are 
> probably valid only for the case of orthogonal design.  And even with the 
> orthogonal design as Anderson said, the values can a bit differ: 
> 
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1604&L= 
> FSL&D=0&1=FSL&9=A&J=on&d=No+Match%3BMatch%3BMatches&

Re: [Freesurfer] Error viewing corrected results

[Antonin Skoch]

Dear Sahil,

thinking of that, the comparisons I suggested in previous mail are probably 
valid only for the case of orthogonal design.  And even with the orthogonal 
design as Anderson said, the values can a bit differ:

https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1604&L=FSL&D=0&1=FSL&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4&P=318728

As I did my own tests with orthogonal design, the values were equal to the 
reasonable precision, apart from the case 3.

So you could produce some testing orthogonal design and make similar tests on 
that.

Antonin


Dear Sahil,

 I would suggest at first to make check of your GLM  PALM setup by comparing 
mri_glmfit and PALM output files (using the same  design and contrast):

1. values of gamma.mgh should correspond to values of *cope.mgh

2. values of F.mgh should be (*dpv_tstat.mgh) ^2.

3.  values of sig.mgh should be {roughly) values of  
-log10(*dpv_tstat_uncp.mgh) - I am currently not sure why I do not get  exact 
correspondence here.

4. When you threshold the sig.mgh by  some threshold in freeview (let it be x) 
and use the same corresponding  cluster-forming z-score threshold -C  in PALM 
computed as 
qnorm(1-10^-x/2)  (and use two-sided hypothesis by specifying -twotail), your  
*clustere_tstat.mgz should show the clusters with the same shape  (regardless 
of their values, the clusters will be defined by non-zero  value, other 
vertices would be zero) as the thresholded display of  sig.mgh (computed by 
-two sided hypothesis).

If there is any inconsistence, then there is probably something wrong with your 
PALM setup.

Antonin


Dear Antonin, 
 
Could you please have a look at the attached screen shot. This map is with 
full number of permutations, without -approx tail -n 500 -nouncorrected 
 
Here, I noticed that its only *_dpv_tstat.mgz which looks correct and 
giving very high negative value, close to that big cluster, small positive 
values at red clusters and the value changes when I change the position of 
cursor. 
 
*_dpv_tstat_fwep shows value of 1 mostly but shows between 0.97 and 1 
close/at the red clusters and 1 elsewhere, even at the big blue negative 
cluster. 
 
Third, *_clustere_tstat_fwep and *_clustere_tstat shows 1 and 0 
respectively everywhere, even at the big blue negative cluster. 
 
If there is something fishy with the analysis, would you mind looking at 
the data and the detailed commands I am using to run the analysis? 
 
Thanks a lot, 
Sahil 
 
On Wed, Mar 8, 2017 at 11:54 PM, Antonin Skoch  wrote: 
 
> Dear Sahil, 
> 
> to assure that there is no other issue with your setup, I would  recommend to 
> obtain cluster-wise p-pvalue of that big cluster to see if  it is reasonable, 
> i.e. if it is somewhat close to the significance. 
> 
> Therefore, I would load *_clustere_tstat_fwep and click to the  area of big 
> cluster and see what the values of the vertices in that  region are. 
> 
> Or, I would increase --thmax in mri_surfcluster to see the  cluster-wise 
> p-value(s). If you use --thmax 0. (or maybe 1), you  should see 
> cluster-wise FWER corrected p-values of all clusters formed  by used 
> cluster-forming threshold. 
> 
> I would also maybe try to switch-off tail approximation and run  it in full 
> number of permutations (i.e. do not use -approx tail -n 500  -nouncorrected). 
> 
> If there is no other issue, then yes, the conclusion would be,  that for the 
> used cluster-extent inference and currently set  cluster-forming threshold, 
> none of the clusters survived FWER correction  at cluster-wise p-value 
> threshold of 0.05. 
> 
> Antonin 
> 
> 
> 
> Dear Antonin, 
> 
> Setting minimum to 1.3 for *_clustere_tstat_fwep doesn't show any 
> significant cluster and similarly thresholded map *dpv_tstat.mgz also 
> doesn't show anything at -log10(0.05) = 1.3. As you said, it seems like 
> even though there is big cluster but after FWER correction, the 
> significance goes away. Actually, even when I removed -logp, I still do not 
> see any significant cluster. 
> 
> Next, I tried to use mri_surfcluster using following three commands 
> following instructions from the link you sent: 
> 
> mri_binarize --i Results_Left_clustere_tstat_fwep.mgz --min 1 --o p_bin.mgz 
> 
> mris_calc --output pmap_filter.mgz Results_Left_clustere_tstat_fwep.mgz sub 
> p_bin.mgz 
> 
> mri_surfcluster --in pmap_filter.mgz --subject fsaverage --hemi lh --surf 
> white --annot aparc.a2009s --thmin 0.0001 --thmax 0.05 --mask 
> glmdir/mask.mgh --sum summary --nofixmni 
> 
> This gives me 'zero' cluster in the summary file. 
> 
> If the above steps are correct, would you conclude that the LGI results are 
> not significant and un-reportable for publication purpose and I should give 
> a try to thickness, volume and area maps? 
> 
&g

Re: [Freesurfer] Error viewing corrected results

[Antonin Skoch]

Dear Sahil,

 I would suggest at first to make check of your GLM PALM setup by comparing 
mri_glmfit and PALM output files (using the same design and contrast):

1. values of gamma.mgh should correspond to values of *cope.mgh

2. values of F.mgh should be (*dpv_tstat.mgh) ^2.

3. values of sig.mgh should be {roughly) values of -log10(*dpv_tstat_uncp.mgh) 
- I am currently not sure why I do not get exact correspondence here.

4. When you threshold the sig.mgh by some threshold in freeview (let it be x) 
and use the same corresponding cluster-forming z-score threshold -C  in PALM 
computed as 
qnorm(1-10^-x/2) (and use two-sided hypothesis by specifying -twotail), your 
*clustere_tstat.mgz should show the clusters with the same shape (regardless of 
their values, the clusters will be defined by non-zero value, other vertices 
would be zero) as the thresholded display of sig.mgh (computed by -two sided 
hypothesis).

If there is any inconsistence, then there is probably something wrong with your 
PALM setup.

Antonin


Dear Antonin, 
 
Could you please have a look at the attached screen shot. This map is with 
full number of permutations, without -approx tail -n 500 -nouncorrected 
 
Here, I noticed that its only *_dpv_tstat.mgz which looks correct and 
giving very high negative value, close to that big cluster, small positive 
values at red clusters and the value changes when I change the position of 
cursor. 
 
*_dpv_tstat_fwep shows value of 1 mostly but shows between 0.97 and 1 
close/at the red clusters and 1 elsewhere, even at the big blue negative 
cluster. 
 
Third, *_clustere_tstat_fwep and *_clustere_tstat shows 1 and 0 
respectively everywhere, even at the big blue negative cluster. 
 
If there is something fishy with the analysis, would you mind looking at 
the data and the detailed commands I am using to run the analysis? 
 
Thanks a lot, 
Sahil 
 
On Wed, Mar 8, 2017 at 11:54 PM, Antonin Skoch  wrote: 
 
> Dear Sahil, 
> 
> to assure that there is no other issue with your setup, I would  recommend to 
> obtain cluster-wise p-pvalue of that big cluster to see if  it is reasonable, 
> i.e. if it is somewhat close to the significance. 
> 
> Therefore, I would load *_clustere_tstat_fwep and click to the  area of big 
> cluster and see what the values of the vertices in that  region are. 
> 
> Or, I would increase --thmax in mri_surfcluster to see the  cluster-wise 
> p-value(s). If you use --thmax 0. (or maybe 1), you  should see 
> cluster-wise FWER corrected p-values of all clusters formed  by used 
> cluster-forming threshold. 
> 
> I would also maybe try to switch-off tail approximation and run  it in full 
> number of permutations (i.e. do not use -approx tail -n 500  -nouncorrected). 
> 
> If there is no other issue, then yes, the conclusion would be,  that for the 
> used cluster-extent inference and currently set  cluster-forming threshold, 
> none of the clusters survived FWER correction  at cluster-wise p-value 
> threshold of 0.05. 
> 
> Antonin 
> 
> 
> 
> Dear Antonin, 
> 
> Setting minimum to 1.3 for *_clustere_tstat_fwep doesn't show any 
> significant cluster and similarly thresholded map *dpv_tstat.mgz also 
> doesn't show anything at -log10(0.05) = 1.3. As you said, it seems like 
> even though there is big cluster but after FWER correction, the 
> significance goes away. Actually, even when I removed -logp, I still do not 
> see any significant cluster. 
> 
> Next, I tried to use mri_surfcluster using following three commands 
> following instructions from the link you sent: 
> 
> mri_binarize --i Results_Left_clustere_tstat_fwep.mgz --min 1 --o p_bin.mgz 
> 
> mris_calc --output pmap_filter.mgz Results_Left_clustere_tstat_fwep.mgz sub 
> p_bin.mgz 
> 
> mri_surfcluster --in pmap_filter.mgz --subject fsaverage --hemi lh --surf 
> white --annot aparc.a2009s --thmin 0.0001 --thmax 0.05 --mask 
> glmdir/mask.mgh --sum summary --nofixmni 
> 
> This gives me 'zero' cluster in the summary file. 
> 
> If the above steps are correct, would you conclude that the LGI results are 
> not significant and un-reportable for publication purpose and I should give 
> a try to thickness, volume and area maps? 
> 
> Thanks you so much Antonin for all your help. 
> Sahil 
> 
> 
> 
> On Wed, Mar 8, 2017 at 3:05 PM, Antonin Skoch  wrote: 
> 
> > Dear Sahil, 
> > 
> > If you used -logp as Anderson suggested, you should set your min to 1.3 to 
> > threshold your *_clustere_tstat_fwep map and see the clusters. 
> > 
> > What is the value of *_clustere_tstat_fwep in the region of the big 
> > cluster seen at thresholded map *dpv_tstat.mgz ?  This should correspond to 
> > your -log10(p) of your cluster. 
> > 
> > I personally 

Re: [Freesurfer] Error viewing corrected results

[Antonin Skoch]

Dear Sahil,

to assure that there is no other issue with your setup, I would recommend to 
obtain cluster-wise p-pvalue of that big cluster to see if it is reasonable, 
i.e. if it is somewhat close to the significance. 

Therefore, I would load *_clustere_tstat_fwep and click to the area of big 
cluster and see what the values of the vertices in that region are.

Or, I would increase --thmax in mri_surfcluster to see the cluster-wise 
p-value(s). If you use --thmax 0. (or maybe 1), you should see cluster-wise 
FWER corrected p-values of all clusters formed by used cluster-forming 
threshold. 

I would also maybe try to switch-off tail approximation and run it in full 
number of permutations (i.e. do not use -approx tail -n 500 -nouncorrected).

If there is no other issue, then yes, the conclusion would be, that for the 
used cluster-extent inference and currently set cluster-forming threshold, none 
of the clusters survived FWER correction at cluster-wise p-value threshold of 
0.05.

Antonin



Dear Antonin,

Setting minimum to 1.3 for *_clustere_tstat_fwep doesn't show any
significant cluster and similarly thresholded map *dpv_tstat.mgz also
doesn't show anything at -log10(0.05) = 1.3. As you said, it seems like
even though there is big cluster but after FWER correction, the
significance goes away. Actually, even when I removed -logp, I still do not
see any significant cluster.Next, I tried to use mri_surfcluster using 
following three commands
following instructions from the link you sent:

mri_binarize --i Results_Left_clustere_tstat_fwep.mgz --min 1 --o p_bin.mgz

mris_calc --output pmap_filter.mgz Results_Left_clustere_tstat_fwep.mgz sub
p_bin.mgz

mri_surfcluster --in pmap_filter.mgz --subject fsaverage --hemi lh --surf
white --annot aparc.a2009s --thmin 0.0001 --thmax 0.05 --mask
glmdir/mask.mgh --sum summary --nofixmni

This gives me 'zero' cluster in the summary file.

If the above steps are correct, would you conclude that the LGI results are
not significant and un-reportable for publication purpose and I should give
a try to thickness, volume and area maps?

Thanks you so much Antonin for all your help.
Sahil



On Wed, Mar 8, 2017 at 3:05 PM, Antonin Skoch  wrote:

> Dear Sahil,
>
> If you used -logp as Anderson suggested, you should set your min to 1.3 to
> threshold your *_clustere_tstat_fwep map and see the clusters.
>
> What is the value of *_clustere_tstat_fwep in the region of the big
> cluster seen at thresholded map *dpv_tstat.mgz ?  This should correspond to
> your -log10(p) of your cluster.
>
> I personally did not use -logp and use the mri_surfcluster for the
> reporting of the clusters, as I wrote in previous mail here:
>
> http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52042.html
>
> But it is only matter of personal preference.
>
> And, beware, that the LGI is very smooth measure, therefore also rather
> big cluster can be insignificant after FWER correction.
>
> Antonin
>
>
>
>
> Hi Antonin,
>
> Here, I am sending you more information:
>
> (1). I used following command:
> palm -i lh.Behav_LGI.10.mgh -s fsaverage/surf/lh.white
> fsaverage/surf/lh.white.avg.area.mgh -d Xg_Behav.csv -t
> Contrast_Behav.csv
> -m lh.Behav_LGI.glmdir/mask.mgh -o Results_Left -Cstat extent -C 1.95
> -approx tail -n 500 -nouncorrected -logp
>
> (2). Somehow, view of *_clustere_tstat_fwep is single colored, thresholded
> 0 (min) and 1(max), which seems suspicious. Please find it attached.
>
> (3). Data showed in screen shot 1 is just partial correlation coefficient
> (PCC, limiting between 0.30-0.35), obtained after running glm_fit command
> and saved in glm directory.
>
> (4). *_clustere_tstat_fwep is attached here in this email.
>
> (5). If I load *dpv_tstat.mgz and threshold it between 1.3 (p = 0.05) and
> 2
> (max), I get the map attached 2nd in attached figure. I am not sure
> how to "threshold
> it by your cluster-forming threshold (I suppose that you should correctly
> convert z value to t-value), to see your initial clusters after
> thresholding".
>
> Thanks a lot Antonin.
> Sahil
>
>
>
> On Wed, Mar 8, 2017 at 2:06 PM, Antonin Skoch  wrote:
>
> > Dear Sahil,
> >
> > could you send the full command-line and unthresholded view of
> > *_clustere_tstat_fwep ?
> >
> > How the data showed in screenshot 1 were produced?
> >
> > How are the actual p-values of your clusters in *_clustere_tstat_fwep?
> >
> > You can also use -saveglm and inspect the files containing values of GLM
> > fit.
> > You can load the *dpv_tstat.mgz file and threshold it by your
> > cluster-forming threshold (I suppose that you should correctly convert z
> > value to t-value), to see your initial clusters after thresh

Re: [Freesurfer] Error viewing corrected results

[Antonin Skoch]

Dear Sahil,

If you used -logp as Anderson suggested, you should set your min to 1.3 to 
threshold your *_clustere_tstat_fwep map and see the clusters.

What is the value of *_clustere_tstat_fwep in the region of the big cluster 
seen at thresholded map *dpv_tstat.mgz ?  This should correspond to your 
-log10(p) of your cluster.

I personally did not use -logp and use the mri_surfcluster for the reporting of 
the clusters, as I wrote in previous mail here:

http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52042.html

But it is only matter of personal preference.

And, beware, that the LGI is very smooth measure, therefore also rather big 
cluster can be insignificant after FWER correction.

Antonin



Hi Antonin, 
 
Here, I am sending you more information: 
 
(1). I used following command: 
palm -i lh.Behav_LGI.10.mgh -s fsaverage/surf/lh.white 
fsaverage/surf/lh.white.avg.area.mgh -d Xg_Behav.csv -t Contrast_Behav.csv 
-m lh.Behav_LGI.glmdir/mask.mgh -o Results_Left -Cstat extent -C 1.95 
-approx tail -n 500 -nouncorrected -logp 
 
(2). Somehow, view of *_clustere_tstat_fwep is single colored, thresholded 
0 (min) and 1(max), which seems suspicious. Please find it attached. 
 
(3). Data showed in screen shot 1 is just partial correlation coefficient 
(PCC, limiting between 0.30-0.35), obtained after running glm_fit command 
and saved in glm directory. 
 
(4). *_clustere_tstat_fwep is attached here in this email. 
 
(5). If I load *dpv_tstat.mgz and threshold it between 1.3 (p = 0.05) and 2 
(max), I get the map attached 2nd in attached figure. I am not sure 
how to "threshold 
it by your cluster-forming threshold (I suppose that you should correctly 
convert z value to t-value), to see your initial clusters after 
thresholding". 
 
Thanks a lot Antonin. 
Sahil 
 
 
 
On Wed, Mar 8, 2017 at 2:06 PM, Antonin Skoch  wrote: 
 
> Dear Sahil, 
> 
> could you send the full command-line and unthresholded view of 
> *_clustere_tstat_fwep ? 
> 
> How the data showed in screenshot 1 were produced? 
> 
> How are the actual p-values of your clusters in *_clustere_tstat_fwep? 
> 
> You can also use -saveglm and inspect the files containing values of GLM 
> fit. 
> You can load the *dpv_tstat.mgz file and threshold it by your 
> cluster-forming threshold (I suppose that you should correctly convert z 
> value to t-value), to see your initial clusters after thresholding. 
> 
> Regards, 
> 
> Antonin 
> 
> 
> 
> Thanks a lot Anderson and Antonin, that's really useful. 
> 
> Actually, I am having trouble in interpreting the results. Could you 
> please 
> share any document explaining all these tests/outputs and their 
> interpretation in simple terms? 
> 
> Here I am attaching a screen shot: (1) Simple partial correlations (I 
> adjusted the color bar between 0.30 and 0.35 to visualize the high 
> correlation coefficients, which is ~0.35) and (2) Results I get when I 
> used cluster 
> extent stats: *dpv_tstat 
> But I do not see any significant clusters when I view 
> *_clustere_tstat_fwep, *_dpv_tstat_fwep, which is very unexpected in my 
> data set. 
> 
> So basically I really doubt if I am running the stats correctly because 
> PCC 
> looks high at that big cluster (shown in PCC in attached screen shot). 
> 
> Could you please suggest if there is any alternative (less stronger) stat 
> flag I can use here while running PALM command? 
> 
> I would be more than happy sharing any required files to interpret the 
> results. 
> 
> Thanks. 
> 
> On Wed, Mar 8, 2017 at 10:20 AM, Sahil Bajaj  
> wrote: 
> 
> > Thanks a lot Anderson and Antonin, that's really useful. 
> > 
> > Actually, I am having trouble in interpreting the results. Could you 
> > please share any document explaining all these tests/outputs and their 
> > interpretation in simple terms? 
> > 
> > Here I am attaching two screen shots: (1) Results I get when I used 
> cluster 
> > extent stats: *dpv_tstat and (2). Simple partial correlations (I 
> adjusted 
> > the color bar between 0.30 and 0.35 to visualize the high correlation 
> > coefficients, which is ~0.35). 
> > I do not see any significant clusters when I view *_clustere_tstat_fwep, 
> > *_dpv_tstat_fwep, which is very unexpected in my data set. 
> > 
> > So basically I really doubt if I am running the stats correctly because 
> > PCC looks high at that big cluster (shown in PCC in attached screen 
> shot). 
> > 
> > Could you please suggest if there is any alternative (less stronger) 
> stat 
> > flag I can use here while running PALM command? 
> > 
> > I would be more than happy sharing any required files to interpret the 
> > results. 
> > 
> > Thanks. 
> > 

Re: [Freesurfer] Error viewing corrected results

[Antonin Skoch]

Dear Sahil,

could you send the full command-line and unthresholded view of 
*_clustere_tstat_fwep ?

How the data showed in screenshot 1 were produced?

How are the actual p-values of your clusters in *_clustere_tstat_fwep?

You can also use -saveglm and inspect the files containing values of GLM fit.
You can load the *dpv_tstat.mgz file and threshold it by your cluster-forming 
threshold (I suppose that you should correctly convert z value to t-value), to 
see your initial clusters after thresholding. 

Regards,

Antonin


Thanks a lot Anderson and Antonin, that's really useful. 
 
Actually, I am having trouble in interpreting the results. Could you please 
share any document explaining all these tests/outputs and their 
interpretation in simple terms? 
 
Here I am attaching a screen shot: (1) Simple partial correlations (I 
adjusted the color bar between 0.30 and 0.35 to visualize the high 
correlation coefficients, which is ~0.35) and (2) Results I get when I 
used cluster 
extent stats: *dpv_tstat 
But I do not see any significant clusters when I view 
*_clustere_tstat_fwep, *_dpv_tstat_fwep, which is very unexpected in my 
data set. 
 
So basically I really doubt if I am running the stats correctly because PCC 
looks high at that big cluster (shown in PCC in attached screen shot). 
 
Could you please suggest if there is any alternative (less stronger) stat 
flag I can use here while running PALM command? 
 
I would be more than happy sharing any required files to interpret the 
results. 
 
Thanks. 
 
On Wed, Mar 8, 2017 at 10:20 AM, Sahil Bajaj  wrote: 
 
> Thanks a lot Anderson and Antonin, that's really useful. 
> 
> Actually, I am having trouble in interpreting the results. Could you 
> please share any document explaining all these tests/outputs and their 
> interpretation in simple terms? 
> 
> Here I am attaching two screen shots: (1) Results I get when I used cluster 
> extent stats: *dpv_tstat and (2). Simple partial correlations (I adjusted 
> the color bar between 0.30 and 0.35 to visualize the high correlation 
> coefficients, which is ~0.35). 
> I do not see any significant clusters when I view *_clustere_tstat_fwep, 
> *_dpv_tstat_fwep, which is very unexpected in my data set. 
> 
> So basically I really doubt if I am running the stats correctly because 
> PCC looks high at that big cluster (shown in PCC in attached screen shot). 
> 
> Could you please suggest if there is any alternative (less stronger) stat 
> flag I can use here while running PALM command? 
> 
> I would be more than happy sharing any required files to interpret the 
> results. 
> 
> Thanks. 
> 
> On Wed, Mar 8, 2017 at 9:27 AM, Martin Juneja  wrote: 
> 
>> Hi Antonin and Anderson, 
>> 
>> That's wonderful ! I am able to run PALM now, without any problem. 
>> 
>> Thank you so much for your help and time, I really appreciate that. 
>> 
>> Best, 
>> MJ 
>> 
>> 
>> 
>> On Wed, Mar 8, 2017 at 6:30 AM, Anderson M. Winkler < 
>> wink...@fmrib.ox.ac.uk> wrote: 
>> 
>>> Hi all, 
>>> 
>>> That's exactly as Antonin says -- I have very little to add :-) 
>>> 
>>> Only a few suggestions: 
>>> 
>>> - With surfaces, both cluster and TFCE statistics tend to be slow. 
>>> Consider using the tail approximation ("-approx tail -n 500 
>>> -nouncorrected") 
>>> 
>>> - Include -logp, so that the p-values are in log-10 scale. Significant 
>>> p-values are then those above 1.3 (i.e., -log10(0.05). This will help to 
>>> make the figures nicer later. 
>>> 
>>> All the best, 
>>> 
>>> Anderson 
>>> 
>>> 
>>> 
>>> On 8 March 2017 at 00:19, Antonin Skoch  wrote: 
>>> 
>>>> Dear Sahil, 
>>>> 
>>>> I suppose, for qcache 1.3 the equivalent cluster-forming threshold 
>>>> z-value is 
>>>> 
>>>> two-tailed test: 
>>>> qnorm(1-10^-1.3/2)=1.958949 
>>>> 
>>>> for one-tailed test: 
>>>> qnorm(1-10^-1.3)=1.643704 
>>>> 
>>>> (qnorm is R function call for quantile function of normal distribution, 
>>>> you can compute this by using other methods or use statistical z-tables) 
>>>> 
>>>> And, the directionality of the hypothesis is I suppose specified by the 
>>>> sign of your contrast vector, as I wrote in my previous mail. 
>>>> 
>>>> As for the output files, you can look at the documentation: 
>>>> 
>>>> https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/PALM/UserGuide#Output_files 
>>>> 
>>>> For example, if you ar

Re: [Freesurfer] TRACULA tract reconstruction

[Antonin Skoch]

Dear Joelle,

regarding the conversion to .bvecs, could you please show the example of 
difference between bvecs converted by mri_convert of FreeSurfer and mrconvert 
of mrtrix3?

Do you have most recent version of mrtrix3? There have been a quite extensive 
discussion on implementation of FSL .bvec convention in mrtrix3 in spring 2016:

http://www.mrtrix.org/2016/04/15/bug-in-fsl-bvecs-handling/

However, there have been quite a big effort to settle this issue and I am 
pretty convinced that the recent versions should have this issue resolved.

Maybe you can also post this to the mrtrix community forum, they are usually 
responding very quickly and each post gives detailed attention.

Regards,

Antonin Skoch


??Dear Tracula experts,
I am applying Tracula on a longitudinal data set, and have some questions I am 
hoping you could help me with:

Firstly, upon visual inspection, several tracts appear to be quite messy, or 
small (on the default freeview threshold) for most subjects. However, the -stat 
step from Tracula does not necessarily flag these tracts as outliers. What is 
then the best way to decide whether tracts are not correctly reconstructed and 
need to be rerun separately once more? Can I rely on the flagged outliers? Or 
should I rerun all the tracts that do not look ok after visual inspection? And 
in the last case, for tracts that look small, are they considered as correctly 
reconstructed if looking ok at lower thresholds than the default of freeview?

Second, concerning the rerunning of poorly reconstructed tracts, I was 
wondering if there might be a more automated way to configure the dmrirc file 
in order to adapt it for each subject/each tract to rerun (and its 
corresponding control points).

Third, I was wondering if there is a recommended software for obtaining bvecs 
and bvals. For the moment I used mrconvert (from MRtrix, using the 
-export_grad_fsl option) and  the new mri_convert from freesurfer 6.0. As they 
give different outputs, I was wondering if this may impact the reconstruction.

Lastly, would you recommend using freesurfer 5.3 or 6.0 for applying the 
longitudinal stream of Tracula? Related to this, is it recommended to use the 
same freesurfer version to obtain the long/base images, and to run Tracula?


Thank you for your time,


Best regards,

Joëlle van der Molen


___
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 viewing corrected results

[Antonin Skoch]

Dear Sahil,

I suppose, for qcache 1.3 the equivalent cluster-forming threshold z-value is

 two-tailed test:
qnorm(1-10^-1.3/2)=1.958949

for one-tailed test:
qnorm(1-10^-1.3)=1.643704

(qnorm is R function call for quantile function of normal distribution, you can 
compute this by using other methods or use statistical z-tables)

And, the directionality of the hypothesis is I suppose specified by the sign of 
your contrast vector, as I wrote in my previous mail.

As for the output files, you can look at the documentation:

https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/PALM/UserGuide#Output_files

For example, if you are looking for the p-values, used cluster extent inference 
and used t-contrast, the file with FWER-corrected p-values would be something 
like

output_basename_clustere_tstat_fwep.mgz

Antonin




Hello Martin and Antonin,

I was following this conversation very closely to understand how to use
PALM in FreeSurfer.Can any of you please confirm in case I am interested in 
checking
correlation between gyrification index (LGI) and behavioral measure using
two tailed, p < 0.05:
Step 1: I used --cache 1.3
Step 2: Because (1-10^-1.3)= 0.95, so I will have to use -C 0.95 in palm
command

Could you please confirm if thats correct and the output *_tstat.mgz is the
final two-tailed corrected significant correlation map between LGI and
behavioral data?

Thanks a lot for this wonderful discussion.
Sahil

PS: For one-tailed: it will be -C -0.95 in palm command, correct?



On Tue, Mar 7, 2017 at 3:48 PM, Antonin Skoch  wrote:

> Dear Martin,
>
> after -s option, there have to be 2 arguments, as I specified in my previous 
> mail:
>
> -s fsaverage/surf/lh.white fsaverage/surf/lh.white.avg.area.mgh
>
> And beware that -C has to have negative sign, if your hypothesis is 
> one-tailed negative.
>
> Antonin
>
>
>
> Hi Antonin,
>
> Thank you so much for this detailed explanation, that's really useful.
>
> Following your instructions, I ran:
>
> palm -i lh.MEQ_LGI.10.mgh -s fsaverage/surf/lh.white.avg.area.mgh -d
> check.csv -t Contrast_MEQ.csv -n 5000 -m lh.MEQ_LGI.glmdir/mask.mgh -o
> myresults -Cstat extent -C 3.719016
>
> but I am getting following error:
>
> Running PALM alpha104 using MATLAB 9.0.0.341360 (R2016a) with the following
> options:
> -i lh.MEQ_LGI.10.mgh
> -s fsaverage/surf/lh.white.avg.area.mgh
> -d check.csv
> -t Contrast_MEQ.csv
> -n 5000
> -m lh.MEQ_LGI.glmdir/mask.mgh
> -o myresults
> -Cstat extent
> -C 3.719016
> Loading surface 1/1: fsaverage/surf/lh.white.avg.area.mgh
> Reading input 1/1: lh.MEQ_LGI.10.mgh
>
> Struct contents reference from a non-struct array object.
>
> Error in palm_takeargs (line 1632)
> if any(size(plm.srf{s}.data.vtx,
> 1) == ...
>
> Error in palm_core (line 33)
> [opts,plm] = palm_takeargs(varargin{:});
>
> Error in palm (line 81)
> palm_core(varargin{:});
>
> Could you please help me in resolving this error?
>
> Thanks much.
>
> On Tue, Mar 7, 2017 at 2:55 PM, Antonin Skoch  wrote:
>
> > Dear Martin,
> >
> > input -i input file is
> >
> > lh.MEQ_LGI.10.mgh file in your glmdir directory (for left hemisphere).
> >
> > As you could read in following messages in the referenced thread in FSL
> > discussion forum, cluster-forming threshold need to be specified in z, not
> > in t.
> >
> > Therefore, you would have to select cluster forming threshold and specify
> > it as a z score.
> >
> > I think that your z-score for your original mri_glmfit-sim commandline
> > argument
> >
> > --cache 4 neg
> >
> > will be  -qnorm(1-10^-4)=-3.719016. (I am not perfectly sure since I never
> > tried negative one-side hypothesis testing in PALM).
> >
> > You could also use other statistics, such as cluster mass, or TFCE. See
> > PALM user guide.
> >
> > Do not include -pmethodp none and -pmethodr none, since you would need the
> > partitioning due your non-orthogonal design matrix.
> >
> > ?h.white.avg.area.mgh file (which you will find under fsaverage directory)
> > goes as second argument after -s option.
> >
> > Therefore I suppose the commandline for cluster extent inference with
> > cluster forming threshold p=0.0001, negative one-sided hypothesis, left
> > hemisphere, will be hopefully something like
> >
> > palm
> > -i y.mgh
> > -s fsaverage/surf/lh.white fsaverage/surf/lh.white.avg.area.mgh
> > -d Xg.csv
> > -t your_contrasts.csv
> > -n number_of_permutations
> > -m mask.mgh
> > -o output_basename
> > -Cstat extent
> > -C -3.719016
> > -saveglm
> > -savedof
> > -savemetrics
> >
> > The last 3 comman

Re: [Freesurfer] Error viewing corrected results

[Antonin Skoch]

Dear Martin,

thinking of that further, my advice for negative cluster-forming threshold was 
probably wrong in this context. Instead, I think that you can achieve negative 
one-side hypothesis by specifying positive cluster-forming threshold and 
inverting the sign of your contrast vector.

Antonin


Dear Martin,

after -s option, there have to be 2 arguments, as I specified in my previous 
mail:-s fsaverage/surf/lh.white fsaverage/surf/lh.white.avg.area.mgh

And beware that -C has to have negative sign, if your hypothesis is one-tailed 
negative.

Antonin


Hi Antonin,

Thank you so much for this detailed explanation, that's really useful.Following 
your instructions, I ran:

palm -i lh.MEQ_LGI.10.mgh -s fsaverage/surf/lh.white.avg.area.mgh -d
check.csv -t Contrast_MEQ.csv -n 5000 -m lh.MEQ_LGI.glmdir/mask.mgh -o
myresults -Cstat extent -C 3.719016

but I am getting following error:

Running PALM alpha104 using MATLAB 9.0.0.341360 (R2016a) with the following
options:
-i lh.MEQ_LGI.10.mgh
-s fsaverage/surf/lh.white.avg.area.mgh
-d check.csv
-t Contrast_MEQ.csv
-n 5000
-m lh.MEQ_LGI.glmdir/mask.mgh
-o myresults
-Cstat extent
-C 3.719016
Loading surface 1/1: fsaverage/surf/lh.white.avg.area.mgh
Reading input 1/1: lh.MEQ_LGI.10.mgh

Struct contents reference from a non-struct array object.

Error in palm_takeargs (line 1632)
if any(size(plm.srf{s}.data.vtx,1) == ...

Error in palm_core (line 33)
[opts,plm] = palm_takeargs(varargin{:});

Error in palm (line 81)
palm_core(varargin{:});

Could you please help me in resolving this error?

Thanks much.

On Tue, Mar 7, 2017 at 2:55 PM, Antonin Skoch  wrote:

> Dear Martin,
>
> input -i input file is
>
> lh.MEQ_LGI.10.mgh file in your glmdir directory (for left hemisphere).
>
> As you could read in following messages in the referenced thread in FSL
> discussion forum, cluster-forming threshold need to be specified in z, not
> in t.
>
> Therefore, you would have to select cluster forming threshold and specify
> it as a z score.
>
> I think that your z-score for your original mri_glmfit-sim commandline
> argument
>
> --cache 4 neg
>
> will be  -qnorm(1-10^-4)=-3.719016. (I am not perfectly sure since I never
> tried negative one-side hypothesis testing in PALM).
>
> You could also use other statistics, such as cluster mass, or TFCE. See
> PALM user guide.
>
> Do not include -pmethodp none and -pmethodr none, since you would need the
> partitioning due your non-orthogonal design matrix.
>
> ?h.white.avg.area.mgh file (which you will find under fsaverage directory)
> goes as second argument after -s option.
>
> Therefore I suppose the commandline for cluster extent inference with
> cluster forming threshold p=0.0001, negative one-sided hypothesis, left
> hemisphere, will be hopefully something like
>
> palm
> -i y.mgh
> -s fsaverage/surf/lh.white fsaverage/surf/lh.white.avg.area.mgh
> -d Xg.csv
> -t your_contrasts.csv
> -n number_of_permutations
> -m mask.mgh
> -o output_basename
> -Cstat extent
> -C -3.719016
> -saveglm
> -savedof
> -savemetrics
>
> The last 3 commandline options are only for diagnostical purposes.
>
> The output is surface overlay you can visualize in freeview.
>
> I use following code snippet for the reporting significant clusters in MNI
> coordinates:
>
> # PALM output cluster extent p maps have 1 outside cluster - problem with
> mri_surfcluster and also for display in freeView
> #here we set values 1 to 0 in pmaps.
> #done by binarizing and subtracting
> if [[ $# -ne 2 ]]; then
> echo "get cluster summary of PALM statistics. Expecting 2 arguments: 1-
> input p-map, 2- hemisphere (lh/rh)"
> exit
> fi
> mri_binarize --i $1 --min 1 --o p_bin.mgz
> mris_calc --output ${1%%.mgz}_filtered.mgz $1 sub p_bin.mgz
> mri_surfcluster --in ${1%%.mgz}_filtered.mgz --subject fsaverage --hemi $2
> --surf white --annot aparc --thmin 0.1 --thmax 0.05 --mask mask.mgh
> --sum ${1%%.mgz}_cluster.summary --nofixmni
> rm p_bin.mgz
>
> They are not Bonferroni-corrected for 2 hemispheres (--2spaces).
>
> Regarding your design and contrast:
>
> Design has to be matrix of values. You can use qdec to produce Xg.dat file
> with design matrix, then rename it to Xg.csv to be correctly readable by
> PALM.
>
> Regards,
>
> Antonin
>
>
>
>
>
> Hi Antonin,
>
> As you suggested in discussion forum, I tried to run following command
> after mri_glmfit:
>
> palm -s fsaverage/surf/lh.white -n 1 -m mask.mgh -Cstat extent -C
> 1.974975 -pmethodp none -pmethodr none -twotail -d Design_MEQ.txt -t
> Contrast_MEQ.txt
>
> Running PALM alpha104 using MATLAB 9.0.0.341360 (R2016a) with the following
> options:
>
> -s fsaverage/surf/lh.white
>
> -n 1000

Re: [Freesurfer] Error viewing corrected results

[Antonin Skoch]

Dear Martin,

after -s option, there have to be 2 arguments, as I specified in my previous 
mail:

-s fsaverage/surf/lh.white fsaverage/surf/lh.white.avg.area.mgh

And beware that -C has to have negative sign, if your hypothesis is one-tailed 
negative.

Antonin


Hi Antonin,

Thank you so much for this detailed explanation, that's really useful.Following 
your instructions, I ran:

palm -i lh.MEQ_LGI.10.mgh -s fsaverage/surf/lh.white.avg.area.mgh -d
check.csv -t Contrast_MEQ.csv -n 5000 -m lh.MEQ_LGI.glmdir/mask.mgh -o
myresults -Cstat extent -C 3.719016

but I am getting following error:

Running PALM alpha104 using MATLAB 9.0.0.341360 (R2016a) with the following
options:
-i lh.MEQ_LGI.10.mgh
-s fsaverage/surf/lh.white.avg.area.mgh
-d check.csv
-t Contrast_MEQ.csv
-n 5000
-m lh.MEQ_LGI.glmdir/mask.mgh
-o myresults
-Cstat extent
-C 3.719016
Loading surface 1/1: fsaverage/surf/lh.white.avg.area.mgh
Reading input 1/1: lh.MEQ_LGI.10.mgh

Struct contents reference from a non-struct array object.

Error in palm_takeargs (line 1632)
if any(size(plm.srf{s}.data.vtx,1) == ...

Error in palm_core (line 33)
[opts,plm] = palm_takeargs(varargin{:});

Error in palm (line 81)
palm_core(varargin{:});

Could you please help me in resolving this error?

Thanks much.

On Tue, Mar 7, 2017 at 2:55 PM, Antonin Skoch  wrote:

> Dear Martin,
>
> input -i input file is
>
> lh.MEQ_LGI.10.mgh file in your glmdir directory (for left hemisphere).
>
> As you could read in following messages in the referenced thread in FSL
> discussion forum, cluster-forming threshold need to be specified in z, not
> in t.
>
> Therefore, you would have to select cluster forming threshold and specify
> it as a z score.
>
> I think that your z-score for your original mri_glmfit-sim commandline
> argument
>
> --cache 4 neg
>
> will be  -qnorm(1-10^-4)=-3.719016. (I am not perfectly sure since I never
> tried negative one-side hypothesis testing in PALM).
>
> You could also use other statistics, such as cluster mass, or TFCE. See
> PALM user guide.
>
> Do not include -pmethodp none and -pmethodr none, since you would need the
> partitioning due your non-orthogonal design matrix.
>
> ?h.white.avg.area.mgh file (which you will find under fsaverage directory)
> goes as second argument after -s option.
>
> Therefore I suppose the commandline for cluster extent inference with
> cluster forming threshold p=0.0001, negative one-sided hypothesis, left
> hemisphere, will be hopefully something like
>
> palm
> -i y.mgh
> -s fsaverage/surf/lh.white fsaverage/surf/lh.white.avg.area.mgh
> -d Xg.csv
> -t your_contrasts.csv
> -n number_of_permutations
> -m mask.mgh
> -o output_basename
> -Cstat extent
> -C -3.719016
> -saveglm
> -savedof
> -savemetrics
>
> The last 3 commandline options are only for diagnostical purposes.
>
> The output is surface overlay you can visualize in freeview.
>
> I use following code snippet for the reporting significant clusters in MNI
> coordinates:
>
> # PALM output cluster extent p maps have 1 outside cluster - problem with
> mri_surfcluster and also for display in freeView
> #here we set values 1 to 0 in pmaps.
> #done by binarizing and subtracting
> if [[ $# -ne 2 ]]; then
> echo "get cluster summary of PALM statistics. Expecting 2 arguments: 1-
> input p-map, 2- hemisphere (lh/rh)"
> exit
> fi
> mri_binarize --i $1 --min 1 --o p_bin.mgz
> mris_calc --output ${1%%.mgz}_filtered.mgz $1 sub p_bin.mgz
> mri_surfcluster --in ${1%%.mgz}_filtered.mgz --subject fsaverage --hemi $2
> --surf white --annot aparc --thmin 0.1 --thmax 0.05 --mask mask.mgh
> --sum ${1%%.mgz}_cluster.summary --nofixmni
> rm p_bin.mgz
>
> They are not Bonferroni-corrected for 2 hemispheres (--2spaces).
>
> Regarding your design and contrast:
>
> Design has to be matrix of values. You can use qdec to produce Xg.dat file
> with design matrix, then rename it to Xg.csv to be correctly readable by
> PALM.
>
> Regards,
>
> Antonin
>
>
>
>
>
> Hi Antonin,
>
> As you suggested in discussion forum, I tried to run following command
> after mri_glmfit:
>
> palm -s fsaverage/surf/lh.white -n 1 -m mask.mgh -Cstat extent -C
> 1.974975 -pmethodp none -pmethodr none -twotail -d Design_MEQ.txt -t
> Contrast_MEQ.txt
>
> Running PALM alpha104 using MATLAB 9.0.0.341360 (R2016a) with the following
> options:
>
> -s fsaverage/surf/lh.white
>
> -n 1
>
> -m mask.mgh
>
> -Cstat extent
>
> -C 1.974975
>
> -pmethodp none
>
> -pmethodr none
>
> -twotail
>
> -d Design.txt
>
> -t Contrast.txt
>
> Found FSL in /usr/share/fsl/5.0
>
> Found FreeSurfer in /usr/local/freesurfer
>
> Found SPM in 

Re: [Freesurfer] Error viewing corrected results

[Antonin Skoch]

Dear Martin,

input -i input file is  
lh.MEQ_LGI.10.mgh file in your glmdir directory (for left hemisphere).

As you could read in following messages in the referenced thread in FSL 
discussion forum, cluster-forming threshold need to be specified in z, not in t.

Therefore, you would have to select cluster forming threshold and specify it as 
a z score.

I think that your z-score for your original mri_glmfit-sim commandline argument
--cache 4 negwill be  -qnorm(1-10^-4)=-3.719016. (I am not perfectly sure since 
I never tried negative one-side hypothesis testing in PALM).

You could also use other statistics, such as cluster mass, or TFCE. See PALM 
user guide.

Do not include -pmethodp none and -pmethodr none, since you would need the 
partitioning due your non-orthogonal design matrix.

?h.white.avg.area.mgh file (which you will find under fsaverage directory) goes 
as second argument after -s option.

Therefore I suppose the commandline for cluster extent inference with cluster 
forming threshold p=0.0001, negative one-sided hypothesis, left hemisphere, 
will be hopefully something like

palm
-i y.mgh
-s fsaverage/surf/lh.white fsaverage/surf/lh.white.avg.area.mgh
-d Xg.csv
-t your_contrasts.csv
-n number_of_permutations
-m mask.mgh 
-o output_basename
-Cstat extent
-C -3.719016
-saveglm
-savedof
-savemetrics

The last 3 commandline options are only for diagnostical purposes.

The output is surface overlay you can visualize in freeview.

I use following code snippet for the reporting significant clusters in MNI 
coordinates:

# PALM output cluster extent p maps have 1 outside cluster - problem with 
mri_surfcluster and also for display in freeView
#here we set values 1 to 0 in pmaps.
#done by binarizing and subtracting
if [[ $# -ne 2 ]]; then
echo "get cluster summary of PALM statistics. Expecting 2 arguments: 1- input 
p-map, 2- hemisphere (lh/rh)"
exit
fi
mri_binarize --i $1 --min 1 --o p_bin.mgz
mris_calc --output ${1%%.mgz}_filtered.mgz $1 sub p_bin.mgz
mri_surfcluster --in ${1%%.mgz}_filtered.mgz --subject fsaverage --hemi $2 
--surf white --annot aparc --thmin 0.1 --thmax 0.05 --mask mask.mgh 
--sum ${1%%.mgz}_cluster.summary --nofixmni
rm p_bin.mgz

They are not Bonferroni-corrected for 2 hemispheres (--2spaces).

Regarding your design and contrast:

Design has to be matrix of values. You can use qdec to produce Xg.dat file with 
design matrix, then rename it to Xg.csv to be correctly readable by PALM.

Regards,

Antonin




Hi Antonin,

As you suggested in discussion forum, I tried to run following command
after mri_glmfit:palm -s fsaverage/surf/lh.white -n 1 -m mask.mgh -Cstat 
extent -C
1.974975 -pmethodp none -pmethodr none -twotail -d Design_MEQ.txt -t
Contrast_MEQ.txt

Running PALM alpha104 using MATLAB 9.0.0.341360 (R2016a) with the following
options:

-s fsaverage/surf/lh.white

-n 1

-m mask.mgh

-Cstat extent

-C 1.974975

-pmethodp none

-pmethodr none

-twotail

-d Design.txt

-t Contrast.txt

Found FSL in /usr/share/fsl/5.0

Found FreeSurfer in /usr/local/freesurfer

Found SPM in /usr/local/spm12

Error using palm_takeargs (line 1141)

Missing input data (missing "-i").

Error in palm_core (line 33)

[opts,plm] = palm_takeargs(varargin{:});

Error in palm (line 81)

palm_core(varargin{:});

Looks like error is because its missing -i input here, I am not sure what's
input file here?

Also, I am trying to correlate LGI versus behavioral score, regressing out
the effect of sex and age. So I just wanted to confirm if my design.txt and
contrast.txt files are correct here. Please find both following:

Design file (Variables Behav, Age) as following:

S001 Male 60 36

S003 Female 73 29

S004 Male 48 39

...so on..

Contrast file as following:
0 0 0.5 0.5 0 0 (same as *.mtx file used for glm_fit)

Thank you so much for your help and time.

On Tue, Mar 7, 2017 at 10:49 AM, Martin Juneja  wrote:

> Hi Antonin,
>
> Thanks a lot for your reply.
>
> Somehow, in the link you sent, I could not find any response to your
> email. But I can see your email to Anderson and command line parameters.
>
> As I am not an expert in using FreeSurfer, so would it be possible for you
> to share detailed step-by-step guide and PALM command after I run mri_glmfit
> command and how and where to include '?h.white.avg.area.mgh' file?
>
> I would really appreciate any help.
>
> On Mon, Mar 6, 2017 at 4:28 PM, Antonin Skoch  wrote:
>
>> Dear Martin,
>>
>> I think yes, you can use PALM with FreeSurfer surfaces, see my
>> conversation with Anderson on FSL list:
>>
>> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1604&L=FSL
>> &D=0&1=FSL&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4&P=239088
>>
>> but beware not to forget to include average the vertex area
>> (?h.white.avg.area.mgh) file.
>>
>> Antonin
>>

Re: [Freesurfer] wm.mgz manual editing, revisited

[Antonin Skoch]

Dear Eli,

did you read my response to your previous thread?

I recommended you to try adding control points to the white matter.

http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51959.html

Regards,

Antonin

Hello all,

Again, I tried to modify the white matter surface by adding voxels to
the wm.mgz file, and performed the reconstruction by doing the
following.-Opened brainmask.mgz for reference
-Opened wm.mgz on top of that
-Click the voxel edit button
-Check the recon editing checkbox
-Fill in voxels where I want to extend the whitematter surface
-Save wm.mgz
-At terminal, from the appropriate subject directory, run:
recon-all -autorecon2-wm -autorecon3 -subjid my_subject -sd `pwd`

Once this is finished, I examine the surfaces, but they have not
changed. lh/rh.white should be changed to include the voxels I painted
in, correct? 

I have no problem removing voxels from the pial surface, but extending
the white matter is for some reason not working for me, so I am really
stumped as to why these wm.mgz edits aren't making any difference.

Any help with this is vastly appreciated. I have tried this several
times on different subjects with no luck.

Here are links to some relevant files.
001.mgz:
https://1drv.ms/u/s!AoOsIIayCH7qlxLBNvCT4JCvM1Kc

recon-all.logs.tar.gz:
https://1drv.ms/u/s!AoOsIIayCH7qlxRGOWpUCttk5Zji

brainmask+surf+wm.tar.gz
https://1drv.ms/u/s!AoOsIIayCH7qlxbDSS54gfHkq2M3

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] Error viewing corrected results

[Antonin Skoch]

Dear Martin,

I think yes, you can use PALM with FreeSurfer surfaces, see my conversation 
with Anderson on FSL list:

https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1604&L=FSL&D=0&1=FSL&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4&P=239088

but beware not to forget to include average the vertex area 
(?h.white.avg.area.mgh) file.

Antonin


If you don't have an orthogonal design, then you can't use 
mri_glmfit-sim. I think you can use 
PALM:https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/PALM

I have not tried it yet.

Anderson, can you use PALM with surfaces?






On 03/06/2017 05:23 PM, Martin Juneja wrote:
> Hi Dr. Greve,
>
> I tried to run: mri_glmfit-sim --glmdir lh.MEQ_LGI.glmdir --sim perm 
> 1000 3 permcsd --sim-sign abs --cwpvalthresh .05
> It gives error that ERROR: design matrix is not orthogonal, cannot be 
> used with permutation.
>
> But when I run: mri_glmfit-sim --glmdir lh.MEQ_LGI.glmdir --sim perm 
> 1000 3 permcsd --sim-sign abs --cwpvalthresh .05 --perm-force, it works.
>
> I am not sure whether I will have to make the design matrix 
> orthogonal. If so, could you please tell me how that can be done?
>
> Or using --perm-force should be fine?
>
> Thanks.
>
> On Mon, Mar 6, 2017 at 1:58 PM, Douglas N Greve 
> mailto:gr...@nmr.mgh.harvard.edu>> wrote:
>
> This is a problem with using LGI in that it is already extremely
> smooth
> that the smoothness exceeds the limit of the look up table that we
> supply. I  recommend that you not use a gaussian-based correction for
> LGI. Instead, use permutation (see mri_glmfit-sim --help).
>
>
>
> On 03/06/2017 01:36 PM, Martin Juneja wrote:
> > Hello everyone,
> >
> > I am trying to extract clusters showing significant correlation
> > between LGI and a behavioral measure. I am able to extract PCC and
> > sig.mgh but at the last step when I try to run simulation command to
> > view corrected results and I run:
> >
> > mri_glmfit-sim --glmdir lh.MEQ_LGI.glmdir --cache 4 neg --cwp 0.05
> > --2spaces
> >
> > I get following error:
> >
> > ERROR: cannot find
> >
> 
> /usr/local/freesurfer/average/mult-comp-cor/fsaverage/lh/cortex/fwhm35/neg/th40/mc-z.csd
> >
> > But I can see mc-z.csd file in fwhm30 etc.
> >
> > Full message on terminal window is attached following.
> >
> > Any help would be really appreciated.
> >
> > - Full message 
> >
> > cmdline mri_glmfit.bin --y lh.MEQ_LGI.10.mgh --fsgd MEQ.fsgd
> dods --C
> > Corr-MEQ-cor.mtx --surf fsaverage lh --cortex --glmdir
> lh.MEQ_LGI.glmdir
> >
> > WARNING: unrecognized mri_glmfit cmd option mri_glmfit.bin
> >
> > SURFACE: fsaverage lh
> >
> > log file is lh.MEQ_LGI.glmdir/cache.mri_glmfit-sim.log
> >
> > /usr/local/freesurfer/bin/mri_glmfit-sim
> >
> > --glmdir lh.MEQ_LGI.glmdir --cache 4 neg --cwp 0.05 --2spaces
> >
> > $Id: mri_glmfit-sim,v 1.60 2016/04/30 15:13:36 greve Exp $
> >
> > Mon Mar  6 11:11:13 MST 2017
> >
> > setenv SUBJECTS_DIR
> > /data/emot/Freesurfer/FreeSurferSegmentation/SB_AgingAll
> >
> > FREESURFER_HOME /usr/local/freesurfer
> >
> > Original mri_glmfit command line:
> >
> > cmdline mri_glmfit.bin --y lh.MEQ_LGI.10.mgh --fsgd MEQ.fsgd
> dods --C
> > Corr-MEQ-cor.mtx --surf fsaverage lh --cortex --glmdir
> lh.MEQ_LGI.glmdir
> >
> > DoSim = 0
> >
> > UseCache = 1
> >
> > DoPoll = 0
> >
> > DoPBSubmit = 0
> >
> > DoBackground = 0
> >
> > DiagCluster = 0
> >
> > gd2mtx = dods
> >
> > fwhm = 35.073391
> >
> > ERROR: cannot find
> >
> 
> /usr/local/freesurfer/average/mult-comp-cor/fsaverage/lh/cortex/fwhm35/neg/th40/mc-z.csd
> >
> >
___
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] Creating custom aparc.a2009s+aseg.mgz: Shuffled names of parcellations after mris_label2annot

[Antonin Skoch]

Dear Doug,

I am sorry, the problem with missing perirhinal label in .annot was due to typo 
in my .ctab file (also seen in my previous mail). Now it works OK.

I have already solved my problem by creating annotation just of entorhinal and 
perirhinal labels (like I wrote in my post here: 
http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51979.html ), 
running it through mri_aparc2aseg and then fusing with default 
aparc.a2009s+aseg.mgz. It works correctly I think.

Btw, just for the record, only now I have noticed that some labels in 
aparc.a2009s.annot in fsaverage have different names than in aparc.a2009s.annot 
of subject processed by recon-all.
For example, anterior insula is read G_and_S_cingul-Ant in fsaverage, whereas 
in subject run through recon-all it reads G&S_cingul-Ant.
This was another reason of missing labels in my testing .annot in fsaverage 
since due to the fact that .ctab file in fsaverage is not available, I used 
.ctab file from some of my subjects.

Antonin


I cannot replicate the missing last label. Can you upload the relevant 
data so I can take a look? Using the --l instead should work too. For 
your other  problem, I would probably run mri_label2label with the 
--outstat option to create an overlay of the statistic, then create a 
segmentation based on the maximum stat using somethign likemri_concat 
label1stat.mgh ... labelNstat.mgh --max-index --o labelseg.mgh

You can convert this back to labels with

mri_cor2label --surf fsaverage lh --i labelseg.mgh --id 1 --l 
newlabel1.label


On 03/02/2017 12:05 PM, Antonin Skoch wrote:
> Dear Doug,
>
> I am using quite recent dev version built 8/2/2017.
>
> mris_label2annot of this version is following:
>
> $Id: mris_label2annot.c,v 1.20 2016/01/07 23:28:11 greve
>
> Regards,
>
> Antonin
>
>
> what version are you using? I thought I fixed the missing-last-label
> problem in v6
> On 03/01/2017 06:42 PM, Antonin Skoch wrote:
> > Dear Doug,
> >
> > thank you, adding  --no-unknown indeed fixed the global shuffling of
> > the label names. However, last line of .ctab seems not to be read this
> > time and produced .annot does not contain perirhinal label.
> >
> > My modified .ctab file looks like this:
> >
> >  0  Unknown   0   0   00
> >   1  G&S_frontomargin 23 220  600
> >   2  G&S_occipital_inf23  60 1800
> >   3  G&S_paracentral  63 100  600
> >   4  G&S_subcentral   63  20 2200
> >   5  G&S_transv_frontopol 13   0 2500
> >   6  G&S_cingul-Ant   26  60   00
> >   7  G&S_cingul-Mid-Ant   26  60  750
> >   8  G&S_cingul-Mid-Post  26  60 1500
> >   9  G_cingul-Post-dorsal 25  60 2500
> >  10  G_cingul-Post-ventral60  25  250
> >  11  G_cuneus180  20  200
> >  12  G_front_inf-Opercular   220  20 1000
> >  13  G_front_inf-Orbital 140  60  600
> >  14  G_front_inf-Triangul180 220 1400
> >  15  G_front_middle  140 100 1800
> >  16  G_front_sup 180  20 1400
> >  17  G_Ins_lg&S_cent_ins  23  10  100
> >  18  G_insular_short 225 140 1400
> >  19  G_occipital_middle  180  60 1800
> >  20  G_occipital_sup  20 220  600
> >  21  G_oc-temp_lat-fusifor60  20 1400
> >  22  G_oc-temp_med-Lingual   220 180 1400
> >  23  G_oc-temp_med-Parahip65 100  200
> >  24  G_orbital   220  60  200
> >  25  G_pariet_inf-Angular 20  60 2200
> >  26  G_pariet_inf-Supramar   100 100  600
> >  27  G_parietal_sup  220 180 2200
> >  28  G_postcentral20 180 1400
> >  29  G_precentral 60 140 1800
> >  30  G_precuneus  25  20 1400
> >  31  G_rectus 20  60 1000
> >  32  G_subcallosal60 220  200
> >  33  G_temp_sup-G_T_transv60  60 2200
> >  34  G_temp_sup-Lateral  220  60 2200
> >  35  G_temp_sup-Plan_polar65 220  600
> >  36  G_temp_sup-Plan_tempo25 140  200
> >  37  G_temporal_inf  220 220 1000
> >  38  G_temporal_middle   180  60  600
> >  39  Lat_Fis-ant-Horizont 61  20 2200
> >  40  Lat_Fis-ant-Vertical 61  20  600
> >  41 

Re: [Freesurfer] Automated extraction of dural/meningeal ROI?

[Antonin Skoch]

Dear Daniel,

For the "outer" boundary of your ROI, I would try the betsurf from FSL for the 
inner skull surface estimation. This should be more precise than using 
brainmask.mgz.

https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/BET/UserGuide

Antonin

You could remove the brain (as found in aseg.mgz) from the 
brainmask.mgz. This will leave some dura. It is not an elegant or 
accurate solution
On 03/06/2017 02:24 PM, Albrecht, Daniel S. wrote:
> Hello,
>
> We have a PET dataset where we expect to see pathogenic changes in the 
> meninges. We'd like to extract the meningeal signal in subject space, 
> and were hoping to come up with an automated strategy to create 
> meningeal ROIs, containing no brain or scalp.
> So my question is: can you suggest any way within the FreeSurfer 
> pipeline that we can create a meningeal-only ROI, or alternatively an 
> ROI containing both skull and meninges, but still no scalp or brain?
>
> Your help is greatly appreciated!
>
> Daniel S. Albrecht, PhD
> Research Fellow in Radiology
> Martinos Center for Biomedical Imaging___
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] threshold method used to obtain *exvivo.thresh.labels

[Antonin Skoch]

Dear experts,

concerning my question regarding thresholding method of entorhinal and 
perirhinal labels, I looked at

Augustinack JC et al, Predicting the location of human perirhinal  cortex, 
Brodmann's area 35, from MRI, Neuroimage 2013 Jan 1;64:32-42.

where I found the text:

For each label, the vertices were ordered from most probable least probable), 
then thresholded so that the surface area of each predicted entorhinal cortex 
or perirhinal cortex label matched the average surface area of the ex vivo 
labels.

So, if I understand it correctly, at least for the entorhinal and perirhinal 
*thresh labels, the threshold has been found individually for each label and 
hemisphere separately, so that the area of the label in the fsaverage space 
match average surface area of the corresponding ex-vivo labels? 
Therefore, no restriction for overlap of perirhinal and entorhinal labels was 
applied in the thresholding? I found that in the right hemisphere the 
rh.entorhinal_thresh.label almost completely overlaps with 
lh.entorhinal_thresh.label.

But, for generating custom aparc+aseg I need non-overlapping labels. I 
attempted to resolve the issue by using 

mris_label2annot --s fsaverage --l fsaverage/label/lh.entorhinal_exvivo.label 
--l fsaverage/label/lh.perirhinal_exvivo.label --hemi lh --ctab 
entorhinal_perirhinal.annot.ctab --maxstatwinner --thresh 0.4 --a 
entorhinal_perirhinal_thresh_0.4

i.e. using --maxstatswinner and --thresh 0.4 which gives non-overlapping labels 
with shapes approximately similar to the original 
entorhinal_exvivo.thresh.label and perirhinal_exvivo.thresh.label, but it 
probably violates the condition of similar area extent.

Could you please comment on if my used method is acceptable, or suggest better 
method how to achieve non-overlaping entorhinal and perirhinal labels for the 
purpose of generating custom aparc+aseg from them?

Regards,

Antonin Skoch

Dear experts,

Could you please provide me the information how exactly the 
*_exvivo.thresh.labels have been thresholded?According to this post, 
http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg32542.html
.thresh labels are thresholded to pick the most likely vertices that give a 
label that is 
the right surface area.But how they are thresholded in the boundary of the 
region where the unthresholded labels do not overlap? There must be additional 
threshold applied:
For example for BA45 there is no further BA label towards frontal pole, but the 
BA45_exvivo.thresh.label is also restricted in this region wrt 
BA45_exvivo.label.

I have further question concerning used thresholding method of 
perirhinal_exvivo.thresh and entorhinal_exvivo.thresh labels. It seems that 
this method is not applied here since looking at them at the fsaverage surface, 
they are overlapping. And also *rhinal_exvivo.labels are much more extending to 
the adjacent regions than *rhinal_exvivo.thresh.labels. What method is applied 
here?

My main objective to obtain annotation with the vertices properly assigned to 
perirhinal_exvivo and entorhinal_exvivo to supply this annotation to 
mri_aparc2aseg to assign ribbon voxels to that parcellation. I think I could 
use mris_label2annot --maxstatswinner with unthresholded entorhinal and 
perirhinal labels to assign vertices to most probable label, but I would need 
to further threshold the labels by correct value to obtain results similar in 
extent to thresh.labels.

For perirhinal, it seems that the additional threshold is 0.4 (what is 
rationale for this value?), for entorhinal it seems also around 0.4 but could 
not find any particular threshold to obtain the exact shape of label 
corresponding to entorhinal_exvivo.thresh.

Thank you in advance for clarification.

Regards,

Antonin Skoch

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


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

Re: [Freesurfer] recon-all exited with error.

[Antonin Skoch]

Dear Paul,

yes, this is the modification of FREESURFER_HOME you need to do (using setenv 
command if you are using tcsh).

Regards, 

Antonin


Hey Antonin,
Thank you. hence, the right path should be "setenv FREESURFER_HOME
/opt/freesurfer-6.0.0/freesurfer "
Best,
Paul.
On Thu, Mar 2, 2017 at 5:41 PM, Antonin Skoch  wrote:

> Dear Paul,
>
> the slash problem prevents to properly create symbolic link to fsaverage in 
> your SUBJECTS_DIR.
>
> Then, the mri_label2label could not find the fsaverage label file since 
> symbolic link for fsaverage does not exist, hence produces the error.log you 
> are attaching.
>
> Regards,
>
> Antonin
>
>
> Thanks Antonin. Also, I got this error.log file in my label folder. Do you
> think it is due to the slash problem?
> Best,
> Paul
>
> On Thu, Mar 2, 2017 at 4:38 PM, Antonin Skoch  wrote:
>
> > Dear Paul,
> >
> > I suppose the clue is following messages from your recon-all.log file:
> >
> > FREESURFER_HOME /opt/freesurfer-6.0.0/freesurfer/
> >
> > and
> >
> >  cd /net/synapse/nt/mozzoude/processing/freesurfer/176_003_120326; ln -s
> > /opt/freesurfer-6.0.0/freesurfer//subjects/fsaverage; cd -
> >
> > ln: failed to create symbolic link './fsaverage': File exists
> >
> > The problem is that your FREESURFER_HOME contains slash in the end. Remove 
> > it
> > and rerun relevant part of recon-all. It should work then.
> >
> > Antonin
> >
> >
> >
> >
> > Hello Freesurfer,
> > I was running recon-all in steps (recon-all -autorecon1, recon-all
> > -autorecon2, and recon-all - -T2 /T2 volume  -T2pial autorecon3). However,
> > it exited with error during the BA_exvivo labels part of autorecon3 (please
> > see attached recon-all.log file). Please, how can I fix it? Thanks
> > Best,
> > Paul
___
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.mgz manual editing

[Antonin Skoch]

Dear Eli,

I have looked at your data.

Due to the fact that the white matter does have intensity well below 110 in the 
large portion of white matter area under your problematic spot, I think that 
instead of editing wm.mgz the better way in your case would be to add some 
control points to the white matter surrounding region

112,49,128.

Btw, it seems that the white matter has generally very inhomogeneus signal 
intensity. Does not the image originate from the subjects with some kind of 
severe pathology of white matter?
What is the large hypointense spot centered at 102,64,126? This causes large 
hole in wm.mgz But there are other hypointensities, for example at 96,77,151.
Does not your problematic spot correspond to some pathology?

Regards,

Antonin


Bruce,

Main problem area that I can see is at coordinates [104,42,124].My first 
attempt, I don't think I had the recon editing box checked when
I was editing the white matter, but I used a brush value of 255. My
second attempt I painted over the same voxels but with the recon editing
box checked.

Both times, after saving wm.mgz I ran the following command:
"recon-all -autorecon2-wm -autorecon3 -subjid my_subject -sd `pwd`"
Only thing different from the guide is I specify a different subject
directory.

Below are download links for the important files, let me know if you
would like to look at anything else. If you look at wm.mgz along with
the rh.white, you can see the surface doesn't appear to acknowledge my
edit.

001.mgz:
https://1drv.ms/u/s!AoOsIIayCH7qlxLBNvCT4JCvM1Kc

recon-all.logs.tar.gz:
https://1drv.ms/u/s!AoOsIIayCH7qlxRGOWpUCttk5Zji

brainmask+surf+wm.tar.gz
https://1drv.ms/u/s!AoOsIIayCH7qlxbDSS54gfHkq2M3

Thanks tremendously for your time,
Eli

> --
> 
> Message: 4
> Date: Wed, 1 Mar 2017 16:39:33 -0500 (EST)
> From: Bruce Fischl 
> Subject: Re: [Freesurfer] wm.mgz manual editing
> To: Freesurfer support list 
> Message-ID:
>   
>   >
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Eli
> 
> hmm, maybe you should just upload the subject and email us the voxel 
> coords you are talking about?
> 
> Also, in general it is hard for us to help you unless you include more 
> information. What exact command did you run? What was the screen output? 
> What was in the recon-all.log?
> 
> cheers
> Bruce
> 
> 
> On Wed, 1 
> Mar 2017, Rockers, Elijah D. wrote:
> 
> > Couple of questions:
> >
> > 1)
> >
> > I edited wm.mgz following the instructions in the wiki guide, but it did
> > not change anything after reconstruction. I am still using 5.3 right
> > now, so maybe the guide is wrong for me. What is the brush value
> > supposed to be? I used 255 but it did not extend the white matter
> > surface to include my edits. I checked to make sure they saved
> > correctly, they did, but the surface didn't change. Any ideas?
> >
> > 2)
> >
> > The reason I am editing wm.mgz is to try to include some cortex that was
> > left out of the pial surface. I don't suppose there's any way to fix
> > this without editing wm.mgz? Because the white matter surface actually
> > looks fine the way it is.
> >
> > Thanks,
> > Eli
> >
> > Houston Methodist. Leading Medicine.
> >___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

Re: [Freesurfer] recon-all exited with error.

[Antonin Skoch]

Dear Paul,

the slash problem prevents to properly create symbolic link to fsaverage in 
your SUBJECTS_DIR.

Then, the mri_label2label could not find the fsaverage label file since 
symbolic link for fsaverage does not exist, hence produces the error.log you 
are attaching.

Regards,

Antonin


Thanks Antonin. Also, I got this error.log file in my label folder. Do you
think it is due to the slash problem?
Best,
PaulOn Thu, Mar 2, 2017 at 4:38 PM, Antonin Skoch  wrote:

> Dear Paul,
>
> I suppose the clue is following messages from your recon-all.log file:
>
> FREESURFER_HOME /opt/freesurfer-6.0.0/freesurfer/
>
> and
>
>  cd /net/synapse/nt/mozzoude/processing/freesurfer/176_003_120326; ln -s 
> /opt/freesurfer-6.0.0/freesurfer//subjects/fsaverage; cd -
>
> ln: failed to create symbolic link './fsaverage': File exists
>
> The problem is that your FREESURFER_HOME contains slash in the end. Remove it 
> and rerun relevant part of recon-all. It should work then.
>
> Antonin
>
>
>
>
> Hello Freesurfer,
> I was running recon-all in steps (recon-all -autorecon1, recon-all
> -autorecon2, and recon-all - -T2 /T2 volume  -T2pial autorecon3). However,
> it exited with error during the BA_exvivo labels part of autorecon3 (please
> see attached recon-all.log file). Please, how can I fix it? Thanks
> Best,
> Paul___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

Re: [Freesurfer] recon-all exited with error.

[Antonin Skoch]

Dear Paul,

I suppose the clue is following messages from your recon-all.log file:

FREESURFER_HOME /opt/freesurfer-6.0.0/freesurfer/

and
 cd /net/synapse/nt/mozzoude/processing/freesurfer/176_003_120326; ln -s 
/opt/freesurfer-6.0.0/freesurfer//subjects/fsaverage; cd - 

ln: failed to create symbolic link './fsaverage': File exists

The problem is that your FREESURFER_HOME contains slash in the end. Remove it 
and rerun relevant part of recon-all. It should work then.

Antonin



Hello Freesurfer,
I was running recon-all in steps (recon-all -autorecon1, recon-all
-autorecon2, and recon-all - -T2 /T2 volume  -T2pial autorecon3). However,
it exited with error during the BA_exvivo labels part of autorecon3 (please
see attached recon-all.log file). Please, how can I fix it? Thanks
Best,
Paul___
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] Strange wm error

[Antonin Skoch]

Dear Mel,

if your recon in 5.3 version finished without error, there must be files 
lh.orig.nofix and rh.orig.nofix present in the subj_id/surf directory.
This type of error is most frequently due to incorrectly fixed topological 
defect. The original wm.mgz and orig.nofix errors can be quite a large distance 
from the area of your white surface error.
The fix you are referring to (editing the wm.mgz) makes perfect sense in this 
context.

Antonin



That does not make sense. Can you run this subject in v6? If the problem 
goes away, then there is not much we can do about it in 5.3
On 02/28/2017 05:27 AM, Melanie Ganz wrote:
> Hi Doug,
>
> the orig looks fine and we cannot see a file orig.nofix in the subject 
> dirs. We still use v5.3.
>
> But what we tried now for another similar subject was to remove 
> falsely labelled white matter in dura which was far away, but that 
> fixed the white matter errors so far inside the brain. Does that make 
> any sense to you why that helps?
>
> Cheers,
> Mel
>
>
>
> On 27-02-2017 5:23, Douglas Greve wrote:
>>
>> Hi Mel, how does the orig or orig.nofix look?
>>
>>
>> On 2/24/17 9:21 AM, Melanie Ganz wrote:
>>> Dear list,
>>>
>>> we are experiencing a strange wm surface error that we are not quite 
>>> sure about how to fix. The errors is at a location where the wm.mgz 
>>> look absolutely fine as well as the brainmask.mgz. Also the 
>>> intensities in the norm.mgz look fine.
>>>
>>> Please find 6 pics showing the error highlighted by the cursor on 
>>> the brainmask.mgz and the wm.mgz in all three views.
>>>
>>> Cheers,
>>> Mel___
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 v6.0 in an AWS cloud configuration (hipposubfield/brainstem failures)

[Antonin Skoch]

Dear Randy,

from the log file you provided it seems that both of your jobs exited on the 
insufficient RAM. You should check your available RAM resources.

brainstem-structures:

std::bad_alloc

hippocampal subfiels:

Out of memory.

Regards,

Antonin




Hello FreeSurfer Experts/Community,


I  am currently working with NITRC (as a novice user) to build and  investigate 
the operability of FreeSurfer v6.0 in their Computational  Environment 
(NITRC-CE).


We have been able to get a "recon-all" run to work, but we are failing to get 
the sub-calls 
-hippocampal-subfields-T1
https://surfer.nmr.mgh.harvard.edu/fswiki/HippocampalSubfields 
-brainstem-structures
https://surfer.nmr.mgh.harvard.edu/fswiki/BrainstemSubstructures 

... to run correctly / run to completion.  We are aware that Matlab Runtime 
needed to be installed, and a partial completion is a testament to that.


However, they seem to choke near the end, and it would be good to get some 
insight as to why.  To wit, I am pasting the last dozen or so lines from each 
(see below) in the hopes we might get a tip or a comment from this forum.


For this exercise, we used an ADNI subject (N3-corrected, downloaded from 
ADNI/LONI as *.nii)


The syntax/command I used was:


recon-all -s ADNI_003_S_2374_m00 \
-i 
$SUBJECTS_DIR/ADNI_003_S_2374__MRI_m00__EMCI-EMCI__20110506__S108554_I235638.nii
 \
-all -hippocampal-subfields-T1 -brainstem-structures  





I'm simply not sure if there's something wrong with my syntax or if there is 
something else we're missing.  Any help would be greatly appreciated, and I can 
pass on what is shared to my developer (and so that eventually everyone might 
begin to have a vetted version of v6.0 using NITRC-CE if they wish in the 
future)



-Randy





From:

/scripts/brainstem-structures 



___





<<>>



Resolution level 3 iteration 3 deformation iterations 8
Did one deformation step of max. 1.6685e-05 voxels in 8.485 seconds

minLogLikelihoodTimesPrior =

   7.5772e+06

Resolution level 3 iteration 3 deformation iterations 9
Did one deformation step of max. 5.3959e-05 voxels in 3.4185 seconds

minLogLikelihoodTimesPrior =

   7.5772e+06

Resolution level 3 iteration 3 deformation iterations 10
Did one deformation step of max. 0 voxels in 6.782 seconds

minLogLikelihoodTimesPrior =

   7.5772e+06

maximalDeformation is too small; stopping
Fitting mesh to image data mask took 919.7675 seconds
numberOfLabels: 21
Rasterizing mesh...here: 21
here2: 21
done
Error using kvlGEMSMatlab
std::bad_alloc

Error in kvlRasterizeAtlasMesh (line 11)



Error in segmentSubject (line 1151) 





__

<<>>__

__










From:

/scripts/hippocampal-subfields-T1


___

<<>>
  

Making alveus map to reduced label 3
--
Making Left-Lateral-Ventricle map to reduced label 4
--
Making hippocampal-fissure map to reduced label 5
--
Making Left-Pallidum map to reduced label 6
--
Making Left-Putamen map to reduced label 7
--
Making Left-Caudate map to reduced label 8
--
Making Left-Thalamus-Proper map to reduced label 9
--
Making Left-choroid-plexus map to reduced label 10
--
Making Left-VentralDC map to reduced label 11
--
Making Left-Accumbens-area map to reduced label 12
--
Making Unknown map to reduced label 13
Computing hyperparameters for estimation of Gaussian parameters
Estimating typical intensities of  alveus
numberOfLabels: 13
Rasterizing mesh...here: 13
here2: 13
done
Error using double
Out of memory. Type HELP MEMORY for your options.

Error in segmentSubjectT1_autoEstimateAlveusML (line 834)



MATLAB:nomem 


__
<<>>___
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] Creating custom aparc.a2009s+aseg.mgz: Shuffled names of parcellations after mris_label2annot

[Antonin Skoch]

Dear Doug,

I am using quite recent dev version built 8/2/2017.

mris_label2annot of this version is following:

$Id: mris_label2annot.c,v 1.20 2016/01/07 23:28:11 greve

Regards,

Antonin


what version are you using? I thought I fixed the missing-last-label 
problem in v6
On 03/01/2017 06:42 PM, Antonin Skoch wrote:
> Dear Doug,
>
> thank you, adding  --no-unknown indeed fixed the global shuffling of 
> the label names. However, last line of .ctab seems not to be read this 
> time and produced .annot does not contain perirhinal label.
>
> My modified .ctab file looks like this:
>
>  0  Unknown   0   0   00
>   1  G&S_frontomargin 23 220  600
>   2  G&S_occipital_inf23  60 1800
>   3  G&S_paracentral  63 100  600
>   4  G&S_subcentral   63  20 2200
>   5  G&S_transv_frontopol 13   0 2500
>   6  G&S_cingul-Ant   26  60   00
>   7  G&S_cingul-Mid-Ant   26  60  750
>   8  G&S_cingul-Mid-Post  26  60 1500
>   9  G_cingul-Post-dorsal 25  60 2500
>  10  G_cingul-Post-ventral60  25  250
>  11  G_cuneus180  20  200
>  12  G_front_inf-Opercular   220  20 1000
>  13  G_front_inf-Orbital 140  60  600
>  14  G_front_inf-Triangul180 220 1400
>  15  G_front_middle  140 100 1800
>  16  G_front_sup 180  20 1400
>  17  G_Ins_lg&S_cent_ins  23  10  100
>  18  G_insular_short 225 140 1400
>  19  G_occipital_middle  180  60 1800
>  20  G_occipital_sup  20 220  600
>  21  G_oc-temp_lat-fusifor60  20 1400
>  22  G_oc-temp_med-Lingual   220 180 1400
>  23  G_oc-temp_med-Parahip65 100  200
>  24  G_orbital   220  60  200
>  25  G_pariet_inf-Angular 20  60 2200
>  26  G_pariet_inf-Supramar   100 100  600
>  27  G_parietal_sup  220 180 2200
>  28  G_postcentral20 180 1400
>  29  G_precentral 60 140 1800
>  30  G_precuneus  25  20 1400
>  31  G_rectus 20  60 1000
>  32  G_subcallosal60 220  200
>  33  G_temp_sup-G_T_transv60  60 2200
>  34  G_temp_sup-Lateral  220  60 2200
>  35  G_temp_sup-Plan_polar65 220  600
>  36  G_temp_sup-Plan_tempo25 140  200
>  37  G_temporal_inf  220 220 1000
>  38  G_temporal_middle   180  60  600
>  39  Lat_Fis-ant-Horizont 61  20 2200
>  40  Lat_Fis-ant-Vertical 61  20  600
>  41  Lat_Fis-post 61  60 1000
>  42  Medial_wall  25  25  250
>  43  Pole_occipital  140  20  600
>  44  Pole_temporal   220 180  200
>  45  S_calcarine  63 180 1800
>  46  S_central   221  20  100
>  47  S_cingul-Marginalis 221  20 1000
>  48  S_circular_insula_ant   221  60 1400
>  49  S_circular_insula_inf   221  20 2200
>  50  S_circular_insula_sup61 220 2200
>  51  S_collat_transv_ant 100 200 2000
>  52  S_collat_transv_post 10 200 2000
>  53  S_front_inf 221 220  200
>  54  S_front_middle  141  20 1000
>  55  S_front_sup  61 220 1000
>  56  S_interm_prim-Jensen141  60  200
>  57  S_intrapariet&P_trans   143  20 2200
>  58  S_oc_middle&Lunatus 101  60 2200
>  59  S_oc_sup&transversal 21  20 1400
>  60  S_occipital_ant  61  20 1800
>  61  S_oc-temp_lat   221 140  200
>  62  S_oc-temp_med&Lingual   141 100 2200
>  63  S_orbital_lateral   221 100  200
>  64  S_orbital_med-olfact181 200  200
>  65  S_orbital-H_Shaped  101  20  200
>  66  S_parieto_occipital 101 100 1800
>  67  S_pericallosal  181 220  200
>  68  S_postcentral21 140 2000
>  69  S_precentral-inf-part21  20 2400
>  70  S_precentral-sup-part21  20 2000
>  71  S_suborbital 21  20  600
>  72  S_subparietal   101  60  600
>  73  S_temporal_inf 

Re: [Freesurfer] Creating custom aparc.a2009s+aseg.mgz: Shuffled names of parcellations after mris_label2annot

[Antonin Skoch]

the rhinal labels into 
that. Do you see any pitfall with that?

In any case, however, before running aparc2aseg I have to cope with another 
problem with rhinal labels - the rhinal.thresh labels are overlapping and I 
would need to correctly assign vertices in the label intersection (see my 
previous post 
http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51919.html ).

Regards,

Antonin


Try adding --no-unknown to the label2annot command line
On 02/28/2017 04:45 PM, Antonin Skoch wrote:
> Dear experts,
>
> I would like to create modified aparc.a2009s+aseg file with relevant 
> parts of parahippocampal cortical ribbon voxel labels replaced by 
> labels derived from surface labels of entorhinal and parahippocampal 
> cortex (created also by default in recon-all). This modified 
> aparc.a2009s+aseg file I want to use for streamline assignment in 
> structural connectome generation in MrTrix3.
>
> I think that mri_label2vol is not optimal way to do it since it would 
> leave some voxels in the ribbon unassigned.
>
> I think that the better, but much complicated, way to do this is to 
> modify aparc.a2009s.annot with the information from these labels and 
> then run again mris_aparc2aseg.
>
> I tried to do this by using:
>
> mri_annotation2label
>
> and
>
> mris_label2annot --hemi lh --subject my_subject --ldir my_labels --a 
> my_aparc.a2009s --ctab my_aparc.annot.a2009s.ctab --debug
>
> I took the  aparc.annot.a2009s.ctab from the my_subject/label 
> directory and added to the end 2 row with entorrhinal and perirhinal 
> parcellations with unique RGB values to assure the relevant parts of 
> parahippocampal gyrus label are replaced by these new labels I want to 
> supply.
>
> But the resulting new .annot file is not correct - the labels are in 
> correct position on cortical surfaces, but the label names of all 
> labels are shuffled.
>
> I even tried the sequence of mri_annotation2label, mris_label2annot 
> without adding new labels, just converting annotation to labels and 
> back, and the annotation naming is also corrupted.
>
> I also tried to create new annotation just from 2 new labels, 
> preparing .ctab file and running mris_label2annot by explicitly 
> specifying my 2 labels like
>
> mris_label2annot --hemi lh --subject my_subject --l 
> lh_labels/lh.perirhinal_exvivo.thresh.label --l 
> lh_labels/lh.entorhinal_exvivo.thresh.label --a rhinal_aparc.a2009s 
> --debug --ctab rhinal_aparc.annot.a2009s.ctab
>
> In this case the label names in annotation are swapped (entorhinal is 
> perirhinal and vice versa), swapped are also file names of labels 
> which I tried to back convert by using mri_annotation2label.
>
> I am using quite recent build of dev version of Freesurfer from 
> 28/2/2017.
>
> Could you suggest where could be the problem?
>
> Or could you advice different, possibly more simple way, how to 
> achieve my goal?
>
> Thank you in advance.
>
> Regards,
>
> Antonin Skoch
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

[Freesurfer] threshold method used to obtain *exvivo.thresh.labels

[Antonin Skoch]

Dear experts,

Could you please provide me the information how exactly the 
*_exvivo.thresh.labels have been thresholded?

According to this post, 
http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg32542.html
.thresh labels are thresholded to pick the most likely vertices that give a 
label that is 
the right surface area.But how they are thresholded in the boundary of the 
region where the unthresholded labels do not overlap? There must be additional 
threshold applied:
For example for BA45 there is no further BA label towards frontal pole, but the 
BA45_exvivo.thresh.label is also restricted in this region wrt 
BA45_exvivo.label.

I have further question concerning used thresholding method of 
perirhinal_exvivo.thresh and entorhinal_exvivo.thresh labels. It seems that 
this method is not applied here since looking at them at the fsaverage surface, 
they are overlapping. And also *rhinal_exvivo.labels are much more extending to 
the adjacent regions than *rhinal_exvivo.thresh.labels. What method is applied 
here?

My main objective to obtain annotation with the vertices properly assigned to 
perirhinal_exvivo and entorhinal_exvivo to supply this annotation to 
mri_aparc2aseg to assign ribbon voxels to that parcellation. I think I could 
use mris_label2annot --maxstatswinner with unthresholded entorhinal and 
perirhinal labels to assign vertices to most probable label, but I would need 
to further threshold the labels by correct value to obtain results similar in 
extent to thresh.labels.

For perirhinal, it seems that the additional threshold is 0.4 (what is 
rationale for this value?), for entorhinal it seems also around 0.4 but could 
not find any particular threshold to obtain the exact shape of label 
corresponding to entorhinal_exvivo.thresh.

Thank you in advance for clarification.

Regards,

Antonin Skoch

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


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

Re: [Freesurfer] multiple expert options files/ wm and control points

[Antonin Skoch]

Dear Paul,

1) You find pretty thoroughful info on expert options file here:
https://surfer.nmr.mgh.harvard.edu/fswiki/recon-all#ExpertPreferences

2) recon-all -autorecon2-cp -autorecon3 is ok (btw -autorecon2-cp and 
-autorecon2-wm runs the same commands, at least in version 6.0).

3) There is in the souce code following comment on -T option in mri_fill:
 min # of neighbors which must be on to retain a point 
Default value is 1.

Regards,

Antonin


Hello Freesurfer,
I have couple questions.
1) If I have 2 commands (e.g., mri_normalize -a 30 and mris_inflate -n 30)
and I want recon-all to execute both commands. Should I create 2 different
expert opts files or 1 expert opts file with both commands in it? Also, how
do I include the expert flag with recon?
2) If I have added control points and wm edits to a subject, it is accurate
to start from control points? i.e., recon-all -autorecon2-cp -autorecon3
3) Lastly, I am playing around with mri_fill command and I did like to know
what -T flag does?
Thank you
Best,
Paul
___
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] Creating custom aparc.a2009s+aseg.mgz: Shuffled names of parcellations after mris_label2annot

[Antonin Skoch]

Dear experts,

I would like to create modified aparc.a2009s+aseg file with relevant parts of 
parahippocampal cortical ribbon voxel labels replaced by labels derived from 
surface labels of entorhinal and parahippocampal cortex (created also by 
default in recon-all). This modified aparc.a2009s+aseg file I want to use for 
streamline assignment in structural connectome generation in MrTrix3.

I think that mri_label2vol is not optimal way to do it since it would leave 
some voxels in the ribbon unassigned.

I think that the better, but much complicated, way to do this is to modify 
aparc.a2009s.annot with the information from these labels and then run again 
mris_aparc2aseg.

I tried to do this by using:

mri_annotation2label

and

mris_label2annot --hemi lh --subject my_subject --ldir my_labels --a 
my_aparc.a2009s --ctab my_aparc.annot.a2009s.ctab --debug

I took the  aparc.annot.a2009s.ctab from the my_subject/label directory and 
added to the end 2 row with entorrhinal and perirhinal parcellations with 
unique RGB values to assure the relevant parts of parahippocampal gyrus label 
are replaced by these new labels I want to supply.

But the resulting new .annot file is not correct - the labels are in correct 
position on cortical surfaces, but the label names of all labels are shuffled.  

I even tried the sequence of mri_annotation2label, mris_label2annot without 
adding new labels, just converting annotation to labels and back, and the 
annotation naming is also corrupted.

I also tried to create new annotation just from 2 new labels, preparing .ctab 
file and running mris_label2annot by explicitly specifying my 2 labels like

mris_label2annot --hemi lh --subject my_subject --l 
lh_labels/lh.perirhinal_exvivo.thresh.label --l 
lh_labels/lh.entorhinal_exvivo.thresh.label --a rhinal_aparc.a2009s --debug 
--ctab rhinal_aparc.annot.a2009s.ctab

In this case the label names in annotation are swapped (entorhinal is 
perirhinal and vice versa), swapped are also file names of labels which I tried 
to back convert by using mri_annotation2label.

I am using quite recent build of dev version of Freesurfer from 28/2/2017. 

Could you suggest where could be the problem? 

Or could you advice different, possibly more simple way, how to achieve my goal?

Thank you in advance.

Regards,

Antonin Skoch


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


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

Re: [Freesurfer] ACPC alignment before or after running on Freesurfer?

[Antonin Skoch]

Dear Kristine,

I am currently experimenting with prepending PreFreeSurferPipeline.sh to 
recon-all (of HCP pipelines https://github.com/Washington-University/Pipelines 
) which does APCP alignment, robust FOV (cropping of unrelevant parts of image 
FOV - neck etc.), bias correction and (optionally) FNIRT-based skullstrip and 
gradient nonlinearity correction.

I believe that ACPC alignment could prevent Talairach registration 
errors/inaccuracies in recon-all which could have profound effect on subsequent 
skullstrip and subcortical labeling (it could at least prevent to disastrous 
errors which some other users reported recently, such as this: 
http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51789.html). This 
could also help to mutual registration of data of multiple sessions (i.e. in 
longitudinal studies) to compensate different head positioning.

It  could be also beneficial to use FNIRT-based skullstrip to help (or even to 
replace) freesurfer's skullstrip (as is it done in FreeSurferPipeline.sh of HCP 
pipelines), since, to my experience, the inaccurate skullstrip is basis of most 
errors in FreeSurfer reconstruction stream.
This FNIRT skullstrip works fine with our high-quality data from 64-channel 
coil acquired by protocol similar to Human connectome project (I ocasionally 
find only several, probably negligible amount of voxels of gray matter 
cut-out), but not as good with older data where significant parts of gray 
matter are often cut-out.

The drawback is that when you want to get to the original space, you have to 
account one more transformation and there is one more step in processing 
pipeline you need to check.

This is my view based on current experience. I would also greatly appreciate 
any comment (different perspective) of other users. 

Regards,

Antonin



Dear Freesurfer team,

This may sound like a bit of a small question, but I could not find any exact 
answer elsewhere.Does the exact orientation of the input image have much effect 
on the accuracy 
of the segmentation in Freesurfer?
It seems that some people apply ACPC alignment to the output of Freesurfer, so 
I am confused as to which order would be optimal.


Thank you in advance,
Kristine

___
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] bbregister vs spmregister vs mri_coreg

[Antonin Skoch]

Dear Doug,

thank you for the feedback. In this context I would like to ask you to share 
your opinion on the mri_cvs_register. This tool should be far the most accurate 
for the registration to MNI, than any of affine-based registration tools, 
shouldn't be? Are there any pitfalls/disadvantages (apart from huge demand on 
computing resources) of using this tool? Since you mentioned that you usually 
use mni152reg, could you share the reason why do not use mri_cvs_register as 
the preferential tool for registration to MNI?

Regards,

Antonin


I have not actually tested it on the mni152 reg. It might (probably  does) work 
fine. On 2/25/17 5:33 PM, Antonin Skoch wrote:
Dear Doug,

I was wondering, why do you prefer mni152reg to mri_coreg for  gregistration to 
MNI? According to help, mri_coreg is also able to do  12 DOF registration. 
Antonin



mri_coreg is the FS implementation of spm_coreg (spmregister) both of  which 
use normalized mutual info. bbregister uses the BBR cost  function and is 
preferred for all MRI. For registration to MNI space,  we usually use mni152reg 
(a wrapper around fsl's flirt) On 2/25/17 8:49 AM, John Anderson wrote:
Dear Freesurfer experts,
I see that the tool "mri_coreg" has been implemented recently in Free  Surfer 6 
and I really wanted to know what are the differences between  the registration 
tools "bbregister", " spmregister" and "mri_coreg"!  Kindly: 1. Are these tools 
similar? if not what are the differences ?
2. Is there any preference of using a tool over the others for  specific type 
of data. For example: A. If I want to register FA map to  T1 image which tool 
is more robust? B. if I want to register FA map to  MNI space which tool is 
more robust? I highly appreciate your input on this!

John


___
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] Overestimation of volume in Hippocampus

[Antonin Skoch]

Dear  Michel,

not sure if I understand. Do you mean that you cropped your T2 to FOV 256 mm ?

I think that this should have no effect until you cropped parts of the brain. 

Maybe, as a part of quality-check you can check whether your T2 is correctly 
registered to T1 by inspection

T1_to_.v10.QC.gif

as stated in
https://surfer.nmr.mgh.harvard.edu/fswiki/HippocampalSubfields

Antonin

Dear Antonin,

Thank you for the assistance!
I really appreciate it.
My final goal is to determine the volume of the dentate gyrus however I first 
wanted to establish if the volume of the whole hippocampus was within expected 
boundaries before moving on to the dentate gyrus. Do you perhaps know if 
forcing the field of view to 256 would affect the segmentation because the T2 
scans have a FOV of 320?Sincerely,
Michel Hu




Van: freesurfer-boun...@nmr.mgh.harvard.edu 
 namens Antonin Skoch 
Verzonden: maandag 27 februari 2017 13:27
Aan: freesurfer@nmr.mgh.harvard.edu
Onderwerp: Re: [Freesurfer] Overestimation of volume in Hippocampus

Dear Michel,

by default in the recon-all the input images are resampled to 1x1x1mm3. To 
disable this and retain your resolution, you have to add -hires flag (and adapt 
the mris_inflate -n parameter).

This could improve the segmentation results, however I would not expect that it 
is the reason of volume overestimation you are refering to. I am not expert at 
hippocampal anatomy, therefore I cannot comment on your results.

But I am guessing, maybe the hippocampal atlas in FreeSurfer includes some 
portions which have not been included in the MCI studies you refer to? Maybe 
you can find answer in the Hippocampal subfields paper:

http://www.nmr.mgh.harvard.edu/~iglesias/pdf/subfieldsNeuroimage2015preprint.pdf

Antonin



Dear Antonin,

I did use the T2 scan for the T2pial refinement during the recon-all however I
actually already preformed the hippocampal subfields and when i looked at the
txt file generated from that the results are quite similar.
I used the multispectral segmentation.
I didn't not use the -hires flag but what does this flag exactly do if i may
ask?

Sincerely,

Michel Hu



Van: freesurfer-boun...@nmr.mgh.harvard.edu
 namens Antonin Skoch 
Verzonden: maandag 27 februari 2017 12:31
Aan: freesurfer@nmr.mgh.harvard.edu
Onderwerp: Re: [Freesurfer] Overestimation of volume in Hippocampus


Dear Michel,

Given your resolution 0.8x0.8x0.8, did you run recon-all with -hires flag? What
did you used T2 image for? As a -T2pial refinement? T2 image is not used for
hippocampal segmentation in standard recon-all stream.
But pay attention that with -hires you also have to alter default value for
mris_inflate, as specified here
http://freesurfer.net/fswiki/SubmillimeterRecon
In my case -n was not enough, I would recommend -n 50 (more does not do any
harm).

In any case, I would recommend to try hippocampal subfields module.

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

This should be more precise than "standard" aseg segmentation and given you
have also 3D T2, multispectral T1 and T2 segmentation can be used.

Antonin Skoch


Dear Shane,

I have checked the aseg.mgz and in only one I would say the segmentation failed
however the others look fine and I'm taking the measurements from the text file
that is generated from the aseg.stats.
Should I redo the recon-all with a different input? I have always given
freesurfer T1 and a T2 scan to process  both having a resolution of 0.8x0.8x0.8
mm.

Sincerely,
Michel Hu



Van: freesurfer-boun...@nmr.mgh.harvard.edu
 namens Shane S

Verzonden: maandag 27 februari 2017 11:15
Aan: Freesurfer support list
Onderwerp: Re: [Freesurfer] Overestimation of volume in Hippocampus

Hi Michel Hu,

Yes, that’s too large for MCI or even controls for that matter I think. Have
you checked the aseg.mgz? I generally find that the hippocampus is well
segmented, even in patients with a lot of atrophy.

Are you taking the measurements with the asegstats2table?

Sincerely,

--
Shane S


On 27 February 2017 at 10:12:09, Michel Hu (a...@live.nl<mailto:a...@live.nl>)
wrote:

Dear Shane,

I apologize for not being clear. The reported value is of only one half of the
hippocampus.
I have only run 4 subjects of the 75 however they all have a reported value of
between 6000 to 1 mm^3 summed together for the hippocampus.

Sincerely,
Michel Hu



Van: freesurfer-boun...@nmr.mgh.harvard.edu
 namens Shane S

Verzonden: maandag 27 februari 2017 11:00
Aan: Freesurfer support list
Onderwerp: Re: [Freesurfer] Overestimation of volume in Hippocampus

Hi Michel Hu,

Is that a summed value of left and right hippocampus? That seems normal to me
since averaged total hippocamppal volumes for MCI have been typically reported
at around 2500-3500mm3.

Thanks,
--
Shane S


On 27 February 2017 at 09:44:27, Michel

Re: [Freesurfer] Overestimation of volume in Hippocampus

[Antonin Skoch]

Dear Michel,

by default in the recon-all the input images are resampled to 1x1x1mm3. To 
disable this and retain your resolution, you have to add -hires flag (and adapt 
the mris_inflate -n parameter).

This could improve the segmentation results, however I would not expect that it 
is the reason of volume overestimation you are refering to. I am not expert at 
hippocampal anatomy, therefore I cannot comment on your results. 

But I am guessing, maybe the hippocampal atlas in FreeSurfer includes some 
portions which have not been included in the MCI studies you refer to? Maybe 
you can find answer in the Hippocampal subfields paper:

http://www.nmr.mgh.harvard.edu/~iglesias/pdf/subfieldsNeuroimage2015preprint.pdf

Antonin


Dear Antonin,

I did use the T2 scan for the T2pial refinement during the recon-all however I 
actually already preformed the hippocampal subfields and when i looked at the 
txt file generated from that the results are quite similar.
I used the multispectral segmentation.
I didn't not use the -hires flag but what does this flag exactly do if i may 
ask?Sincerely,

Michel Hu



Van: freesurfer-boun...@nmr.mgh.harvard.edu 
 namens Antonin Skoch 
Verzonden: maandag 27 februari 2017 12:31
Aan: freesurfer@nmr.mgh.harvard.edu
Onderwerp: Re: [Freesurfer] Overestimation of volume in Hippocampus


Dear Michel,

Given your resolution 0.8x0.8x0.8, did you run recon-all with -hires flag? What 
did you used T2 image for? As a -T2pial refinement? T2 image is not used for 
hippocampal segmentation in standard recon-all stream.
But pay attention that with -hires you also have to alter default value for 
mris_inflate, as specified here
http://freesurfer.net/fswiki/SubmillimeterRecon
In my case -n was not enough, I would recommend -n 50 (more does not do any 
harm).

In any case, I would recommend to try hippocampal subfields module.

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

This should be more precise than "standard" aseg segmentation and given you 
have also 3D T2, multispectral T1 and T2 segmentation can be used.

Antonin Skoch


Dear Shane,

I have checked the aseg.mgz and in only one I would say the segmentation failed
however the others look fine and I'm taking the measurements from the text file
that is generated from the aseg.stats.
Should I redo the recon-all with a different input? I have always given
freesurfer T1 and a T2 scan to process  both having a resolution of 0.8x0.8x0.8
mm.

Sincerely,
Michel Hu



Van: freesurfer-boun...@nmr.mgh.harvard.edu
 namens Shane S

Verzonden: maandag 27 februari 2017 11:15
Aan: Freesurfer support list
Onderwerp: Re: [Freesurfer] Overestimation of volume in Hippocampus

Hi Michel Hu,

Yes, that’s too large for MCI or even controls for that matter I think. Have
you checked the aseg.mgz? I generally find that the hippocampus is well
segmented, even in patients with a lot of atrophy.

Are you taking the measurements with the asegstats2table?

Sincerely,

--
Shane S


On 27 February 2017 at 10:12:09, Michel Hu (a...@live.nl<mailto:a...@live.nl>)
wrote:

Dear Shane,

I apologize for not being clear. The reported value is of only one half of the
hippocampus.
I have only run 4 subjects of the 75 however they all have a reported value of
between 6000 to 1 mm^3 summed together for the hippocampus.

Sincerely,
Michel Hu



Van: freesurfer-boun...@nmr.mgh.harvard.edu
 namens Shane S

Verzonden: maandag 27 februari 2017 11:00
Aan: Freesurfer support list
Onderwerp: Re: [Freesurfer] Overestimation of volume in Hippocampus

Hi Michel Hu,

Is that a summed value of left and right hippocampus? That seems normal to me
since averaged total hippocamppal volumes for MCI have been typically reported
at around 2500-3500mm3.

Thanks,
--
Shane S


On 27 February 2017 at 09:44:27, Michel Hu (a...@live.nl<mailto:a...@live.nl>)
wrote:

Dear Freesurfer experts,

I have run several subjects through the recon-all pipeline including the
hippocampal segmentation with freesurfer 6.0 on Ubuntu 16.04. However when
looking at the text file with the volumes it seems that all the numbers are
bigger than normal as all my subjects have MCI and freesurfer reports them
having all over 5000 mm^3. I was wondering if the problem could lie somewhere
in the recon-all process?
Thank you for your time

Sincerely,
Michel Hu

___
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

Re: [Freesurfer] Overestimation of volume in Hippocampus

[Antonin Skoch]

Dear Michel,

Given your resolution 0.8x0.8x0.8, did you run recon-all with -hires flag? What 
did you used T2 image for? As a -T2pial refinement? T2 image is not used for 
hippocampal segmentation in standard recon-all stream.
But pay attention that with -hires you also have to alter default value for 
mris_inflate, as specified here
http://freesurfer.net/fswiki/SubmillimeterRecon
In my case -n was not enough, I would recommend -n 50 (more does not do any 
harm).
 
In any case, I would recommend to try hippocampal subfields module. 

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

This should be more precise than "standard" aseg segmentation and given you 
have also 3D T2, multispectral T1 and T2 segmentation can be used.

Antonin Skoch


Dear Shane,

I have checked the aseg.mgz and in only one I would say the segmentation failed 
however the others look fine and I'm taking the measurements from the text file 
that is generated from the aseg.stats.
Should I redo the recon-all with a different input? I have always given 
freesurfer T1 and a T2 scan to process  both having a resolution of 0.8x0.8x0.8 
mm.Sincerely,
Michel Hu



Van: freesurfer-boun...@nmr.mgh.harvard.edu 
 namens Shane S 

Verzonden: maandag 27 februari 2017 11:15
Aan: Freesurfer support list
Onderwerp: Re: [Freesurfer] Overestimation of volume in Hippocampus

Hi Michel Hu,

Yes, that’s too large for MCI or even controls for that matter I think. Have 
you checked the aseg.mgz? I generally find that the hippocampus is well 
segmented, even in patients with a lot of atrophy.

Are you taking the measurements with the asegstats2table?

Sincerely,

--
Shane S


On 27 February 2017 at 10:12:09, Michel Hu (a...@live.nl<mailto:a...@live.nl>) 
wrote:

Dear Shane,

I apologize for not being clear. The reported value is of only one half of the 
hippocampus.
I have only run 4 subjects of the 75 however they all have a reported value of 
between 6000 to 1 mm^3 summed together for the hippocampus.

Sincerely,
Michel Hu



Van: freesurfer-boun...@nmr.mgh.harvard.edu 
 namens Shane S 

Verzonden: maandag 27 februari 2017 11:00
Aan: Freesurfer support list
Onderwerp: Re: [Freesurfer] Overestimation of volume in Hippocampus

Hi Michel Hu,

Is that a summed value of left and right hippocampus? That seems normal to me 
since averaged total hippocamppal volumes for MCI have been typically reported 
at around 2500-3500mm3.

Thanks,
--
Shane S


On 27 February 2017 at 09:44:27, Michel Hu (a...@live.nl<mailto:a...@live.nl>) 
wrote:

Dear Freesurfer experts,

I have run several subjects through the recon-all pipeline including the 
hippocampal segmentation with freesurfer 6.0 on Ubuntu 16.04. However when 
looking at the text file with the volumes it seems that all the numbers are 
bigger than normal as all my subjects have MCI and freesurfer reports them 
having all over 5000 mm^3. I was wondering if the problem could lie somewhere 
in the recon-all process?
Thank you for your time

Sincerely,
Michel Hu___
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] Fw: PETsurfer mri_coreg problem

[Antonin Skoch]

Dear Paul,

I think that the transform window in freeview opens by default to enable manual 
refinement of registration if needed.

If you are not sure, try also tkregister2. It should work to simply replace 
tkregisterfv by tkregister2, the command would be

tkregister2 --mov your_moveable --targ your_target --reg your_lta 

or, if you registered your PET to freesurfer-processed subject and want also to 
display surfaces, you should use tkregister2, no tkregisterfv  (according to 
the freeview warning). The command in this case would be

tkregister2 --mov your_moveable --s your_subject_id --reg your_lta --surfs

Antonin



Hello Antonin, 
Thank  you for your quick reply. Does this mean I should close the transform  
window when it opens? The alignment looks good to me, I was worried  because 
the transform window opened and the info on the terminal window.  I haven't 
used tkregister2 before. Do I replace tkregisterfv with  tkregister2 like this 
" tkregister2 --mov template.nii.gz --reg  template.reg.lta --surfs"?  ‎Thanks. 
Best, 
Paul

   
Sent from my BlackBerry 10 smartphone.  


   
  
From: Antonin Skoch
Sent: Sunday, February 26, 2017 3:50 PM
To: freesurfer@nmr.mgh.harvard.edu
Reply To: Freesurfer support list
Subject: Re: [Freesurfer] Fw: PETsurfer mri_coreg problem
Dear Paul,

LTA means transformation matrix stored in .lta format.

This matrix can encode transformation between various coordinate spaces. 

What  coordinate systems transform this .lta from and to is specified by  
string in the .lta file. Typically this type could be vox2RAS, RAS2vox,  
vox2vox or RAS2RAS. Most typically the type is vox2vox.

The explanation of coordinate systems is specified for example here:
http://freesurfer.net/fswiki/CoordinateSystems
http://www.grahamwideman.com/gw/brain/fs/coords/fscoords.htm

The  output of freeview is only info, not error, indicating that your .lta  is 
not of type vox2vox. I personally still use tkregister2 for checking  of 
registration, since the freeview does not contain full functionality  for 
checking transformations (see the warning).  Therefore I have no  experience 
with tkregisterfv and consider tkregister2 still as a "gold  standard". 
However, if you use tkregisterfv for checkning transformation  between volumes 
and the output is only "info", I would guess that  everything is OK and you do 
not need to be bothered. 

Btw, does the alignment of the images seem reasonable? How does it look in 
tkregister2?

Regards,

Antonin___
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] Fw: PETsurfer mri_coreg problem

[Antonin Skoch]

Dear Paul,

LTA means transformation matrix stored in .lta format.

This matrix can encode transformation between various coordinate spaces. 

What coordinate systems transform this .lta from and to is specified by string 
in the .lta file. Typically this type could be vox2RAS, RAS2vox, vox2vox or 
RAS2RAS. Most typically the type is vox2vox.

The explanation of coordinate systems is specified for example here:
http://freesurfer.net/fswiki/CoordinateSystems
http://www.grahamwideman.com/gw/brain/fs/coords/fscoords.htm

The output of freeview is only info, not error, indicating that your .lta is 
not of type vox2vox. I personally still use tkregister2 for checking of 
registration, since the freeview does not contain full functionality for 
checking transformations (see the warning).  Therefore I have no experience 
with tkregisterfv and consider tkregister2 still as a "gold standard". However, 
if you use tkregisterfv for checkning transformation between volumes and the 
output is only "info", I would guess that everything is OK and you do not need 
to be bothered. 

Btw, does the alignment of the images seem reasonable? How does it look in 
tkregister2?

Regards,

Antonin



___
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] editing topological defect

[Antonin Skoch]

Dear Shane,

the "topological defect" in FreeSurfer jargon means that the estimated surface 
contains errors like "holes" or "handles".

See

PPT from FreeSurfer course 
http://surfer.nmr.mgh.harvard.edu/pub/docs/freesurfer.failure_modes.ppt
or
https://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/TroubleshootingData

XL (=extra large?) defect often means large error in previous steps of 
recon-all, usually skullstrip or white matte segmentation. In some cases the 
error is automatically corrected, but not always.

To see, what is happening, I would suggest to inspect brainmask.mgz or wm.mgz 
and correct errors.

You can also find more information on the forum, there are quite large amount 
of posts related to topological defects.
For example:
http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg30763.html

Antonin Skoch


Hi Freesurfer Team,

I am running recon-all on Freesurfer version 6. A few of my subjects have “XL 
defect detected …” and their recon-all have been running for more than 20 
hours. I hope this is not a silly question, but will this XL defect be 
corrected eventually…? Another question, what are “defects”? Is there anything 
I could do to the raw 
T1 before recon-all?

Thanks!

Shane
___
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] Mindboggle official software release and publication!

[Antonin Skoch]

Dear experts,

I was wondering what is your opinion on the fact, that, according to the 
mindboggle paper

http://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1005350

it is beneficial to use ANTS volume-based gray matter segmentation to refine 
gray matter segmentation in FreeSurfer.

I am not expert in ANTS but looking at the ANTS code it seems to me that the 
ANTS routine does not do anything more than the volume-based nonlinear 
registration to the template and intensity and probabilistic atlas-based voxel 
labeling. Therefore, the method is in principle identical to GCA volume-based 
labeling (mri_ca_register and mri_ca_label, part of recon-all) in FreeSurfer 
which also produces cortical gray matter mask, far not so precise as the 
segmentation based on pial and white surface estimation.

I think that FreeSurfer pipeline for estimation of white and pial surfaces is 
much more sophisticated and precise than any method using volume-based 
registration and volume-based labeling by intensity and anatomical priors. 

The FreeSurfer gray matter underestimation showed in figure 2 of the paper
http://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1005350#pcbi-1005350-g002
seems to me like either partial-volume effect or skull-strip error (which cuts 
out part of gray matter) which can be corrected by proper inspection and manual 
correction of brainmask.mgz. In contrast, the errors in presented ANTS gray 
matter segmentation in figure 2 are much more severe, spanning not only the 
blue encircled region.

I would very appreciate your expert opinion on this.

Regards,

Antonin Skoch




Announcing the official release of Mindboggle (http://mindboggle.info),
open source software <http://mindboggle.info/software.html> and data
<https://osf.io/ydyxu/> for analyzing the shapes of brain structures from
human MRI data (processed through FreeSurfer and optionally through ANTs).
The release coincides with a publication in PLoS Computational Biology that
documents and evaluates the software:Klein A, Ghosh SS, Bao FS, Giard J, Hame 
Y, Stavsky E, Lee N, Rossa B,
Reuter M, Neto EC, Keshavan A. (2017) Mindboggling morphometry of human
brains. PLoS Computational Biology 13(3): e1005350.
doi:10.1371/journal.pcbi.1005350
<http://doi.org/10.1371/journal.pcbi.1005350>

Cheers,
@rno


___
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] bbregister vs spmregister vs mri_coreg

[Antonin Skoch]

Dear Doug,

I was wondering, why do you prefer mni152reg to mri_coreg for gregistration to 
MNI? According to help, mri_coreg is also able to do 12 DOF registration.

Antonin



mri_coreg is the FS implementation of spm_coreg (spmregister) both of  which 
use normalized mutual info. bbregister uses the BBR cost function  and is 
preferred for all MRI. For registration to MNI space, we usually  use mni152reg 
(a wrapper around fsl's flirt) On 2/25/17 8:49 AM, John Anderson wrote:
Dear Freesurfer experts,
I see that the tool "mri_coreg" has been implemented recently in Free  Surfer 6 
and I really wanted to know what are the differences between  the registration 
tools "bbregister", " spmregister" and "mri_coreg"!  Kindly: 1. Are these tools 
similar? if not what are the differences ?
2. Is there any preference of using a tool over the others for  specific type 
of data. For example:A. If I want to register FA map to T1 image 
which tool is  more robust?B. if I want to register FA map to MNI 
space which tool is  more robust? 
I highly appreciate your input on this!

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