Re: [Freesurfer] PETSurfer individual atlas for subcortocal segmentation

[Boris Rauchmann]

External Email - Use Caution

Did you already have the time to look at the logfile? Do you have any 
suggestions how to proceed?

Thank you!

> Am 02.12.2019 um 19:18 schrieb Boris Rauchmann :
> 
> 
> In this example tried it with only the subcortical segmentations from my 
> atlas. Please find the logfile attached. It gives me back: "tissue type is 
> not set" but I set it to 2 in the LUT.txt
> 
> In principle look the following commands right to you?
> 
> xcerebralseg --s 0120test --o apas+head+subcort_BN.mgz --m 
> BN_Atlas_subcotex.mgz --atlas BN_Atlas_subcortex.gca
> 
> gtmseg --s 0120test --head apas+head+subcort_BN.mgz --ctab subcort_BN_LUT.txt 
> --o gtmseg+subcort_BN.mgz
> 
> Ideally I would have a gtmseg with both, the subcortical and the cortical 
> structures, but only the subcortical would also be fine as long as I can get  
> mri_gtmpvc running on it. 
> 
> Thanks,
> Boris
> 
>> On Mon, Dec 2, 2019 at 5:31 PM Greve, Douglas N.,Ph.D. 
>>  wrote:
>> Can you send the log file for each of the gtmseg runs?
>> 
>>> On 11/26/2019 1:09 PM, Boris Rauchmann wrote:
>>> External Email - Use Caution
>>> 
>>> Thank you! I have a gca for subcortical  and two gcs (lh/rh) for cortical 
>>> structures. 
>>> I created an annot (rh/lh) and a mgz using mris_ca_label and mri_ca_label 
>>> for parcellation/segmentation stats. 
>>> 
>>> For the PET analysis I have the following problem:
>>> 
>>> If I use this command: gtmseg --s test --o test.mgz --ctab 
>>> /xyz/BN_Atlas_246_LUT.txt --head BN_Atlas_subcotex.mgz --ctx-annot 
>>> BN_Atlas.annot --ctab '/xyz/BN_Atlas_246_LUT.txt' 
>>> 
>>> It gives me the right regions for subcortical structures but it looks like 
>>> it uses the standard FS parcellation with my labels for the cortical 
>>> parcellations (only 93 cortical regions instead of 210). 
>>> 
>>> If I use gtmseg --s 0059test --o onlyhead.gtmseg_test.mgz --ctx-annot 
>>> BN_Atlas.annot --ctab '/xyz/BN_Atlas_246_LUT.txt' --no-xcerseg I get all my 
>>> 210 cortical parcellations but the standard FS subcortical segmentations. 
>>> 
>>> How can I use both in one gtmseg so that I can proceed with it doing my PET 
>>> analysis in PETSurfer? It is not totally clear for me what to merge using 
>>> xcerebralseg.
>>> 
>>> Thanks a lot!
>>> 
 On Mon, Nov 18, 2019 at 8:28 PM Greve, Douglas N.,Ph.D. 
  wrote:
 It gets the subcortical from apas+head.mgz which gets created along the 
 way by xcerebralseg. You can create your own with xcerebralseg by 
 specifying your volume as the mergevol. I think this will work, but I'm 
 not sure. I'm assuming you've used the GCA to create your own 
 subcortical seg for the given subject
 
 On 11/5/19 1:06 PM, Boris Rauchmann wrote:
 >
 > External Email - Use Caution
 >
 > I just realized that the above mentioned command (gtmseg --s XYZ --o 
 > BN.gtmseg.mgz --ctx-annot BN_Atlas.annot --ctab 
 > '/media/XYZ/BN_Atlas_freesurfer/BN_Atlas_246_LUT.txt' --no-xcerseg) 
 > gives me only the cortical segmentation. Is there any way to also 
 > include the subcortical segmentation based on my individual atlas? I 
 > also have an Atlas_subcortex.gca file available.
 >
 > Best,
 > Boris
 >
 > On Tue, Aug 13, 2019 at 5:10 PM Greve, Douglas N.,Ph.D. 
 > mailto:dgr...@mgh.harvard.edu>> wrote:
 >
 > There is no cut off for the minimum size. As it gets smaller, the PVC
 > noise amplification will become bigger (it also depends on the
 > shape as
 > well).
 >
 > I think the --no-xcerseg is the right way to go now
 >
 > On 8/13/19 11:00 AM, Boris Rauchmann wrote:
 > >
 > > External Email - Use Caution
 > >
 > > Thank you for your prompt answer - the command worked. This is the
 > > atlas mentioned: http://atlas.brainnetome.org/brainnetome.html
 > > What is approximately the smallest possible segment when using PVC?
 > > Also, does the exclusion of extracerebral structures harm? I
 > used that
 > > flag because it complained:
 > >
 > > gtmseg --s XYZ --o BN.gtmseg.mgz --ctx-annot BN_Atlas.annot --ctab
 > > '/media/XYZ/BN_Atlas_freesurfer/BN_Atlas_246_LUT.txt'
 > > ERROR: /media/subjects/XYZ/mri/apas+head.mgz exists. This is ok
 > > but you must indicate whether to use what is there (--no-xcerseg)
 > > or create a new one and overwrite what is there (--xcerseg)
 > > or specify your own headseg (--head)
 > >
 > > and did not want to override my apas+head.mgz
 > >
 > > Thanks,
 > > Boris
 > >
 > > On Tue, Aug 13, 2019 at 4:44 PM Greve, Douglas N.,Ph.D.
 > > mailto:dgr...@mgh.harvard.edu>
 > >>
 > wrote:
 > >
 > > I don't 

Re: [Freesurfer] topological defect error

[Bruce Fischl]

I guess I would try adding control points to the wm in the region that is 
darker


On Thu, 5 Dec 2019, Laurel Quinlan wrote:



External Email - Use Caution

Thanks Bruce! I will chat with my supervisor about uploading the brain to the 
ftp site, but for now, I
can see intensity issues on the brain.mgz volume. The area being excluded from 
segmentation is darker
and the R frontal region is hyperintense. 

Would this be a case to try mri_normalize?

-Laurel


From: Bruce Fischl 
Sent: Thursday, December 5, 2019 3:40 PM
To: Laurel Quinlan 
Cc: Freesurfer support list 
Subject: Re: [Freesurfer] topological defect error  
Hi Laurel

do you want to upload this subject to our ftp site and we can take a
look? Alternatively you can overlay the wm.mgz as a heatmap on top of the
  brain.mgz with the ?h.orig surface overlaid so you can see where it is
missing stuff and why
Bruce


On
Thu, 5 Dec 2019, Laurel Quinlan wrote:

>
> External Email - Use Caution
>
> Thank you!
>
> Attached are two screenshots of the filled.mgz view and the lh.orig.nofix 
view. The cerebellum doesn't
> seem to be the problem, and both hemispheres are distinguished. Additionally, 
the brainmask does not
> show this defect. All of the brain is included in the brainmask.
>
> How can I get FS to recognize that the missing portion of brain is gray/white 
matter that should be
> included in the pial line?
>
> Thanks!
>
> -Laurel
>
>
>___
_
> From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of
Bruce
> Fischl 
> Sent: Tuesday, December 3, 2019 11:57 AM
> To: Freesurfer support list 
> Subject: Re: [Freesurfer] topological defect error  
> it might also be the hemispheres not being separated, hard to tell
> (although that almost never happens). You can look at the filled.mgz to
> check this (the hemis should have different labels)
> On Tue, 3 Dec 2019,
> Greve, Douglas N.,Ph.D. wrote:
>
> > Look at the lh.orig.nofix and see if you can find the defect. Also, look at 
it in the volume and the
> > surface views. Might be cerebellum
> >
> > On 12/3/2019 11:30 AM, Laurel Quinlan wrote:
> >
> >   External Email - Use Caution
> >
> >   Hi Freesurfer Support,
> >
> > One of my colleagues receives the following error after running a recon:
> >
> > exited with errors: "excessive topologic defect encountered: could not 
allocate 289309485 edges
> > for retessellation"
> >
> > I checked the inflated view and there does appear to be significant 
portions of the brain missing
> > (however I cannot see this in 2D). I've attached a screenshot of the 
inflated view. 
> >
> > How would I go about fixing the error? 
> >
> > Thank you!
> >
> > Laurel Quinlan
> > Associate Research Specialist
> > Center for Healthy Minds
> > University of Wisconsin-Madison
> >
> >
> > ___
> > 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] topological defect error

[Bruce Fischl]

Hi Laurel

do you want to upload this subject to our ftp site and we can take a 
look? Alternatively you can overlay the wm.mgz as a heatmap on top of the
 brain.mgz with the ?h.orig surface overlaid so you can see where it is 
missing stuff and why

Bruce


On 
Thu, 5 Dec 2019, Laurel Quinlan wrote:




External Email - Use Caution

Thank you!

Attached are two screenshots of the filled.mgz view and the lh.orig.nofix view. 
The cerebellum doesn't
seem to be the problem, and both hemispheres are distinguished. Additionally, 
the brainmask does not
show this defect. All of the brain is included in the brainmask.

How can I get FS to recognize that the missing portion of brain is gray/white 
matter that should be
included in the pial line?

Thanks!

-Laurel



From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Bruce
Fischl 
Sent: Tuesday, December 3, 2019 11:57 AM
To: Freesurfer support list 
Subject: Re: [Freesurfer] topological defect error  
it might also be the hemispheres not being separated, hard to tell
(although that almost never happens). You can look at the filled.mgz to
check this (the hemis should have different labels)
On Tue, 3 Dec 2019,
Greve, Douglas N.,Ph.D. wrote:

> Look at the lh.orig.nofix and see if you can find the defect. Also, look at 
it in the volume and the
> surface views. Might be cerebellum
>
> On 12/3/2019 11:30 AM, Laurel Quinlan wrote:
>
>   External Email - Use Caution
>
>   Hi Freesurfer Support,
>
> One of my colleagues receives the following error after running a recon:
>
> exited with errors: "excessive topologic defect encountered: could not 
allocate 289309485 edges
> for retessellation"
>
> I checked the inflated view and there does appear to be significant portions 
of the brain missing
> (however I cannot see this in 2D). I've attached a screenshot of the inflated 
view. 
>
> How would I go about fixing the error? 
>
> Thank you!
>
> Laurel Quinlan
> Associate Research Specialist
> Center for Healthy Minds
> University of Wisconsin-Madison
>
>
> ___
> 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] Reporting Results in a three group analysis

[cody samth]

External Email - Use Caution

Thanks for the help!

On Wed, Dec 4, 2019 at 6:47 PM Greve, Douglas N.,Ph.D. <
dgr...@mgh.harvard.edu> wrote:

> Yes, but threshold it first, eg
> mri_binarize --abs --i sig.cluster.mgh --min .01 --o newmask.mgh
>
> On 12/4/19 1:38 PM, cody samth wrote:
> >
> > External Email - Use Caution
> >
> > Thanks, for your input. It's interesting that there isn't a more
> > standard way of approaching it. If i wanted to constrain my post-hoc
> > to be within the cluster(s) from the main effect how would I go about
> > running this through mri_glmfit? Would I include the --mask
> > sig.cluster.mgh in the command for mri_glmfit and then aslo
> > mri_glmfit-sim?
> >
> > On Mon, Dec 2, 2019 at 6:40 PM Greve, Douglas N.,Ph.D.
> > mailto:dgr...@mgh.harvard.edu>> wrote:
> >
> > I don't think there is a standard way to do this. A vertex-wise
> > analysis is not the same thing as a averaging over a group of
> > vertices. I guess you could constrain your post-hoc analysis to be
> > within the main effect cluster; that would be most consistent. But
> > I don't think you'd have any problems getting it published either
> way.
> >
> > On 12/2/2019 3:12 PM, cody samth wrote:
> >>
> >> External Email - Use Caution
> >>
> >> Hi,
> >>
> >> I have a statistical question about how to approach reporting
> >> results from FreeSurfer analyses containing three groups. I ran a
> >> group effect (F-test) and then post-hoc tests looking at
> >> pair-wise comparisons between the three groups. My question is
> >> why is that we run separate vertex-wise analyses for the
> >> post-hocs rather than extracting the values from significant
> >> clusters and running post-hocs in a statistical software for just
> >> the regions where a significance difference was found (ie the
> >> clusters)? As a post-hoc vertex wide analysis can lead to
> >> different results.
> >>
> >> For example in my group effect contrasts I found a cluster in the
> >> parietal lobe. Whereas in my post hoc-vertex wide analyses one of
> >> them found two clusters 1) within the parietal 2) within the
> >> frontal lobe. If I choose to run these post-hoc analyses via
> >> freesurfer (ie vertex-wise) rather than extracting the results to
> >> analyze in a statistical program, is it standard to report the
> >> second cluster? Even though it didn't come up in the group model?
> >> If so is there a paper that people reference that uses this
> approach?
> >>
> >> Thanks,
> >> Cody
> >>
> >> ___
> >> Freesurfer mailing list
> >> Freesurfer@nmr.mgh.harvard.edu   Freesurfer@nmr.mgh.harvard.edu>
> >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> >
> > ___
> > Freesurfer mailing list
> > Freesurfer@nmr.mgh.harvard.edu  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
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] surfaceholes in aseg.stats

[Bruce Fischl]

Hi Laurel

yes, the lh.orig.nofix is created using the control points and other 
things, and so the number of holes in it will definitely change if the 
placement of control points changes


cheers
Bruce
On Thu, 5 Dec 2019, Laurel Quinlan 
wrote:




External Email - Use Caution

Hi Doug,

Thank you! Yes, their control point edits were different. Are the number of 
?h.orig.nofix defects
calculated after reconstruction with control point edits?

-Laurel


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of
Greve, Douglas N.,Ph.D. 
Sent: Tuesday, December 3, 2019 2:16 PM
To: freesurfer@nmr.mgh.harvard.edu 
Subject: Re: [Freesurfer] surfaceholes in aseg.stats  
Those are the number of defects in the ?h.orig.nofix. Not sure why the two 
people see different numbers.
Are you totally sure they are being run in exactly the same way? If they made 
different edits (control
points, brain mask) then it could result in different number of holes

On 12/3/2019 2:38 PM, Laurel Quinlan wrote:

  External Email - Use Caution

  Hi Freesurfer Support,

I'm wondering how ?h.surfaceholes prior to fixing and "Total number of defect 
holes in surfaces
prior to fixing" are calculated in the aseg.stats file for each brain. I 
compared aseg.stats files
for the same brain edited by two different people, and I noticed that there 
were different numbers
of holes listed for each person, despite the brain being the same.  

For example:
lhSurfaceHoles 130 vs 61
rhSurfaceHoles 102 vs 80
Total number of defect holes 232 vs 141
Why would those numbers be so different?

Thanks,

Laurel Quinlan
Associate Research Specialist
Center for Healthy Minds
University of Wisconsin-Madison


___
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] surfaceholes in aseg.stats

[Laurel Quinlan]

External Email - Use Caution

Hi Doug,

Thank you! Yes, their control point edits were different. Are the number of 
?h.orig.nofix defects calculated after reconstruction with control point edits?

-Laurel

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

Sent: Tuesday, December 3, 2019 2:16 PM
To: freesurfer@nmr.mgh.harvard.edu 
Subject: Re: [Freesurfer] surfaceholes in aseg.stats

Those are the number of defects in the ?h.orig.nofix. Not sure why the two 
people see different numbers. Are you totally sure they are being run in 
exactly the same way? If they made different edits (control points, brain mask) 
then it could result in different number of holes

On 12/3/2019 2:38 PM, Laurel Quinlan wrote:

External Email - Use Caution

Hi Freesurfer Support,

I'm wondering how ?h.surfaceholes prior to fixing and "Total number of defect 
holes in surfaces prior to fixing" are calculated in the aseg.stats file for 
each brain. I compared aseg.stats files for the same brain edited by two 
different people, and I noticed that there were different numbers of holes 
listed for each person, despite the brain being the same.

For example:
lhSurfaceHoles 130 vs 61
rhSurfaceHoles 102 vs 80
Total number of defect holes 232 vs 141

Why would those numbers be so different?

Thanks,

Laurel Quinlan
Associate Research Specialist
Center for Healthy Minds
University of Wisconsin-Madison




___
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] Study specific template

[Greve, Douglas N.,Ph.D.]

We currently do not have a mac build of mri_aparc2aseg, and we recommend
downloading the freesurfer dev release to resolve this issue.



On 12/5/19 1:00 PM, Joshi, Nandita wrote:
>  External Email - Use Caution
>
> Thank you so much for that! The README file instructs to download 
> make_average_subject and platform specific mri_aparc2aseg. However, the mac 
> version of mri_aparc2aseg is missing in the patch. Could it be possible to 
> download it from elsewhere?
>
> - Nandita
>   
>   
>
> On 12/5/19, 12:49 PM, "freesurfer-boun...@nmr.mgh.harvard.edu on behalf of 
> Greve, Douglas N.,Ph.D."  dgr...@mgh.harvard.edu> wrote:
>
>  USE CAUTION: External Message.
>  
>  See the REAME file here
>  
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__surfer.nmr.mgh.harvard.edu_pub_dist_freesurfer_6.0.0-2Dpatch_=DwIGaQ=shNJtf5dKgNcPZ6Yh64b-A=Bk3PG21nu20V-TX_S982zJE-KkrgCuPol41Dhbe_0mI=HRcVNlmwdK9YHH6teQ4oW9oc6SDFzz79TS63mOlbWIY=6p4504imNdnEktx-WXKqAlxMvMCQ1EYnJW_deB2CAWI=
>  
>  
>  On 12/5/19 11:47 AM, Joshi, Nandita wrote:
>  >
>  > External Email - Use Caution
>  >
>  > Hello,
>  >
>  > I am trying to make a study specific template based on the
>  > instructions at:
>  > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__surfer.nmr.mgh.harvard.edu_fswiki_SurfaceRegAndTemplates=DwIGaQ=shNJtf5dKgNcPZ6Yh64b-A=Bk3PG21nu20V-TX_S982zJE-KkrgCuPol41Dhbe_0mI=HRcVNlmwdK9YHH6teQ4oW9oc6SDFzz79TS63mOlbWIY=LmIaVqBLyDekwkZsc46m3nOdn25B7E96m_UuRzDu3Ew=
>  >
>  > However, on running the first step:
>  >
>  > make_average_subject --out newtemplate --subjects subj1 subj2 subj3 ...
>  >
>  > I get an error while running the recon-all is trying to run the aparc
>  > to aseg step:
>  >
>  > #@# AParc-to-ASeg aparc Thu Dec5 11:29:33 EST 2019
>  >
>  > /Users/nandita/FreeSurfer_recon/newtemplate
>  >
>  > \n mri_aparc2aseg --s newtemplate --volmask --aseg aseg.presurf.hypos
>  > --relabel mri/norm.mgz mri/transforms/talairach.m3z
>  > /Applications/freesurfer/average/RB_all_2016-05-10.vc700.gca
>  > mri/aseg.auto_noCCseg.label_intensities.txt \n
>  >
>  > relabeling unlikely voxels interior to white matter surface:
>  >
>  > norm: mri/norm.mgz
>  >
>  > XFORM: mri/transforms/talairach.m3z
>  >
>  > GCA: /Applications/freesurfer/average/RB_all_2016-05-10.vc700.gca
>  >
>  > label intensities: mri/aseg.auto_noCCseg.label_intensities.txt
>  >
>  > SUBJECTS_DIR /Users/nandita/FreeSurfer_recon
>  >
>  > subject newtemplate
>  >
>  > outvol /Users/nandita/FreeSurfer_recon/newtemplate/mri/aparc+aseg.mgz
>  >
>  > useribbon 0
>  >
>  > baseoffset 0
>  >
>  > RipUnknown 0
>  >
>  > Reading lh white surface
>  >
>  > /Users/nandita/FreeSurfer_recon/newtemplate/surf/lh.white
>  >
>  > Reading lh pial surface
>  >
>  > /Users/nandita/FreeSurfer_recon/newtemplate/surf/lh.pial
>  >
>  > Loading lh annotations from
>  > /Users/nandita/FreeSurfer_recon/newtemplate/label/lh.aparc.annot
>  >
>  > reading colortable from annotation file...
>  >
>  > colortable with 36 entries read (originally
>  > 
> /Users/nandita/FreeSurfer_recon/newtemplate/label/tmpdir.annot2std.41916/seg.1.100110189.ctab)
>  >
>  > Reading rh white surface
>  >
>  > /Users/nandita/reeSurfer_recon/newtemplate/surf/rh.white
>  >
>  > Reading rh pial surface
>  >
>  > /Users/nandita/FreeSurfer_recon/newtemplate/surf/rh.pial
>  >
>  > Loading rh annotations from
>  > /Users/nandita/ADRC/FreeSurfer_recon/newtemplate/label/rh.aparc.annot
>  >
>  > reading colortable from annotation file...
>  >
>  > colortable with 36 entries read (originally
>  > 
> /Users/nandita/FreeSurfer_recon/newtemplate/label/tmpdir.annot2std.47059/seg.1.100110189.ctab)
>  >
>  > Have color table for lh white annotation
>  >
>  > Have color table for rh white annotation
>  >
>  > Loading ribbon segmentation from
>  > /Users/nandita/FreeSurfer_recon/newtemplate/mri/ribbon.mgz
>  >
>  > Building hash of lh white
>  >
>  > Building hash of lh pial
>  >
>  > Building hash of rh white
>  >
>  > Building hash of rh pial
>  >
>  > Loading aseg from
>  > /Users/nandita/FreeSurfer_recon/newtemplate/mri/aseg.presurf.hypos.mgz
>  >
>  > ASeg Vox2RAS: ---
>  >
>  > -1.0 0.0 0.0 128.0;
>  >
>  > 0.0 0.0 1.0-128.0;
>  >
>  > 0.0-1.0 0.0 128.0;
>  >
>  > 0.0 0.0 0.0 1.0;
>  >
>  > mghRead(mri/norm.mgz, -1): could not open file
>  >
>  > -
>  >
>  > Labeling Slice
>  >
>  > relabeling unlikely voxels in interior of white matter
>  

Re: [Freesurfer] Multiple comparison using Monte Carlo

[Ting Li]

External Email - Use Caution

Dear Dr. Douglas,

Thank you so much!

Best regards,
Ting

On Thu, Dec 5, 2019 at 11:45 AM Greve, Douglas N.,Ph.D. <
dgr...@mgh.harvard.edu> wrote:

> I've attached a couple of papers
>
> On 12/3/19 9:24 PM, Ting Li wrote:
> >
> > External Email - Use Caution
> >
> > Dear Dr. Douglas,
> >
> > Thank you so much.
> >
> > I have difficulty to understand z map is essentially an infinite # of
> > subjects.
> > Before smooth, there is no GLM analysis. Does the smooth include in
> > the GLM process?
> >
> > Best regards,
> > Ting
> >
> > On Tue, Dec 3, 2019 at 2:14 PM Greve, Douglas N.,Ph.D.
> > mailto:dgr...@mgh.harvard.edu>> wrote:
> >
> >
> >
> > On 12/3/2019 1:36 PM, Ting Li wrote:
> >>
> >> External Email - Use Caution
> >>
> >> Dear Dr. Douglas,
> >>
> >> Thank  you so much for all the answers. I have two more questions.
> >>
> >> 1, When the Monte Carlo simulation is doing, how does one
> >> simulation is done?
> >>
> >>   * synthesize z map (synthesize z map for how many subjects?)
> >>
> > The Z is essentailly an infinite # of subjects (it is just a
> > single map).
> >>
> >>   * smooth z map (You have mentioned the FWHM comes from an
> >> estimate from the residuals of the analysis, which analysis?
> >> or the way we process the real data with the command
> >> mris_preproc with FWHM value? )
> >>
> > The GLM analysis, from the residual.
> >>
> >>   * threshold z map (Does it mean a GLM analysis so we can have
> >> threshold z map?)
> >>
> > No, the z-map is synthesized directly
> >
> > The simulation is done in mri_glmfit-sim and in mri_mcsim.
> >
> >> 2, When we reference to the CSD files in freesurfer, will it
> >> correct the cluster size p-value based on DOF (degree of
> >> freedom), like the t-ratios table including a DOF? Thanks a lot!
> > I don't know what you mean.
> >>
> >> Best regards,
> >> Ting
> >>
> >> On Mon, Dec 2, 2019 at 1:59 PM Greve, Douglas N.,Ph.D.
> >> mailto:dgr...@mgh.harvard.edu>> wrote:
> >>
> >> Correct. This is no different than, eg, a t-test. Look in
> >> the back of a stats book from the 1950s and you will find a
> >> table of t-ratios and corresponding p-values. Obviously, they
> >> did not have access to any of the data being analyzed
> >> today:), but the tables are still valid.
> >>
> >> On 12/2/2019 2:03 PM, Ting Li wrote:
> >>>
> >>> External Email - Use Caution
> >>>
> >>> Dear Dr. Douglas,
> >>>
> >>> Thank you so much for your detailed response.
> >>>
> >>> The simulation here is to get the probability of a maximum
> >>> cluster that size or larger in the cached CSD files. It
> >>> checks the probability of  the cluster size but have nothing
> >>> to do with the analysis metrics that I have used. Do I
> >>> understand correctly?
> >>>
> >>> Best regards,
> >>> Ting Li
> >>>
> >>> On Mon, Dec 2, 2019 at 11:57 AM Greve, Douglas N.,Ph.D.
> >>> mailto:dgr...@mgh.harvard.edu>>
> wrote:
> >>>
> >>>
> >>>
> >>> On 12/2/2019 11:58 AM, Ting Li wrote:
> 
>  External Email - Use Caution
> 
>  Dear Dr. Douglas,
> 
>  Thank you so much for your quick response! You saved my
>  half life.
> 
>  From the introduction of clusterwise correction for
>  multiple comparisons, I have a few questions.
> 
>  1, What is the null hypothesis here ?
> >>> In the tutorial, the null hypothesis is that there is no
> >>> effect of age (age slope = 0)
>  2, What is a z map? Do you mean synthesize cortical
>  datasets?
> >>> A z-map is just a map where all the values are from a
> >>> gaussian distribution with mean=0 and stddev=1. This
> >>> just assigns a random z-value to each vertex on fsaverage
>  3. Smooth z map, what FWHM do you use, if it is not
>  consistent with my FWHM, how will it affect the results?
> >>> The FWHM comes from an estimate from the residuals of
> >>> the analysis. The residuals are everything that does not
> >>> fit the linear model and represent noise. We use the
> >>> residuals to estimate the underlying smoothness (FWHM),
>  4, Threshold z map, what does level mean? Does it mean
>  the vertex p-value?
> >>> Basically, it is the vertex p-value, but we use  the
> >>> "sig" = -log10(p). You also have to specify the sign. If
> >>> you have an a priori hypothesis about the direction,
> >>> then you can specify pos (positive) or neg (negative).
> >>> 

Re: [Freesurfer] Study specific template

[Joshi, Nandita]

External Email - Use Caution

Thank you so much for that! The README file instructs to download 
make_average_subject and platform specific mri_aparc2aseg. However, the mac 
version of mri_aparc2aseg is missing in the patch. Could it be possible to 
download it from elsewhere?

- Nandita
 
 

On 12/5/19, 12:49 PM, "freesurfer-boun...@nmr.mgh.harvard.edu on behalf of 
Greve, Douglas N.,Ph.D."  wrote:

USE CAUTION: External Message.

See the REAME file here

https://urldefense.proofpoint.com/v2/url?u=ftp-3A__surfer.nmr.mgh.harvard.edu_pub_dist_freesurfer_6.0.0-2Dpatch_=DwIGaQ=shNJtf5dKgNcPZ6Yh64b-A=Bk3PG21nu20V-TX_S982zJE-KkrgCuPol41Dhbe_0mI=HRcVNlmwdK9YHH6teQ4oW9oc6SDFzz79TS63mOlbWIY=6p4504imNdnEktx-WXKqAlxMvMCQ1EYnJW_deB2CAWI=


On 12/5/19 11:47 AM, Joshi, Nandita wrote:
>
> External Email - Use Caution
>
> Hello,
>
> I am trying to make a study specific template based on the
> instructions at:
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__surfer.nmr.mgh.harvard.edu_fswiki_SurfaceRegAndTemplates=DwIGaQ=shNJtf5dKgNcPZ6Yh64b-A=Bk3PG21nu20V-TX_S982zJE-KkrgCuPol41Dhbe_0mI=HRcVNlmwdK9YHH6teQ4oW9oc6SDFzz79TS63mOlbWIY=LmIaVqBLyDekwkZsc46m3nOdn25B7E96m_UuRzDu3Ew=
>
> However, on running the first step:
>
> make_average_subject --out newtemplate --subjects subj1 subj2 subj3 ...
>
> I get an error while running the recon-all is trying to run the aparc
> to aseg step:
>
> #@# AParc-to-ASeg aparc Thu Dec5 11:29:33 EST 2019
>
> /Users/nandita/FreeSurfer_recon/newtemplate
>
> \n mri_aparc2aseg --s newtemplate --volmask --aseg aseg.presurf.hypos
> --relabel mri/norm.mgz mri/transforms/talairach.m3z
> /Applications/freesurfer/average/RB_all_2016-05-10.vc700.gca
> mri/aseg.auto_noCCseg.label_intensities.txt \n
>
> relabeling unlikely voxels interior to white matter surface:
>
> norm: mri/norm.mgz
>
> XFORM: mri/transforms/talairach.m3z
>
> GCA: /Applications/freesurfer/average/RB_all_2016-05-10.vc700.gca
>
> label intensities: mri/aseg.auto_noCCseg.label_intensities.txt
>
> SUBJECTS_DIR /Users/nandita/FreeSurfer_recon
>
> subject newtemplate
>
> outvol /Users/nandita/FreeSurfer_recon/newtemplate/mri/aparc+aseg.mgz
>
> useribbon 0
>
> baseoffset 0
>
> RipUnknown 0
>
> Reading lh white surface
>
> /Users/nandita/FreeSurfer_recon/newtemplate/surf/lh.white
>
> Reading lh pial surface
>
> /Users/nandita/FreeSurfer_recon/newtemplate/surf/lh.pial
>
> Loading lh annotations from
> /Users/nandita/FreeSurfer_recon/newtemplate/label/lh.aparc.annot
>
> reading colortable from annotation file...
>
> colortable with 36 entries read (originally
> 
/Users/nandita/FreeSurfer_recon/newtemplate/label/tmpdir.annot2std.41916/seg.1.100110189.ctab)
>
> Reading rh white surface
>
> /Users/nandita/reeSurfer_recon/newtemplate/surf/rh.white
>
> Reading rh pial surface
>
> /Users/nandita/FreeSurfer_recon/newtemplate/surf/rh.pial
>
> Loading rh annotations from
> /Users/nandita/ADRC/FreeSurfer_recon/newtemplate/label/rh.aparc.annot
>
> reading colortable from annotation file...
>
> colortable with 36 entries read (originally
> 
/Users/nandita/FreeSurfer_recon/newtemplate/label/tmpdir.annot2std.47059/seg.1.100110189.ctab)
>
> Have color table for lh white annotation
>
> Have color table for rh white annotation
>
> Loading ribbon segmentation from
> /Users/nandita/FreeSurfer_recon/newtemplate/mri/ribbon.mgz
>
> Building hash of lh white
>
> Building hash of lh pial
>
> Building hash of rh white
>
> Building hash of rh pial
>
> Loading aseg from
> /Users/nandita/FreeSurfer_recon/newtemplate/mri/aseg.presurf.hypos.mgz
>
> ASeg Vox2RAS: ---
>
> -1.0 0.0 0.0 128.0;
>
> 0.0 0.0 1.0-128.0;
>
> 0.0-1.0 0.0 128.0;
>
> 0.0 0.0 0.0 1.0;
>
> mghRead(mri/norm.mgz, -1): could not open file
>
> -
>
> Labeling Slice
>
> relabeling unlikely voxels in interior of white matter
>
> Segmentation fault
>
> Darwin Nanditas-MacBook-Pro.local 17.7.0 Darwin Kernel Version 17.7.0:
> Sun Jun2 20:31:42 PDT 2019; root:xnu-4570.71.46~1/RELEASE_X86_64 x86_64
>
> recon-all -s newtemplate exited with ERRORS at Thu Dec5 11:29:52 EST 2019
>
> On inspecting the mri folder, it seems the norm.mgz file has not been
> created at all. Looking at the flowchart of steps for the recon-all
> command, norm.mgz is supposed to be created in the CA Normalize step,
> which requires the talairach.lta in the newtemplate/mri/transforms
> folder, 

Re: [Freesurfer] negative SUVr using PETsurfer

[Greve, Douglas N.,Ph.D.]

Yea, not sure. It could be that the uptake in WM near the NAcc is 
somewhat less than average (GTM assumes constant throughout). If so, 
then the GTM would subtract too much from the NAcc in an attempt to 
remove the spill in from WM. This is more of a problem for amyoild and 
tau ligands because then tend not to have clear anatomical delineations, 
esp in WM.

On 12/3/19 9:24 AM, miracle ozzoude wrote:
>
> External Email - Use Caution
>
> Thanks Doug. we double checked the registration with gtm.seg.mgz and 
> it looks good. Also the uptake in Acc is not much smaller than other 
> regions and is pretty similar on both hemispheres so we are not sure 
> what could be causing this. Any suggestions much appreciated.
> Many thanks
>
> Paul
>
> On Mon, Dec 2, 2019 at 5:15 PM Greve, Douglas N.,Ph.D. 
> mailto:dgr...@mgh.harvard.edu>> wrote:
>
> It may or may not be something that needs to be fixed. The PVC is
> just a linear model where the regression coefficients are the
> uptake in each ROI. As with any model, it adjusts the regression
> coefs to minimize the error in the fit. If some end up being less
> than zero when you really expect all to be > 0, then this probably
> indicates an error in the (linear) model. This error could come
> from several sources. For example, the registration could be off.
> The PSF might not be right. Or the uptake might not be constant
> across the ROIs. You should definitely start by checking the
> registration. If the uptake in Nuc Acc is very small relative to
> other ROIs, then I would just leave it the way it is, ie, DON'T
> just set it to 0 when you go to a group analysis.
>
> On 12/2/2019 4:48 PM, miracle ozzoude wrote:
>>
>> External Email - Use Caution
>>
>> Hello Experts,
>>
>> I ran the PETsurfer pipeline using AV45 pet and performed pvc
>> using pons as reference point. When i looked at the gtm.stats.dat
>> file for one of my subjects, the SUVr for right and left
>> nucleus-accumbens areas were in the negative (left = -0.361;
>> right = -0.046).
>>
>> This is strange because SUVR shouldn't be negative. How do i go
>> about fixing this error? Below, is my pvc command.
>> mri_gtmpvc --i pet.nii --reg register.lta --psf 6 --seg
>> gtmseg.mgz --default--seg-merge --auto-mask PSF .01 --mgx .01 --o
>> subject_gtmpvc --rescale 174
>>
>> Thanks.
>>
>> Best,
>> Paul
>>
>> ___
>> 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


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

Re: [Freesurfer] T2 in recon-all: command to correct pial surfaces errors

[Greve, Douglas N.,Ph.D.]

The same one that you would use with the T1 stream, just make sure to 
include -T2pial

On 12/5/19 5:04 AM, Steve Petersen wrote:
>
> External Email - Use Caution
>
> Dear Freesurfer experts,
>
> I used t2 image as input in subjects that have already been processed 
> without them following the instructions of the website. Although pial 
> surface segmentation has improved there is still some error. After 
> edit the brainmask.mgz file in Freeview (recon edit option), what 
> command should I use  to correct the pial surfaces obtained after the 
> -T2pial flag?
>
> I tried to use the -autorecon-pial command to correct the edits but I 
> think that this command only takes into account the T1, is that right?
>
>
> Best regards,
>
>
>
> ___
> 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] Question on GLM - correlation

[Greve, Douglas N.,Ph.D.]

It does not create a file with a single voxel. Below, prv.mgz is meant 
to represent the file that has all the voxels/vertices. Once you know 
the vertex no you are interested in, you extract it with the pvrvtx line.

On 12/5/19 12:47 PM, Barletta, Valeria wrote:
> I did what you suggested in your previous email:
>
> > That does not have the pvr in it. You can extract the pvr for that
> > vertex and add it as a column to the X matrix with
> > pvr = fast_vol2mat(MRIread('pvr.mgz'));
> > pvrvtx = pvr(:,vertexno+1);
>
> Which file shall I look like for the single voxel?
>
>
> 
> *From:* Greve, Douglas N.,Ph.D. 
> *Sent:* Thursday, December 5, 2019 12:40 PM
> *To:* Barletta, Valeria ; Freesurfer 
> support list 
> *Subject:* Re: [Freesurfer] Question on GLM - correlation
>
>
> On 12/4/19 11:51 AM, Barletta, Valeria wrote:
> > Ok I did it and did not get any .mgh file as a result.
> Did what?
> >
> > At this point I wonder, what is the best model to check for
> > correlation between my continuous outcome CME.mgh and the continuous
> > variable ficvf.mgh?
> > Shall I include ficvf.mgh as a regressor (pvr) and use the Contrast  1
> > 0 0   or shall I use a completely different method?
> >
> > Thanks, sorry for the long interaction...
> > 
> > *From:* Greve, Douglas N.,Ph.D. 
> > *Sent:* Tuesday, December 3, 2019 3:18 PM
> > *To:* Barletta, Valeria ; Freesurfer
> > support list 
> > *Subject:* Re: [Freesurfer] Question on GLM - correlation
> > That does not have the pvr in it. You can extract the pvr for that
> > vertex and add it as a column to the X matrix with
> > pvr = fast_vol2mat(MRIread('pvr.mgz'));
> > pvrvtx = pvr(:,vertexno+1);
> >
> > ps. Please remember to post to the list
> >
> > On 12/3/2019 1:29 PM, Barletta, Valeria wrote:
> >> Ok done. This is the Xg.mat
> >> 1    29
> >>      1    44
> >>      1    38
> >>      1    47
> >>      1    34
> >>      1    25
> >>      1    30
> >>      1    22
> >>      1    52
> >>      1    31
> >>      1    37
> >>      1    42
> >>      1    28
> >>      1    39
> >>      1    44
> >>      1    44
> >>      1    32
> >>      1    32
> >>      1    36
> >>      1    47
> >>      1    52
> >> And the cond(Xg'*Xg) is again: 3.0555e+04
> >> Looks like there is no extra column for the pvr in the Xg.mat
> >>
> >>
> >> 
> 
> >> *From:* Greve, Douglas N.,Ph.D. 
> >> 
> >> *Sent:* Tuesday, December 3, 2019 11:03 AM
> >> *To:* Barletta, Valeria 
> >> ; Freesurfer support list
> >>  
> 
> >> *Subject:* Re: [Freesurfer] Question on GLM - correlation
> >> I'm not sure those condition numbers include the pvr. Try loading the
> >> Xg.mat into matlab and computing
> >> cond(Xg'*Xg)
> >> Make sure Xg has the extra column for the pvr
> >>
> >> On 12/3/2019 10:42 AM, Barletta, Valeria wrote:
> >>> Ok it worked.
> >>> So I tried with a non-zero vertex and I got:
> >>> Normalized matrix condition is 81.1382
> >>> Matrix condition is 30558.5
> >>> Found 149926 points in label.
> >>> Found 149926 voxels in mask
> >>> Saving mask to
> >>> 
> /autofs/space/lipari_001/users/valeria/NODDI/GLM//GLM_CME_ficvf_doug/rh_contrast-MS_CME_all_FIS_ICA1/mask.mgh
> >>> Reshaping mriglm->mask...
> >>> search space = 74490.928733
> >>> DOF = 18
> >>> Dumping voxel 1024 0 0 to
> >>> 
> /autofs/space/lipari_001/users/valeria/NODDI/GLM//GLM_CME_ficvf_doug/rh_contrast-MS_CME_all_FIS_ICA1/voxdump-1024-0-0
> >>>
> >>> ...and with a zero vertex and got:
> >>> Normalized matrix condition is 81.1382
> >>> Matrix condition is 30558.5
> >>> Found 149926 points in label.
> >>> Found 149926 voxels in mask
> >>> Saving mask to
> >>> 
> /autofs/space/lipari_001/users/valeria/NODDI/GLM//GLM_CME_ficvf_doug2/rh_contrast-MS_CME_all_FIS_ICA1/mask.mgh
> >>> Reshaping mriglm->mask...
> >>> search space = 74490.928733
> >>> DOF = 18
> >>> Dumping voxel 150252 0 0 to
> >>> 
> /autofs/space/lipari_001/users/valeria/NODDI/GLM//GLM_CME_ficvf_doug2/rh_contrast-MS_CME_all_FIS_ICA1/voxdump-150252-0-0
> >>>
> >>>
> >>>
> >>> 
> 
> >>> *From:* freesurfer-boun...@nmr.mgh.harvard.edu
> >>> 
> >>> 
> >>>  on behalf of Greve,
> >>> Douglas N.,Ph.D. 
> >>> 
> >>> *Sent:* Monday, December 2, 2019 2:56 PM
> >>> *To:* freesurfer@nmr.mgh.harvard.edu
> >>> 
> >>>  
> 
> >>> *Subject:* Re: [Freesurfer] Question on GLM - correlation
> >>> oh, sorry, did not see the pvr. It could very well be the pvr that
> >>> is causing the patchiness. Unfortunately, you have 

Re: [Freesurfer] Using pre-segmented results

[Greve, Douglas N.,Ph.D.]

If your WM volume is not conformed, you will need to conform it with
mri_convert yourwm.mgz --conform wm.mgz


On 12/5/19 4:24 AM, Jordi Huguet wrote:
>
> External Email - Use Caution
>
> Hi Douglas,
>
> I have followed the suggested approach, however I get an error related 
> to the dimensions of the WM volume (see log trace below).
>
> ... 
>
> Found wm edits: 23448857 deletes, 783317 fills
>
>  cp wm.mgz wm.seg.mgz
>
>
>  mri_segment -keep -mprage brain.mgz wm.seg.mgz
>
> preserving editing changes in output volume...
> doing initial intensity segmentation...
> using local statistics to label ambiguous voxels...
> computing class statistics for intensity windows...
> WM (104.0): 105.4 +- 6.0 [79.0 --> 125.0]
> GM (69.0) : 67.0 +- 10.5 [30.0 --> 95.0]
> setting bottom of white matter range to 77.5
> setting top of gray matter range to 88.0
> doing initial intensity segmentation...
> using local statistics to label ambiguous voxels...
> using local geometry to label remaining ambiguous voxels...
>
> reclassifying voxels using Gaussian border classifier...
>
> removing voxels with positive offset direction...
> smoothing T1 volume with sigma = 0.250
> removing 1-dimensional structures...
> thickening thin strands
> 20 segments, 7509 filled
> 8232 bright non-wm voxels segmented.
> 8121 diagonally connected voxels added...
> white matter segmentation took 2.7 minutes
> writing output to wm.seg.mgz...
> *ERROR: mri_segment-MRIcheckVolDims: volume1 width=240 != volume2
> width=320.*
>
>
> My WM segmentations (as well as the T1w images) are 320 rows x 320 
> columns in 240 frames. Seems like FreeSurfer expects them to be cubic, 
> correct?
> Would that fix the problem if I add 80 frames of zeroes (or ones) to 
> my volumes? Any other ideas of what I might be doing wrong?
>
> Regards,
> Jordi
>
> On Thu, Nov 28, 2019 at 8:47 AM Jordi Huguet  > wrote:
>
> Great, just what I was looking for!
>
> Thanks Douglas,
> Jordi
>
> On Wed, Nov 27, 2019, 19:47 Greve, Douglas N.,Ph.D.
> mailto:dgr...@mgh.harvard.edu>> wrote:
>
> It might work if you
> mkdir -p FOO/mri
> cp yourwm.mgz FOO/mri/wm.mgz
> cp inputdata.mgz FOO/mri/orig/001.mgz
> then run recon-all -s FOO -all
>
>
> On 11/27/2019 12:39 PM, Jordi Huguet wrote:
>>
>> External Email - Use Caution
>>
>> Hi Bruce,
>>
>> Many thanks for your reply.
>>
>> I understand from your answer that it could be done as
>> follows (I am not an expert in FreeSurfer directives):
>>
>> a) run full FreeSurfer pipeline
>> recon-all -s FOO
>> b) insert pre-existing WM segmentation as wm.mgz (modifying
>> the intensity values)
>> c) re-run stages 15-23 and 24-31 (recon-all shall use my
>> external segmentation as WM "edits")
>> recon-all -s FOO -autorecon2-wm -autorecon3
>>
>> Is it possible however to just include the WM segmentation
>> without executing a full early run of recon-all?
>>
>> Thanks,
>> Jordi
>>
>>
>> On Tue, Nov 26, 2019 at 3:08 PM Bruce Fischl
>> > > wrote:
>>
>> Hi Jordi
>>
>> yes, this should be possible. You might need to run
>> recon-all in stages
>> though. Although if you set the wm.mgz values from SPM to
>> 255 and 1 (not 0)
>> recon-all should detect them as "edits" and retain them
>>
>> cheers
>> Bruce
>>
>>
>> On Tue, 26 Nov 2019, Jordi Huguet wrote:
>>
>> >
>> > External Email - Use Caution
>> >
>> > Hi there,
>> > I wonder if its somehow possible to feed FreeSurfer's
>> recon-all with pre-existing segmented maps
>> > (based on prior segmentation procedure e.g. SPM or
>> ANTs) to "improve" FreeSurfer results.
>> >
>> > For some images I am working with the FreeSurfer's WM
>> segmentation output is not optimal so I am
>> > looking for alternatives to improve the final results
>> on such specific cases without requiring any
>> > manual intervention.
>> >
>> > Any comments, examples or shared reflections on this
>> regard are kindly welcome.
>> >
>> > Thanks in advance,
>> > Jordi Huguet
>> >
>> >___
>> Freesurfer mailing list
>> Freesurfer@nmr.mgh.harvard.edu
>> 
>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>
>>
>> 

Re: [Freesurfer] Study specific template

[Greve, Douglas N.,Ph.D.]

See the REAME file here
ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/6.0.0-patch/


On 12/5/19 11:47 AM, Joshi, Nandita wrote:
>
> External Email - Use Caution
>
> Hello,
>
> I am trying to make a study specific template based on the 
> instructions at: 
> https://surfer.nmr.mgh.harvard.edu/fswiki/SurfaceRegAndTemplates
>
> However, on running the first step:
>
> make_average_subject --out newtemplate --subjects subj1 subj2 subj3 ...
>
> I get an error while running the recon-all is trying to run the aparc 
> to aseg step:
>
> #@# AParc-to-ASeg aparc Thu Dec5 11:29:33 EST 2019
>
> /Users/nandita/FreeSurfer_recon/newtemplate
>
> \n mri_aparc2aseg --s newtemplate --volmask --aseg aseg.presurf.hypos 
> --relabel mri/norm.mgz mri/transforms/talairach.m3z 
> /Applications/freesurfer/average/RB_all_2016-05-10.vc700.gca 
> mri/aseg.auto_noCCseg.label_intensities.txt \n
>
> relabeling unlikely voxels interior to white matter surface:
>
> norm: mri/norm.mgz
>
> XFORM: mri/transforms/talairach.m3z
>
> GCA: /Applications/freesurfer/average/RB_all_2016-05-10.vc700.gca
>
> label intensities: mri/aseg.auto_noCCseg.label_intensities.txt
>
> SUBJECTS_DIR /Users/nandita/FreeSurfer_recon
>
> subject newtemplate
>
> outvol /Users/nandita/FreeSurfer_recon/newtemplate/mri/aparc+aseg.mgz
>
> useribbon 0
>
> baseoffset 0
>
> RipUnknown 0
>
> Reading lh white surface
>
> /Users/nandita/FreeSurfer_recon/newtemplate/surf/lh.white
>
> Reading lh pial surface
>
> /Users/nandita/FreeSurfer_recon/newtemplate/surf/lh.pial
>
> Loading lh annotations from 
> /Users/nandita/FreeSurfer_recon/newtemplate/label/lh.aparc.annot
>
> reading colortable from annotation file...
>
> colortable with 36 entries read (originally 
> /Users/nandita/FreeSurfer_recon/newtemplate/label/tmpdir.annot2std.41916/seg.1.100110189.ctab)
>
> Reading rh white surface
>
> /Users/nandita/reeSurfer_recon/newtemplate/surf/rh.white
>
> Reading rh pial surface
>
> /Users/nandita/FreeSurfer_recon/newtemplate/surf/rh.pial
>
> Loading rh annotations from 
> /Users/nandita/ADRC/FreeSurfer_recon/newtemplate/label/rh.aparc.annot
>
> reading colortable from annotation file...
>
> colortable with 36 entries read (originally 
> /Users/nandita/FreeSurfer_recon/newtemplate/label/tmpdir.annot2std.47059/seg.1.100110189.ctab)
>
> Have color table for lh white annotation
>
> Have color table for rh white annotation
>
> Loading ribbon segmentation from 
> /Users/nandita/FreeSurfer_recon/newtemplate/mri/ribbon.mgz
>
> Building hash of lh white
>
> Building hash of lh pial
>
> Building hash of rh white
>
> Building hash of rh pial
>
> Loading aseg from 
> /Users/nandita/FreeSurfer_recon/newtemplate/mri/aseg.presurf.hypos.mgz
>
> ASeg Vox2RAS: ---
>
> -1.0 0.0 0.0 128.0;
>
> 0.0 0.0 1.0-128.0;
>
> 0.0-1.0 0.0 128.0;
>
> 0.0 0.0 0.0 1.0;
>
> mghRead(mri/norm.mgz, -1): could not open file
>
> -
>
> Labeling Slice
>
> relabeling unlikely voxels in interior of white matter
>
> Segmentation fault
>
> Darwin Nanditas-MacBook-Pro.local 17.7.0 Darwin Kernel Version 17.7.0: 
> Sun Jun2 20:31:42 PDT 2019; root:xnu-4570.71.46~1/RELEASE_X86_64 x86_64
>
> recon-all -s newtemplate exited with ERRORS at Thu Dec5 11:29:52 EST 2019
>
> On inspecting the mri folder, it seems the norm.mgz file has not been 
> created at all. Looking at the flowchart of steps for the recon-all 
> command, norm.mgz is supposed to be created in the CA Normalize step, 
> which requires the talairach.lta in the newtemplate/mri/transforms 
> folder, which seems to be missing as well. The only transform created 
> in the transform folder is talairach.xfm. The talairach.lta is created 
> in the EM GCA registration step. Do I re-run the EM GCA registration, 
> CA normalize, and then contonue from aparc to aseg? I am not sure if 
> since I am creating my own template, the EM GCA step requires any 
> modifications? Any help will be appreciated.
>
> Thanks,
>
> Nandita
>
>
> ___
> 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] Question on GLM - correlation

[Barletta, Valeria]

I did what you suggested in your previous email:

> That does not have the pvr in it. You can extract the pvr for that
> vertex and add it as a column to the X matrix with
> pvr = fast_vol2mat(MRIread('pvr.mgz'));
> pvrvtx = pvr(:,vertexno+1);

Which file shall I look like for the single voxel?



From: Greve, Douglas N.,Ph.D. 
Sent: Thursday, December 5, 2019 12:40 PM
To: Barletta, Valeria ; Freesurfer support list 

Subject: Re: [Freesurfer] Question on GLM - correlation



On 12/4/19 11:51 AM, Barletta, Valeria wrote:
> Ok I did it and did not get any .mgh file as a result.
Did what?
>
> At this point I wonder, what is the best model to check for
> correlation between my continuous outcome CME.mgh and the continuous
> variable ficvf.mgh?
> Shall I include ficvf.mgh as a regressor (pvr) and use the Contrast  1
> 0 0   or shall I use a completely different method?
>
> Thanks, sorry for the long interaction...
> 
> *From:* Greve, Douglas N.,Ph.D. 
> *Sent:* Tuesday, December 3, 2019 3:18 PM
> *To:* Barletta, Valeria ; Freesurfer
> support list 
> *Subject:* Re: [Freesurfer] Question on GLM - correlation
> That does not have the pvr in it. You can extract the pvr for that
> vertex and add it as a column to the X matrix with
> pvr = fast_vol2mat(MRIread('pvr.mgz'));
> pvrvtx = pvr(:,vertexno+1);
>
> ps. Please remember to post to the list
>
> On 12/3/2019 1:29 PM, Barletta, Valeria wrote:
>> Ok done. This is the Xg.mat
>> 129
>>  144
>>  138
>>  147
>>  134
>>  125
>>  130
>>  122
>>  152
>>  131
>>  137
>>  142
>>  128
>>  139
>>  144
>>  144
>>  132
>>  132
>>  136
>>  147
>>  152
>> And the cond(Xg'*Xg) is again: 3.0555e+04
>> Looks like there is no extra column for the pvr in the Xg.mat
>>
>>
>> 
>> *From:* Greve, Douglas N.,Ph.D. 
>> 
>> *Sent:* Tuesday, December 3, 2019 11:03 AM
>> *To:* Barletta, Valeria 
>> ; Freesurfer support list
>>  
>> *Subject:* Re: [Freesurfer] Question on GLM - correlation
>> I'm not sure those condition numbers include the pvr. Try loading the
>> Xg.mat into matlab and computing
>> cond(Xg'*Xg)
>> Make sure Xg has the extra column for the pvr
>>
>> On 12/3/2019 10:42 AM, Barletta, Valeria wrote:
>>> Ok it worked.
>>> So I tried with a non-zero vertex and I got:
>>> Normalized matrix condition is 81.1382
>>> Matrix condition is 30558.5
>>> Found 149926 points in label.
>>> Found 149926 voxels in mask
>>> Saving mask to
>>> /autofs/space/lipari_001/users/valeria/NODDI/GLM//GLM_CME_ficvf_doug/rh_contrast-MS_CME_all_FIS_ICA1/mask.mgh
>>> Reshaping mriglm->mask...
>>> search space = 74490.928733
>>> DOF = 18
>>> Dumping voxel 1024 0 0 to
>>> /autofs/space/lipari_001/users/valeria/NODDI/GLM//GLM_CME_ficvf_doug/rh_contrast-MS_CME_all_FIS_ICA1/voxdump-1024-0-0
>>>
>>> ...and with a zero vertex and got:
>>> Normalized matrix condition is 81.1382
>>> Matrix condition is 30558.5
>>> Found 149926 points in label.
>>> Found 149926 voxels in mask
>>> Saving mask to
>>> /autofs/space/lipari_001/users/valeria/NODDI/GLM//GLM_CME_ficvf_doug2/rh_contrast-MS_CME_all_FIS_ICA1/mask.mgh
>>> Reshaping mriglm->mask...
>>> search space = 74490.928733
>>> DOF = 18
>>> Dumping voxel 150252 0 0 to
>>> /autofs/space/lipari_001/users/valeria/NODDI/GLM//GLM_CME_ficvf_doug2/rh_contrast-MS_CME_all_FIS_ICA1/voxdump-150252-0-0
>>>
>>>
>>>
>>> 
>>> *From:* freesurfer-boun...@nmr.mgh.harvard.edu
>>> 
>>> 
>>>  on behalf of Greve,
>>> Douglas N.,Ph.D. 
>>> 
>>> *Sent:* Monday, December 2, 2019 2:56 PM
>>> *To:* freesurfer@nmr.mgh.harvard.edu
>>> 
>>>  
>>> *Subject:* Re: [Freesurfer] Question on GLM - correlation
>>> oh, sorry, did not see the pvr. It could very well be the pvr that
>>> is causing the patchiness. Unfortunately, you have to debug it
>>> vertex by vertex. I would choose a few vertices (one with signal, on
>>> without) and run mri_glmfit with --voxdump vertexno 0 0 This will
>>> create a subfolder with the GLM for that vertex. I'm not sure what
>>> to tell you to look for, but I would at least check the condition
>>> numbers in each vertex. What is the nature of ficvf?
>>>
>>> On 12/2/2019 1:22 PM, Barletta, Valeria wrote:
 My other continuous variable is --pvr ${hemi}.ficvf.mgh
 Not sure about --no-prune, I found it in my script as a default...
 Shall I remove it?
 

Re: [Freesurfer] Question on GLM - correlation

[Greve, Douglas N.,Ph.D.]

On 12/4/19 11:51 AM, Barletta, Valeria wrote:
> Ok I did it and did not get any .mgh file as a result.
Did what?
>
> At this point I wonder, what is the best model to check for 
> correlation between my continuous outcome CME.mgh and the continuous 
> variable ficvf.mgh?
> Shall I include ficvf.mgh as a regressor (pvr) and use the Contrast  1 
> 0 0   or shall I use a completely different method?
>
> Thanks, sorry for the long interaction...
> 
> *From:* Greve, Douglas N.,Ph.D. 
> *Sent:* Tuesday, December 3, 2019 3:18 PM
> *To:* Barletta, Valeria ; Freesurfer 
> support list 
> *Subject:* Re: [Freesurfer] Question on GLM - correlation
> That does not have the pvr in it. You can extract the pvr for that 
> vertex and add it as a column to the X matrix with
> pvr = fast_vol2mat(MRIread('pvr.mgz'));
> pvrvtx = pvr(:,vertexno+1);
>
> ps. Please remember to post to the list
>
> On 12/3/2019 1:29 PM, Barletta, Valeria wrote:
>> Ok done. This is the Xg.mat
>> 1    29
>>      1    44
>>      1    38
>>      1    47
>>      1    34
>>      1    25
>>      1    30
>>      1    22
>>      1    52
>>      1    31
>>      1    37
>>      1    42
>>      1    28
>>      1    39
>>      1    44
>>      1    44
>>      1    32
>>      1    32
>>      1    36
>>      1    47
>>      1    52
>> And the cond(Xg'*Xg) is again: 3.0555e+04
>> Looks like there is no extra column for the pvr in the Xg.mat
>>
>>
>> 
>> *From:* Greve, Douglas N.,Ph.D.  
>> 
>> *Sent:* Tuesday, December 3, 2019 11:03 AM
>> *To:* Barletta, Valeria  
>> ; Freesurfer support list 
>>  
>> *Subject:* Re: [Freesurfer] Question on GLM - correlation
>> I'm not sure those condition numbers include the pvr. Try loading the 
>> Xg.mat into matlab and computing
>> cond(Xg'*Xg)
>> Make sure Xg has the extra column for the pvr
>>
>> On 12/3/2019 10:42 AM, Barletta, Valeria wrote:
>>> Ok it worked.
>>> So I tried with a non-zero vertex and I got:
>>> Normalized matrix condition is 81.1382
>>> Matrix condition is 30558.5
>>> Found 149926 points in label.
>>> Found 149926 voxels in mask
>>> Saving mask to 
>>> /autofs/space/lipari_001/users/valeria/NODDI/GLM//GLM_CME_ficvf_doug/rh_contrast-MS_CME_all_FIS_ICA1/mask.mgh
>>> Reshaping mriglm->mask...
>>> search space = 74490.928733
>>> DOF = 18
>>> Dumping voxel 1024 0 0 to 
>>> /autofs/space/lipari_001/users/valeria/NODDI/GLM//GLM_CME_ficvf_doug/rh_contrast-MS_CME_all_FIS_ICA1/voxdump-1024-0-0
>>>
>>> ...and with a zero vertex and got:
>>> Normalized matrix condition is 81.1382
>>> Matrix condition is 30558.5
>>> Found 149926 points in label.
>>> Found 149926 voxels in mask
>>> Saving mask to 
>>> /autofs/space/lipari_001/users/valeria/NODDI/GLM//GLM_CME_ficvf_doug2/rh_contrast-MS_CME_all_FIS_ICA1/mask.mgh
>>> Reshaping mriglm->mask...
>>> search space = 74490.928733
>>> DOF = 18
>>> Dumping voxel 150252 0 0 to 
>>> /autofs/space/lipari_001/users/valeria/NODDI/GLM//GLM_CME_ficvf_doug2/rh_contrast-MS_CME_all_FIS_ICA1/voxdump-150252-0-0
>>>
>>>
>>>
>>> 
>>> *From:* freesurfer-boun...@nmr.mgh.harvard.edu 
>>>  
>>>  
>>>  on behalf of Greve, 
>>> Douglas N.,Ph.D.  
>>> 
>>> *Sent:* Monday, December 2, 2019 2:56 PM
>>> *To:* freesurfer@nmr.mgh.harvard.edu 
>>>  
>>>  
>>> *Subject:* Re: [Freesurfer] Question on GLM - correlation
>>> oh, sorry, did not see the pvr. It could very well be the pvr that 
>>> is causing the patchiness. Unfortunately, you have to debug it 
>>> vertex by vertex. I would choose a few vertices (one with signal, on 
>>> without) and run mri_glmfit with --voxdump vertexno 0 0 This will 
>>> create a subfolder with the GLM for that vertex. I'm not sure what 
>>> to tell you to look for, but I would at least check the condition 
>>> numbers in each vertex. What is the nature of ficvf?
>>>
>>> On 12/2/2019 1:22 PM, Barletta, Valeria wrote:
 My other continuous variable is --pvr ${hemi}.ficvf.mgh
 Not sure about --no-prune, I found it in my script as a default... 
 Shall I remove it?
 
 *From:* freesurfer-boun...@nmr.mgh.harvard.edu 
  
  
  on behalf of 
 Barletta, Valeria  
 
 *Sent:* Friday, November 29, 2019 3:08 PM
 *To:* Freesurfer support list  
 
 *Subject:* [Freesurfer] Question on GLM - 

Re: [Freesurfer] about label to surface

[Greve, Douglas N.,Ph.D.]

Use mri_label2label. Run it with --help to get examples

On 12/4/19 1:58 AM, 于倩倩 wrote:
>
> External Email - Use Caution
>
> Dear Freesurfer Expert:
> First, I got the lh.parsorbitalis.label according to the command:
>   mri_annotation2label --subject fsaverage --hemi lh --outdir 
> /Users/qianqianyu/Desktop/fsl_bold/label_fsaverage
> Now, I want to make the lh.parsorbitalis.label to fsaverage surface 
> file (nii.gz). How?
>
> I did the conversion myself using the following method, but an error 
> occurred. The structure of lh.parsorbitalis.label  is as follows：
>  I think the first column is coordinate information. So, I use the 
> following commands to convert in Matlab.
>
> a=[116,255,256,735,...3806,...];%All values in the first column are 
> assigned to the matrix, a.
>
> n=1:163842; %cause the vol matrix of fsaverage lh is1*163842
>
> t=zeros(1,length(n));
>
> t(1,a)=1;%value of lh.parsorbitalis area were 1
>
> MRIread('/Users/qianqianyu/Desktop/Project/Sess06/bold/my-syn.sm04.lh/sem-v-fj/sig.nii');%read
>  
> a  fsaverage image
>
> ans.vol=t;
>
> err = MRIwrite(ans,'lh.parsorbitalis.mask.nii.gz')
>
>
> But, when I check the lh.parsorbitalis.mask.nii.gz in Freeview, I find 
> it is not consistent with the lh.parsorbitalis.label
>
>
> I am now very very anxious to know how to get the 
> right  lh.parsorbitalis.mask.nii.gz！Looking forward to your reply！
>
> Best wishes!
>
> Qianqian Yu
>
>
>
>
> ___
> 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] DWI to T1 registration accuracy with bbregister

[Greve, Douglas N.,Ph.D.]

Are you 100% sure that the DTI and the anatomical are the same subject? 
Also, please send the bbregister log file

On 12/5/19 12:14 PM, VictorM - Gmail wrote:
>  External Email - Use Caution
>
> Hi Freesurfer experts,
>
> I have been trying to run a registration between my DWi data and the T1.
> I am struggling to obtain a good cortical matching, despite I have
> previously run it withour problems in other datasets. The mincost for
> most of the individuals is >0.8, which is pretty bad. My guess is that
> there is a problem with the initialization (mri_coreg not converging
> correctly?). I have tried different approaches to improve the results
> with no success:
>
> 1) Typical bbregister command:
>
>      >> bbregister --s XX --mov XX_b0_brain.nii.gz --reg dwi2anat.reg.lta
> --dti
>
> 2) Initialize with fsl (using --init-fsl and using flirt independently
> with mutual information cost)
>
> 3) Playing around with mri_coreg different parameters (dof, non-mask,
> different smooth of target/mov, etc).
>
> 4) Use bbregister with the pial surface (since the contrast CSF/GM is
> higher than GM/WM) with the command:
>
>      >> bbregister --s XX --mov 'XX_b0_brain.nii.gz'  --reg
> reg.csf.gm.contrast.dat --surf pial --o dwi2anat.nii.gz --t1
> --gm-proj-abs 1 --wm-proj-abs 1
>
>
> Any insight on how to improve the results?
>
> Victor Montal
>
>
> PS: Please, see below the output of mri_coreg when initializing the
> bbregister with default parameters (method1):
>
> $Id: bbregister,v 1.75 2016/05/10 20:02:28 greve Exp $
> Linux testPC 4.15.0-64-generic #73~16.04.1-Ubuntu SMP Fri Sep 13
> 09:56:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
> FREESURFER_HOME /usr/local/freesurfer
> mri_convert XX_b0_brain.nii.gz ./tmp.bbregister.28271/template.nii
> mri_convert.bin XX_b0_brain.nii.gz ./tmp.bbregister.28271/template.nii
> $Id: mri_convert.c,v 1.226 2016/02/26 16:15:24 mreuter Exp $
> reading from XX_b0_brain.nii.gz...
> TR=1000.00, TE=0.00, TI=0.00, flip angle=0.00
> i_ras = (-0.998604, 0.0523657, -0.00685515)
> j_ras = (0.0495749, 0.974205, 0.220152)
> k_ras = (-0.0182067, -0.219505, 0.975442)
> writing to ./tmp.bbregister.28271/template.nii...
> mri_coreg --s XX --mov ./tmp.bbregister.28271/template.nii --regdat
> ./tmp.bbregister.28271/reg.init.dat --reg
> ./tmp.bbregister.28271/mri_coreg.lta --nthreads 1 --dof 6 --sep 4 --ftol
> .0001 --linmintol .01
>
> $Id: mri_coreg.c,v 1.27 2016/04/30 15:11:49 greve Exp $
> cwd /home/testPC/Desktop/tmp/todel_max/test_subject/DTI/XX
> cmdline mri_coreg --s XX --mov ./tmp.bbregister.28271/template.nii
> --regdat ./tmp.bbregister.28271/reg.init.dat --reg
> ./tmp.bbregister.28271/mri_coreg.lta --nthreads 1 --dof 6 --sep 4 --ftol
> .0001 --linmintol .01
> sysname  Linux
> hostname testPC
> machine  x86_64
> user testPC
> dof    6
> nsep    1
> cras0    1
> ftol    0.000100
> linmintol    0.01
> bf   1
> bflim    30.00
> bfnsamp    30
> SmoothRef 0
> SatPct    99.99
> MovOOB 0
> optschema 1
> Reading in mov ./tmp.bbregister.28271/template.nii
> Reading in ref
> /home/testPC/Desktop/tmp/todel_max/test_subject/FS/XX/mri/brainmask.mgz
> Reading in and applying refmask
> /home/testPC/Desktop/tmp/todel_max/test_subject/FS/XX/mri/aparc+aseg.mgz
> Setting cras translation parameters to align centers
> Creating random numbers for coordinate dithering
> Performing intensity dithering
> Initial parameters -0.1963 -2.6892 11.5267  0.  0. 0.
> 1.  1.  1.  0.  0.  0.
> Separation list (1):  4   min = 4
> DoSmoothing 1
> DoCoordDither 1
> DoIntensityDither 1
> nitersmax 4
> ftol 1.000e-04
> linmintol 1.000e-02
> SatPct 99.99
> Hist FWHM 7.00 7.00
> nthreads 1
> movsat = 1692.
> mov gstd 1.6917 1.6917 1.6917
> Smoothing mov
> refsat = 116.
> ref gstd 1.8914 1.8914 1.8914
> Smoothing ref
> COREGpreproc() done
> Testing if mov and target overlap
> Init cost   -1.0432535803
> nhits = 124061 out of 16777216, Percent Overlap:  47.3
> Initial  RefRAS-to-MovRAS
>    1.0   0.0   0.0  -0.19633;
>    0.0   1.0   0.0  -2.68918;
>    0.0   0.0   1.0   11.52671;
>    0.0   0.0   0.0   1.0;
> Initial  RefVox-to-MovVox
>    0.49930   0.00343   0.02618  -3.93636;
> -0.02479  -0.11008   0.48710   18.58949;
>    0.00910  -0.48772  -0.10975   106.51717;
>    0.0   0.0   0.0   1.0;
> sep = 4 ---
> COREGoptBruteForce() 30 1 30
> Turning on MovOOB for BruteForce Search
> #BF# sep= 4 iter=0 lim=30.0 delta=2.00  -2.19633   7.31082 -4.47329
> 2.0   0.0   4.0   -1.0498706
> Turning  MovOOB back off after brute force search
>
>
> -
> Init Powel Params dof = 6
> Starting OpenPowel2(), sep = 4
> InitialCost    -1.0708609819
> #@#  4  188  -2.19633 7.31082 -4.47329 2.0 0.0 4.0 -1.0708610
> fs_powell::minimize
>     nparams 6
>     maxfev 4
>     ftol   0.000100
>     linmin_xtol_   0.01

[Freesurfer] DWI to T1 registration accuracy with bbregister

[VictorM - Gmail]

External Email - Use Caution

Hi Freesurfer experts,

I have been trying to run a registration between my DWi data and the T1. 
I am struggling to obtain a good cortical matching, despite I have 
previously run it withour problems in other datasets. The mincost for 
most of the individuals is >0.8, which is pretty bad. My guess is that 
there is a problem with the initialization (mri_coreg not converging 
correctly?). I have tried different approaches to improve the results 
with no success:

1) Typical bbregister command:

    >> bbregister --s XX --mov XX_b0_brain.nii.gz --reg dwi2anat.reg.lta 
--dti

2) Initialize with fsl (using --init-fsl and using flirt independently 
with mutual information cost)

3) Playing around with mri_coreg different parameters (dof, non-mask, 
different smooth of target/mov, etc).

4) Use bbregister with the pial surface (since the contrast CSF/GM is 
higher than GM/WM) with the command:

    >> bbregister --s XX --mov 'XX_b0_brain.nii.gz'  --reg 
reg.csf.gm.contrast.dat --surf pial --o dwi2anat.nii.gz --t1 
--gm-proj-abs 1 --wm-proj-abs 1


Any insight on how to improve the results?

Victor Montal


PS: Please, see below the output of mri_coreg when initializing the 
bbregister with default parameters (method1):

$Id: bbregister,v 1.75 2016/05/10 20:02:28 greve Exp $
Linux testPC 4.15.0-64-generic #73~16.04.1-Ubuntu SMP Fri Sep 13 
09:56:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
FREESURFER_HOME /usr/local/freesurfer
mri_convert XX_b0_brain.nii.gz ./tmp.bbregister.28271/template.nii
mri_convert.bin XX_b0_brain.nii.gz ./tmp.bbregister.28271/template.nii
$Id: mri_convert.c,v 1.226 2016/02/26 16:15:24 mreuter Exp $
reading from XX_b0_brain.nii.gz...
TR=1000.00, TE=0.00, TI=0.00, flip angle=0.00
i_ras = (-0.998604, 0.0523657, -0.00685515)
j_ras = (0.0495749, 0.974205, 0.220152)
k_ras = (-0.0182067, -0.219505, 0.975442)
writing to ./tmp.bbregister.28271/template.nii...
mri_coreg --s XX --mov ./tmp.bbregister.28271/template.nii --regdat 
./tmp.bbregister.28271/reg.init.dat --reg 
./tmp.bbregister.28271/mri_coreg.lta --nthreads 1 --dof 6 --sep 4 --ftol 
.0001 --linmintol .01

$Id: mri_coreg.c,v 1.27 2016/04/30 15:11:49 greve Exp $
cwd /home/testPC/Desktop/tmp/todel_max/test_subject/DTI/XX
cmdline mri_coreg --s XX --mov ./tmp.bbregister.28271/template.nii 
--regdat ./tmp.bbregister.28271/reg.init.dat --reg 
./tmp.bbregister.28271/mri_coreg.lta --nthreads 1 --dof 6 --sep 4 --ftol 
.0001 --linmintol .01
sysname  Linux
hostname testPC
machine  x86_64
user testPC
dof    6
nsep    1
cras0    1
ftol    0.000100
linmintol    0.01
bf   1
bflim    30.00
bfnsamp    30
SmoothRef 0
SatPct    99.99
MovOOB 0
optschema 1
Reading in mov ./tmp.bbregister.28271/template.nii
Reading in ref 
/home/testPC/Desktop/tmp/todel_max/test_subject/FS/XX/mri/brainmask.mgz
Reading in and applying refmask 
/home/testPC/Desktop/tmp/todel_max/test_subject/FS/XX/mri/aparc+aseg.mgz
Setting cras translation parameters to align centers
Creating random numbers for coordinate dithering
Performing intensity dithering
Initial parameters -0.1963 -2.6892 11.5267  0.  0. 0.  
1.  1.  1.  0.  0.  0.
Separation list (1):  4   min = 4
DoSmoothing 1
DoCoordDither 1
DoIntensityDither 1
nitersmax 4
ftol 1.000e-04
linmintol 1.000e-02
SatPct 99.99
Hist FWHM 7.00 7.00
nthreads 1
movsat = 1692.
mov gstd 1.6917 1.6917 1.6917
Smoothing mov
refsat = 116.
ref gstd 1.8914 1.8914 1.8914
Smoothing ref
COREGpreproc() done
Testing if mov and target overlap
Init cost   -1.0432535803
nhits = 124061 out of 16777216, Percent Overlap:  47.3
Initial  RefRAS-to-MovRAS
  1.0   0.0   0.0  -0.19633;
  0.0   1.0   0.0  -2.68918;
  0.0   0.0   1.0   11.52671;
  0.0   0.0   0.0   1.0;
Initial  RefVox-to-MovVox
  0.49930   0.00343   0.02618  -3.93636;
-0.02479  -0.11008   0.48710   18.58949;
  0.00910  -0.48772  -0.10975   106.51717;
  0.0   0.0   0.0   1.0;
sep = 4 ---
COREGoptBruteForce() 30 1 30
Turning on MovOOB for BruteForce Search
#BF# sep= 4 iter=0 lim=30.0 delta=2.00  -2.19633   7.31082 -4.47329   
2.0   0.0   4.0   -1.0498706
Turning  MovOOB back off after brute force search


-
Init Powel Params dof = 6
Starting OpenPowel2(), sep = 4
InitialCost    -1.0708609819
#@#  4  188  -2.19633 7.31082 -4.47329 2.0 0.0 4.0 -1.0708610
fs_powell::minimize
   nparams 6
   maxfev 4
   ftol   0.000100
   linmin_xtol_   0.01
   powell nthiter 0: fret = -1.070861
#@#  4  190  -1.19633 7.31082 -4.47329 2.0 0.0 4.0 -1.0711184
#@#  4  195  -1.38650 7.31082 -4.47329 2.0 0.0 4.0 -1.0711316
#@#  4  201  -1.38650 5.69279 -4.47329 2.0 0.0 4.0 -1.0721272
#@#  4  202  -1.38650 4.18476 -4.47329 2.0 0.0 4.0 -1.0723432
#@#  4  203  -1.38650 4.46454 -4.47329 2.0 0.0 

[Freesurfer] Study specific template

[Joshi, Nandita]

External Email - Use Caution

Hello,

I am trying to make a study specific template based on the instructions at: 
https://surfer.nmr.mgh.harvard.edu/fswiki/SurfaceRegAndTemplates

However, on running the first step:
make_average_subject --out newtemplate --subjects subj1 subj2 subj3 ...

I get an error while running the recon-all is trying to run the aparc to aseg 
step:


#@# AParc-to-ASeg aparc Thu Dec  5 11:29:33 EST 2019

/Users/nandita/FreeSurfer_recon/newtemplate

\n mri_aparc2aseg --s newtemplate --volmask --aseg aseg.presurf.hypos --relabel 
mri/norm.mgz mri/transforms/talairach.m3z 
/Applications/freesurfer/average/RB_all_2016-05-10.vc700.gca 
mri/aseg.auto_noCCseg.label_intensities.txt \n

relabeling unlikely voxels interior to white matter surface:

   norm: mri/norm.mgz

   XFORM: mri/transforms/talairach.m3z

   GCA: /Applications/freesurfer/average/RB_all_2016-05-10.vc700.gca

   label intensities: mri/aseg.auto_noCCseg.label_intensities.txt

SUBJECTS_DIR /Users/nandita/FreeSurfer_recon

subject newtemplate

outvol /Users/nandita/FreeSurfer_recon/newtemplate/mri/aparc+aseg.mgz

useribbon 0

baseoffset 0

RipUnknown 0



Reading lh white surface

 /Users/nandita/FreeSurfer_recon/newtemplate/surf/lh.white



Reading lh pial surface

 /Users/nandita/FreeSurfer_recon/newtemplate/surf/lh.pial



Loading lh annotations from 
/Users/nandita/FreeSurfer_recon/newtemplate/label/lh.aparc.annot

reading colortable from annotation file...

colortable with 36 entries read (originally 
/Users/nandita/FreeSurfer_recon/newtemplate/label/tmpdir.annot2std.41916/seg.1.100110189.ctab)



Reading rh white surface

 /Users/nandita/reeSurfer_recon/newtemplate/surf/rh.white



Reading rh pial surface

 /Users/nandita/FreeSurfer_recon/newtemplate/surf/rh.pial



Loading rh annotations from 
/Users/nandita/ADRC/FreeSurfer_recon/newtemplate/label/rh.aparc.annot

reading colortable from annotation file...

colortable with 36 entries read (originally 
/Users/nandita/FreeSurfer_recon/newtemplate/label/tmpdir.annot2std.47059/seg.1.100110189.ctab)

Have color table for lh white annotation

Have color table for rh white annotation

Loading ribbon segmentation from 
/Users/nandita/FreeSurfer_recon/newtemplate/mri/ribbon.mgz



Building hash of lh white



Building hash of lh pial



Building hash of rh white



Building hash of rh pial



Loading aseg from 
/Users/nandita/FreeSurfer_recon/newtemplate/mri/aseg.presurf.hypos.mgz

ASeg Vox2RAS: ---

-1.0   0.0   0.0   128.0;

 0.0   0.0   1.0  -128.0;

 0.0  -1.0   0.0   128.0;

 0.0   0.0   0.0   1.0;

mghRead(mri/norm.mgz, -1): could not open file

-



Labeling Slice

relabeling unlikely voxels in interior of white matter

Segmentation fault

Darwin Nanditas-MacBook-Pro.local 17.7.0 Darwin Kernel Version 17.7.0: Sun Jun  
2 20:31:42 PDT 2019; root:xnu-4570.71.46~1/RELEASE_X86_64 x86_64



recon-all -s newtemplate exited with ERRORS at Thu Dec  5 11:29:52 EST 2019

On inspecting the mri folder, it seems the norm.mgz file has not been created 
at all. Looking at the flowchart of steps for the recon-all command, norm.mgz 
is supposed to be created in the CA Normalize step, which requires the 
talairach.lta in the newtemplate/mri/transforms folder, which seems to be 
missing as well. The only transform created in the transform folder is 
talairach.xfm. The talairach.lta is created in the EM GCA registration step. Do 
I re-run the EM GCA registration, CA normalize, and then contonue from aparc to 
aseg? I am not sure if since I am creating my own template, the EM GCA step 
requires any modifications? Any help will be appreciated.

Thanks,
Nandita

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

[Freesurfer] T2 in recon-all: command to correct pial surfaces errors

[Steve Petersen]

External Email - Use Caution

Dear Freesurfer experts,

I used t2 image as input in subjects that have already been processed
without them following the instructions of the website. Although pial
surface segmentation has improved there is still some error. After edit the
brainmask.mgz file in Freeview (recon edit option), what command should I
use  to correct the pial surfaces obtained after the -T2pial flag?

I tried to use the -autorecon-pial command to correct the edits but I think
that this command only takes into account the T1, is that right?


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

Re: [Freesurfer] Using pre-segmented results

[Jordi Huguet]

External Email - Use Caution

Hi Douglas,

I have followed the suggested approach, however I get an error related to
the dimensions of the WM volume (see log trace below).

...

Found wm edits: 23448857 deletes, 783317 fills
>
>  cp wm.mgz wm.seg.mgz
>
>
>  mri_segment -keep -mprage brain.mgz wm.seg.mgz
>
> preserving editing changes in output volume...
> doing initial intensity segmentation...
> using local statistics to label ambiguous voxels...
> computing class statistics for intensity windows...
> WM (104.0): 105.4 +- 6.0 [79.0 --> 125.0]
> GM (69.0) : 67.0 +- 10.5 [30.0 --> 95.0]
> setting bottom of white matter range to 77.5
> setting top of gray matter range to 88.0
> doing initial intensity segmentation...
> using local statistics to label ambiguous voxels...
> using local geometry to label remaining ambiguous voxels...
>
> reclassifying voxels using Gaussian border classifier...
>
> removing voxels with positive offset direction...
> smoothing T1 volume with sigma = 0.250
> removing 1-dimensional structures...
> thickening thin strands
> 20 segments, 7509 filled
> 8232 bright non-wm voxels segmented.
> 8121 diagonally connected voxels added...
> white matter segmentation took 2.7 minutes
> writing output to wm.seg.mgz...
> *ERROR: mri_segment-MRIcheckVolDims: volume1 width=240 != volume2
> width=320.*
>

My WM segmentations (as well as the T1w images) are 320 rows x 320 columns
in 240 frames. Seems like FreeSurfer expects them to be cubic, correct?
Would that fix the problem if I add 80 frames of zeroes (or ones) to my
volumes? Any other ideas of what I might be doing wrong?

Regards,
Jordi


On Thu, Nov 28, 2019 at 8:47 AM Jordi Huguet  wrote:

> Great, just what I was looking for!
>
> Thanks Douglas,
> Jordi
>
> On Wed, Nov 27, 2019, 19:47 Greve, Douglas N.,Ph.D. <
> dgr...@mgh.harvard.edu> wrote:
>
>> It might work if you
>> mkdir -p FOO/mri
>> cp yourwm.mgz FOO/mri/wm.mgz
>> cp inputdata.mgz FOO/mri/orig/001.mgz
>> then run recon-all -s FOO -all
>>
>>
>> On 11/27/2019 12:39 PM, Jordi Huguet wrote:
>>
>> External Email - Use Caution
>> Hi Bruce,
>>
>> Many thanks for your reply.
>>
>> I understand from your answer that it could be done as follows (I am not
>> an expert in FreeSurfer directives):
>>
>> a) run full FreeSurfer pipeline
>> recon-all -s FOO
>> b) insert pre-existing WM segmentation as wm.mgz (modifying the intensity
>> values)
>> c) re-run stages 15-23 and 24-31 (recon-all shall use my external
>> segmentation as WM "edits")
>> recon-all -s FOO -autorecon2-wm -autorecon3
>>
>> Is it possible however to just include the WM segmentation without
>> executing a full early run of recon-all?
>>
>> Thanks,
>> Jordi
>>
>>
>> On Tue, Nov 26, 2019 at 3:08 PM Bruce Fischl 
>> wrote:
>>
>>> Hi Jordi
>>>
>>> yes, this should be possible. You might need to run recon-all in stages
>>> though. Although if you set the wm.mgz values from SPM to 255 and 1 (not
>>> 0)
>>> recon-all should detect them as "edits" and retain them
>>>
>>> cheers
>>> Bruce
>>>
>>>
>>> On Tue, 26 Nov 2019, Jordi Huguet wrote:
>>>
>>> >
>>> > External Email - Use Caution
>>> >
>>> > Hi there,
>>> > I wonder if its somehow possible to feed FreeSurfer's recon-all with
>>> pre-existing segmented maps
>>> > (based on prior segmentation procedure e.g. SPM or ANTs) to
>>> "improve" FreeSurfer results.
>>> >
>>> > For some images I am working with the FreeSurfer's WM segmentation
>>> output is not optimal so I am
>>> > looking for alternatives to improve the final results on such specific
>>> cases without requiring any
>>> > manual intervention.
>>> >
>>> > Any comments, examples or shared reflections on this regard are kindly
>>> welcome.
>>> >
>>> > Thanks in advance,
>>> > Jordi Huguet
>>> >
>>> >___
>>> Freesurfer mailing list
>>> Freesurfer@nmr.mgh.harvard.edu
>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>
>>
>> ___
>> Freesurfer mailing 
>> listfreesur...@nmr.mgh.harvard.eduhttps://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