Re: [Freesurfer] Downsampling from fsaverage to fsaverage6

[Matthieu VANHOUTTE]

   External Email - Use Caution


Hi Bruce,

The input file has not only binary values (0 or 1) it is made of float 
values, whereas the output mri_surf2surf contains only binary values.


Best,

Matthieu

On 13/09/2019 15:52, Bruce Fischl wrote:

Hi Matthieu

sorry, I don't understand. All the files are binary, no? Are you 
getting an error?


cheers
Bruce
On Fri, 13 Sep 2019, Matthieu VANHOUTTE wrote:


  External Email - Use Caution Dear FS's experts,

I am trying to downsample some surface data from fsaverage to 
fsaverage6 with the following command:


 mri_surf2surf --hemi lh --srcsubject fsaverage --sval 
./lh.fsaverage.s8mm.mgh  --trgsubject fsaverage6 --tval 
./lh.fsaverage6.s8mm.mgh --cortex


However, the output surface data is a binary file contrary to the 
source one (please see attached).


Would anyone have an idea of the problem?

Best,

Matthieu





___
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] Compare vertexwise correlation maps

[Matthieu Vanhoutte]

External Email - Use Caution

So if I obtained two correlation maps from the same population but based on 
different input parameters, how could I demonstrate that vertex correlation 
values are statistically « strongest »/« lowest »  in one of the map compared 
to the other ?

Best,
Matthieu

> Le 3 sept. 2019 à 17:00, Greve, Douglas N.,Ph.D.  a 
> écrit :
> 
> You want to see if the correlation values themselves? You can't do that 
> (unless you have a bunch of correlation maps). You have to incorporate 
> your question/hypothesis into the design and contrast.
> 
> On 9/2/2019 11:14 AM, Matthieu VANHOUTTE wrote:
>> External Email - Use Caution
>> 
>> Dear experts,
>> 
>> I would like now to determine if there is statistically difference
>> between vertexwise correlation maps (whether one is statistically
>> "stronger" than the other). Would there be a way to do this with
>> Freesurfer? (r-to-z Fisher transformation and statistical method?)
>> 
>> Best regards,
>> 
>> Matthieu
>> 
>> ___
>> 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] Compare vertexwise correlation maps

[Matthieu VANHOUTTE]

External Email - Use Caution

Dear experts,

I would like now to determine if there is statistically difference 
between vertexwise correlation maps (whether one is statistically 
"stronger" than the other). Would there be a way to do this with 
Freesurfer? (r-to-z Fisher transformation and statistical method?)

Best regards,

Matthieu

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

[Freesurfer] Estimation of surface based smoothing

[Matthieu Vanhoutte]

External Email - Use Caution

Dear experts,

Knowing the size of the effects on volume-based data, does anyone would
know a way to estimate the size of the effects on surface data?

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

Re: [Freesurfer] Command line tksurfer: use of the color scale "Color Wheel"

[Matthieu Vanhoutte]

External Email - Use Caution

All my script is based on tksurfer derived commande. Is this possible to
parametrize freeview by command lines with as many options than tksurfer,
and then save snap in one script?

Please give me some information on how to set properly "Color Wheel" Color
scale.

Best,
Matthieu

Le jeu. 18 juil. 2019 à 20:45, Greve, Douglas N.,Ph.D. <
dgr...@mgh.harvard.edu> a écrit :

> In freeview, you can use :overlay_color=colorscale,settings
> maybe Ruopeng can weigh in on exactly what to set them to to get the
> colorwheel
> Are you also looking to have freeview snap pictures for you?
>
> On 7/18/19 11:57 AM, Matthieu VANHOUTTE wrote:
> > External Email - Use Caution
> > Sorry not to be precise on my answer.
> >
> > I can easily open freeview to load overlay on surface and configure
> > the color scale to "Color Wheel".
> >
> > However to create pictures for article I automatize the creation
> > of those pictures by scripting using tksurfer command line. There are
> > different options for this command line but I didn't find any option
> > to set the color scale to which I want "Color Wheel".
> >
> > Is there any tool existing allowing to use "Color Wheel" color scale
> > by scripting ?
> >
> > Best,
> >
> > Matthieu
> >
> > On 18/07/2019 17:51, Greve, Douglas N.,Ph.D. wrote:
> >> I don't know what you mean by "stay graphical". can you explain? What is
> >> the tksurfer option to load the colorwheel?
> >>
> >> On 7/18/19 11:47 AM, Matthieu VANHOUTTE wrote:
> >>> External Email - Use Caution
> >>> Hi Douglas, Bruce,
> >>>
> >>> Freeview is really nice but stay graphical. When I want to create
> >>> composed snapshots of surface overlays I use tksurfer with command
> >>> lines to create these.
> >>>
> >>> I looked at tksurferfv with command lines but didn't see where is the
> >>> option to set color scale to "Color Wheel"?
> >>>
> >>> Best,
> >>>
> >>> Matthieu
> >>>
> >>> On 18/07/2019 17:22, Greve, Douglas N.,Ph.D. wrote:
> >>>> There is a program called tksurferfv that runs freeview but takes all
> >>>> the same command line args as tksurfer
> >>>>
> >>>> On 7/18/19 10:56 AM, Bruce Fischl wrote:
> >>>>> Hi Matthieu
> >>>>>
> >>>>> tksurfer has been deprecated for years. Is there a reason you can't
> >>>>> switch to freeview?
> >>>>>
> >>>>> cheers
> >>>>> Bruce
> >>>>> On Thu, 18 Jul 2019, Matthieu VANHOUTTE wrote:
> >>>>>
> >>>>>>   External Email - Use Caution
> >>>>>>
> >>>>>> Dear experts,
> >>>>>>
> >>>>>> I use tksurfer in command line to generate multiple faces images of
> >>>>>> overlays on the fsaverage surface.
> >>>>>>
> >>>>>> Graphically it is possible via freeview to set the color scale of
> >>>>>> the
> >>>>>> overlay with "Color Wheel" setting. I searched into the tksufer
> >>>>>> command
> >>>>>> help but didn' t find any option to specify this color scale. Doas
> >>>>>> anyone know how to deal with it by command lines ?
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>> Matthieu
> >>>>>>
> >>>>>>
> >>>>>> ___
> >>>>>> 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.
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] Command line tksurfer: use of the color scale "Color Wheel"

[Matthieu VANHOUTTE]

External Email - Use Caution

Dear experts,

I use tksurfer in command line to generate multiple faces images of 
overlays on the fsaverage surface.

Graphically it is possible via freeview to set the color scale of the 
overlay with "Color Wheel" setting. I searched into the tksufer command 
help but didn' t find any option to specify this color scale. Doas 
anyone know how to deal with it by command lines ?

Best regards,

Matthieu


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

Re: [Freesurfer] Within-subject vertexwise correlation

[Matthieu Vanhoutte]

External Email - Use Caution

I effectively smoothed both modalities the same amount.

The question is whether I should or not smooth before calculating
within-subject correlation?

Best,
Matthieu

Le sam. 22 juin 2019 à 02:14, Greve, Douglas N.,Ph.D. <
dgr...@mgh.harvard.edu> a écrit :

> I'm not sure that this is a question we can answer. If you do smooth, then
> you should smooth both modalities the same amount.
>
> On 6/18/2019 10:12 PM, Matthieu Vanhoutte wrote:
>
> External Email - Use Caution
> Dear FS experts,
>
> I would like to compute within-subject correlation between two modalities
> based on vertexwise maps in fsaverage space. I wonder whether I have to
> smooth the normalized surface-based maps before computing vertexwise
> within-subject correlation?
>
> I have noted that smoothing surface maps before computing correlation
> increases the output correlation value.
>
> Thanks for your lights.
>
> Best,
> Matthieu
>
> ___
> 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

[Freesurfer] Within-subject vertexwise correlation

[Matthieu Vanhoutte]

External Email - Use Caution

Dear FS experts,

I would like to compute within-subject correlation between two modalities
based on vertexwise maps in fsaverage space. I wonder whether I have to
smooth the normalized surface-based maps before computing vertexwise
within-subject correlation?

I have noted that smoothing surface maps before computing correlation
increases the output correlation value.

Thanks for your lights.

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

[Freesurfer] Error with "recon-all -make all" following multiple manual editing

[Matthieu VANHOUTTE]

   External Email - Use Caution


Dear Freesurfer's experts,

Havng done multiple types of manual editing in two subjects, I 
relaunched the recon-all process (Freesurfer 6.0.1) with the flag "-make 
all".


However, during the process, I goth for both subjects the following 
error message: /

/

/make: *** 
[/netapp/vol2_agewell/pro/IMAP/imap_mvh/FS6.0.1/awellv1s097/mri/aseg.presurf.mgz] 
Error 1/


/recon-all -s /netapp/vol2_agewell/pro/IMAP/imap_mvh/FS6.0.1/awellv3s024 
-ccseg

ERROR: Flag -ccseg unrecognized./

Following the troubleshooting site 
(https://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/TroubleshootingDataV6.0) 
I have over-writed the "recon-all.makefile" file since I use the 6.0.1 
version of Freesurfer.


Thanks for helping.

Best,

Matthieu

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

Re: [Freesurfer] Left and right pial surfaces crossing in medial cortex

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Experts,

Would you have any advice?

Best,
Matthieu

Le mar. 26 mars 2019 à 13:54, Matthieu VANHOUTTE <
matthieuvanhou...@gmail.com> a écrit :

> Dear FS' experts,
>
> Using both T1 and FLAIR in recon-all to improve pial surfaces, I often
> have the case where pial surfaces from the left and right hemisphere are
> crossing in medial cortex (see attached images).
>
> Is it anormal and bad ? If so, How could I fix it ?
>
> Best,
>
> Matthieu
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] Recon editing + FLAIRpial

[Matthieu VANHOUTTE]

External Email - Use Caution

Dear Experts,

Having launched recon-all process on one subject with supplemental FLAIR 
data in order to better define pial surface, I still need to follow some 
recon editing during the QC of this patient.

However, when re-launching recon-all to take into account manual editing 
do I have to precise on more time "-FLAIR FLAIR.nii.gz -FLAIRpial" or 
will it be implicit?

Best regards,

Matthieu


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

Re: [Freesurfer] PETSurfer: Equivalence between surfaces un gtmseg space and native surface?

[Matthieu VANHOUTTE]

External Email - Use Caution

Ok so if I well understand surface in the gtmseg space would not have 
finer resolution than surface in native space (big voxel)?

On 06/03/2019 23:48, Greve, Douglas N.,Ph.D. wrote:
> I don't think so. The surfaces are at about 1mm resolution, which should
> be fine for this. The reason that RBV had to be upsampled is that there
> is no way to represent the different tissue types at a single (big) voxel
>
> On 3/6/19 4:46 PM, Matthieu Vanhoutte wrote:
>>  External Email - Use Caution
>>
>> Dear Douglas,
>>
>> RBV PVC use the advantage of upsampled gtmseg space at 0.5 mm3 to
>> compute PVCorrected images. Would it be beneficial to project this
>> PVCorrected images onto gtmseg space surfaces to keep this upsampled
>> resolution ?
>>
>> Or would it be equivalent to project these PVCorrected images on
>> gtmseg space onto native surfaces using --reg rbv2anat.lta ?
>>
>> Best,
>> Matthieu
>>
>> ___
>> 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] PETSurfer: Equivalence between surfaces un gtmseg space and native surface?

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Douglas,

RBV PVC use the advantage of upsampled gtmseg  space at 0.5 mm3 to compute
PVCorrected images. Would it be beneficial to project this PVCorrected
images onto gtmseg space surfaces to keep this upsampled resolution ?

Or would it be equivalent to project these PVCorrected images on gtmseg
space onto native surfaces using --reg rbv2anat.lta ?

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

Re: [Freesurfer] Recon-all XL defect detected...

[Matthieu VANHOUTTE]

   External Email - Use Caution


Hi Bruce,

Did you have time to tale a look at ?

Best,

Matthieu

On 19/02/2019 16:39, Bruce Fischl wrote:

will do
On Tue, 19 Feb 2019, Matthieu VANHOUTTE wrote:



External Email - Use Caution

Hi Bruce,

I don't see major thing that could be wrong.

I uploaded on the FileDrop the subject directory compressed. Could 
you have a look at it and tell me

what you think ?

Best,
Matthieu

On 18/02/2019 15:56, Bruce Fischl wrote:
  Hi Matthieu

  have you looked at the lh.inflated.nofix to see if anything 
major is wrong? The code
  doesn't exit when it detects an XL defect - it just warns you 
and doesn't search as
  thoroughly for solutions (which would take forever). It sounds 
like the 0 faces error is
  your problem, but they are likely related. Take a look at the 
inflated.nofix and see if
  you can identify the XL defect. It is probably near the back of 
the brain since it is

  one of the first defects encountered.

  cheers
  Bruce




   On Mon, 18 Feb 2019, Matthieu VANHOUTTE wrote:


    External Email - Use Caution

    Dear Freesurfer's experts,

    I have run recon-all on one subject and it stopped with a 
"XL defect

    detected..."  (please see below
    the log):

    #@# Fix Topology lh Sat Feb 16 08:22:31 CET 2019

     mris_fix_topology -rusage
/FS6.0.1/awellv3s013/touch/rusage.mris_fix_topology.lh.dat -mgz -sphere
    qsphere.nofix -ga -seed 1234 awellv3s013 lh

    reading spherical homeomorphism from 'qsphere.nofix'
    using genetic algorithm with optimized parameters
    setting seed for random number genererator to 1234

*
    Topology Correction Parameters
    retessellation mode:   genetic search
    number of patches/generation : 10
    number of generations :    10
    surface mri loglikelihood coefficient : 1.0
    volume mri loglikelihood coefficient :  10.0
    normal dot loglikelihood coefficient :  1.0
    quadratic curvature loglikelihood coefficient : 1.0
    volume resolution : 2
    eliminate vertices during search :  1
    initial patch selection :   1
    select all defect vertices :    0
    ordering dependant retessellation:  0
    use precomputed edge table :    0
    smooth retessellated patch :    2
    match retessellated patch : 1
    verbose mode :  0

*
    INFO: assuming .mgz format
    $Id: mris_fix_topology.c,v 1.50.2.1 2016/10/27 22:25:58 
zkaufman Exp $
      $Id: mrisurf.c,v 1.781.2.6 2016/12/27 16:47:14 zkaufman 
Exp $
    before topology correction, eno=-112 (nv=135382, 
nf=270988, ne=406482, g=57)
    using quasi-homeomorphic spherical map to tessellate 
cortical surface...


    Correction of the Topology
    Finding true center and radius of Spherical Surface...done
    Surface centered at (0,0,0) with radius 100.0 in 10 
iterations

    marking ambiguous vertices...
    39303 ambiguous faces found in tessellation
    segmenting defects...
    22 defects found, arbitrating ambiguous regions...
    analyzing neighboring defects...
      -merging segment 16 into 2
    21 defects to be corrected
    0 vertices coincident
    reading input surface 
FS6.0.1/awellv3s013/surf/lh.qsphere.nofix...

    reading brain volume from brain...
    reading wm segmentation from wm...
    Computing Initial Surface Statistics
      -face   loglikelihood: -9.1744  (-4.5872)
      -vertex loglikelihood: -6.3047  (-3.1523)
      -normal dot loglikelihood: -3.6091  (-3.6091)
      -quad curv  loglikelihood: -5.8524  (-2.9262)
      Total Loglikelihood : -24.9405

    CORRECTING DEFECT 0 (vertices=41, convex hull=76, v0=1825)
    After retessellation of defect 0 (v0=1825), euler #=-4
    (114791,342427,227632) : difference with
    theory (-18) = -14

    CORRECTING DEFECT 1 (vertices=22, convex hull=53, v0=6219)
    After retessellation of defect 1 (v0=6219), euler #=-3
    (114805,342485,227677) : difference with
    theory (-17) = -14

    CORRECTING DEFECT 2 (vertices=19736, convex hull=2755, 
v0=16117)

    normal vector of length zero at vertex 115020 with 0 faces
    vertex 115020 has 0 face

[Freesurfer] PETSurfer: Needs for gtmseg

[Matthieu VANHOUTTE]

External Email - Use Caution

Dear FS's experts,

In the perspective of correcting generated surfaces errors or defects, 
does the gtmseg command need corrected surfaces or could it be launch 
independently before having these corrected surfaces ?

Best,

Matthieu


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

Re: [Freesurfer] Recon-all XL defect detected...

[Matthieu VANHOUTTE]

   External Email - Use Caution


Hi Bruce,

I don't see major thing that could be wrong.

I uploaded on the FileDrop the subject directory compressed. Could you 
have a look at it and tell me what you think ?


Best,
Matthieu

On 18/02/2019 15:56, Bruce Fischl wrote:

Hi Matthieu

have you looked at the lh.inflated.nofix to see if anything major is 
wrong? The code doesn't exit when it detects an XL defect - it just 
warns you and doesn't search as thoroughly for solutions (which would 
take forever). It sounds like the 0 faces error is your problem, but 
they are likely related. Take a look at the inflated.nofix and see if 
you can identify the XL defect. It is probably near the back of the 
brain since it is one of the first defects encountered.


cheers
Bruce




 On Mon, 18 Feb 2019, Matthieu VANHOUTTE wrote:



External Email - Use Caution

Dear Freesurfer's experts,

I have run recon-all on one subject and it stopped with a "XL defect 
detected..."  (please see below

the log):

#@# Fix Topology lh Sat Feb 16 08:22:31 CET 2019

 mris_fix_topology -rusage 
/FS6.0.1/awellv3s013/touch/rusage.mris_fix_topology.lh.dat -mgz -sphere

qsphere.nofix -ga -seed 1234 awellv3s013 lh

reading spherical homeomorphism from 'qsphere.nofix'
using genetic algorithm with optimized parameters
setting seed for random number genererator to 1234

*
Topology Correction Parameters
retessellation mode:   genetic search
number of patches/generation : 10
number of generations :    10
surface mri loglikelihood coefficient : 1.0
volume mri loglikelihood coefficient :  10.0
normal dot loglikelihood coefficient :  1.0
quadratic curvature loglikelihood coefficient : 1.0
volume resolution : 2
eliminate vertices during search :  1
initial patch selection :   1
select all defect vertices :    0
ordering dependant retessellation:  0
use precomputed edge table :    0
smooth retessellated patch :    2
match retessellated patch : 1
verbose mode :  0

*
INFO: assuming .mgz format
$Id: mris_fix_topology.c,v 1.50.2.1 2016/10/27 22:25:58 zkaufman Exp $
  $Id: mrisurf.c,v 1.781.2.6 2016/12/27 16:47:14 zkaufman Exp $
before topology correction, eno=-112 (nv=135382, nf=270988, 
ne=406482, g=57)

using quasi-homeomorphic spherical map to tessellate cortical surface...

Correction of the Topology
Finding true center and radius of Spherical Surface...done
Surface centered at (0,0,0) with radius 100.0 in 10 iterations
marking ambiguous vertices...
39303 ambiguous faces found in tessellation
segmenting defects...
22 defects found, arbitrating ambiguous regions...
analyzing neighboring defects...
  -merging segment 16 into 2
21 defects to be corrected
0 vertices coincident
reading input surface FS6.0.1/awellv3s013/surf/lh.qsphere.nofix...
reading brain volume from brain...
reading wm segmentation from wm...
Computing Initial Surface Statistics
  -face   loglikelihood: -9.1744  (-4.5872)
  -vertex loglikelihood: -6.3047  (-3.1523)
  -normal dot loglikelihood: -3.6091  (-3.6091)
  -quad curv  loglikelihood: -5.8524  (-2.9262)
  Total Loglikelihood : -24.9405

CORRECTING DEFECT 0 (vertices=41, convex hull=76, v0=1825)
After retessellation of defect 0 (v0=1825), euler #=-4 
(114791,342427,227632) : difference with

theory (-18) = -14

CORRECTING DEFECT 1 (vertices=22, convex hull=53, v0=6219)
After retessellation of defect 1 (v0=6219), euler #=-3 
(114805,342485,227677) : difference with

theory (-17) = -14

CORRECTING DEFECT 2 (vertices=19736, convex hull=2755, v0=16117)
normal vector of length zero at vertex 115020 with 0 faces
vertex 115020 has 0 face
XL defect detected...
No such file or directory
Linux hpc1.cyceron.fr 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Jan 4 
01:06:37 UTC 2018 x86_64 x86_64

x86_64 GNU/Linux

recon-all -s awellv3s013 exited with ERRORS at Sat Feb 16 10:17:17 
CET 2019


I looked at the ?h.orig.nofix but didn't see anything wrong, despite 
the fact that these surfaces

are very not smooth.

What could I do ?

Best,

Matthieu





___
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] Recon-all XL defect detected...

[Matthieu VANHOUTTE]

   External Email - Use Caution


Dear Freesurfer's experts,

I have run recon-all on one subject and it stopped with a "XL defect 
detected..."  (please see below the log):


/#@# Fix Topology lh Sat Feb 16 08:22:31 CET 2019//
//
// mris_fix_topology -rusage 
/FS6.0.1/awellv3s013/touch/rusage.mris_fix_topology.lh.dat -mgz -sphere 
qsphere.nofix -ga -seed 1234 awellv3s013 lh //

//
//reading spherical homeomorphism from 'qsphere.nofix'//
//using genetic algorithm with optimized parameters//
//setting seed for random number genererator to 1234//
//
//*//
//Topology Correction Parameters//
//retessellation mode:   genetic search//
//number of patches/generation : 10//
//number of generations :    10//
//surface mri loglikelihood coefficient : 1.0//
//volume mri loglikelihood coefficient :  10.0//
//normal dot loglikelihood coefficient :  1.0//
//quadratic curvature loglikelihood coefficient : 1.0//
//volume resolution : 2//
//eliminate vertices during search :  1//
//initial patch selection :   1//
//select all defect vertices :    0//
//ordering dependant retessellation:  0//
//use precomputed edge table :    0//
//smooth retessellated patch :    2//
//match retessellated patch : 1//
//verbose mode :  0//
//
//*//
//INFO: assuming .mgz format//
//$Id: mris_fix_topology.c,v 1.50.2.1 2016/10/27 22:25:58 zkaufman Exp $//
//  $Id: mrisurf.c,v 1.781.2.6 2016/12/27 16:47:14 zkaufman Exp $//
//before topology correction, eno=-112 (nv=135382, nf=270988, ne=406482, 
g=57)//

//using quasi-homeomorphic spherical map to tessellate cortical surface...//
//
//Correction of the Topology//
//Finding true center and radius of Spherical Surface...done//
//Surface centered at (0,0,0) with radius 100.0 in 10 iterations//
//marking ambiguous vertices...//
//39303 ambiguous faces found in tessellation//
//segmenting defects...//
//22 defects found, arbitrating ambiguous regions...//
//analyzing neighboring defects...//
//  -merging segment 16 into 2//
//21 defects to be corrected //
//0 vertices coincident//
//reading input surface FS6.0.1/awellv3s013/surf/lh.qsphere.nofix...//
//reading brain volume from brain...//
//reading wm segmentation from wm...//
//Computing Initial Surface Statistics//
//  -face   loglikelihood: -9.1744  (-4.5872)//
//  -vertex loglikelihood: -6.3047  (-3.1523)//
//  -normal dot loglikelihood: -3.6091  (-3.6091)//
//  -quad curv  loglikelihood: -5.8524  (-2.9262)//
//  Total Loglikelihood : -24.9405//
//
//CORRECTING DEFECT 0 (vertices=41, convex hull=76, v0=1825)//
//After retessellation of defect 0 (v0=1825), euler #=-4 
(114791,342427,227632) : difference with theory (-18) = -14 //

//
//CORRECTING DEFECT 1 (vertices=22, convex hull=53, v0=6219)//
//After retessellation of defect 1 (v0=6219), euler #=-3 
(114805,342485,227677) : difference with theory (-17) = -14 //

//
//CORRECTING DEFECT 2 (vertices=19736, convex hull=2755, v0=16117)//
//normal vector of length zero at vertex 115020 with 0 faces//
//vertex 115020 has 0 face//
//XL defect detected...//
//No such file or directory//
//Linux hpc1.cyceron.fr 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Jan 4 
01:06:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux//

//
//recon-all -s awellv3s013 exited with ERRORS at Sat Feb 16 10:17:17 CET 
2019/


I looked at the ?h.orig.nofix but didn't see anything wrong, despite the 
fact that these surfaces are very not smooth.


What could I do ?

Best,

Matthieu

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

[Freesurfer] PETSurfer: Problem with "mri_gtmpvc --no-reduce-fov" + time consuming when using "--psf 0 --no-tfe"

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Douglas,

I wanted just to compute rescaled PET image without any PVC but following the 
same process as if I would have applied PVC. Moreover, I didn’t want to reduce 
FOV with auto mask generated (to still be in the gtmseg space). So I ran the 
following command:

mri_gtmpvc --i PET.lps.nii.gz --reg Pet2T1.register.dof6.lta --psf 0 --no-tfe 
--seg gtmseg.mgz --default-seg-merge --auto-mask PSF .01 --no-reduce-fov --rbv 
--o nopvc_nGMcerebpons --threads 4 --rescale 8 47 174

1) However, in the output directory rbv.nii.gz file still had a reduced fov:
  type: nii
dimensions: 297 x 381 x 363
   voxel sizes: 0.50, 0.50, 0.50
  type: FLOAT (3)
   fov: 148.500

Compared to the gtmseg.mgz:
 type: MGH
dimensions: 334 x 452 x 424
   voxel sizes: 0.50, 0.50, 0.50
  type: INT (1)
   fov: 226.000

I tried also to remove the —auto-mask option without success. Did I miss 
something?

2) I wonder why the process took so much time while there is just a rescaling 
to apply when using --psf 0 --no-tfe?

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

Re: [Freesurfer] PETSurfer: "mri_gtmpvc --psf 0 --no-tfe" voxel-wise output

[Matthieu Vanhoutte]

External Email - Use Caution

Le jeu. 14 févr. 2019 à 21:36, Greve, Douglas N.,Ph.D. <
dgr...@mgh.harvard.edu> a écrit :

>
>
> On 2/14/19 2:25 PM, Matthieu Vanhoutte wrote:
> >  External Email - Use Caution
> >
> >> Le 14 févr. 2019 à 19:37, Greve, Douglas N.,Ph.D. <
> dgr...@mgh.harvard.edu> a écrit :
> >>
> >>
> >>
> >> On 2/14/19 1:14 PM, Matthieu Vanhoutte wrote:
> >>>  External Email - Use Caution
> >>>
> >>>
> >>>
> >>> Le jeu. 14 févr. 2019 à 18:31, Greve, Douglas N.,Ph.D.
> >>> mailto:dgr...@mgh.harvard.edu>> a écrit :
> >>>
> >>>
> >>>
> >>> On 2/14/19 12:16 PM, Matthieu VANHOUTTE wrote:
> >>>>External Email - Use Caution
> >>>>
> >>>> Hi Douglas,
> >>>>
> >>>> So to register PET to gtmseg space mri_gtmpvc command use nearest
> >>>> neighbor, interpolation right ?
> >>> It does not map the PET to the gtmseg space. It maps the gtmseg to
> >>> the
> >>> PET space. Since this is a segmentation, it uses nearest neighbor.
> >>> But
> >>> the algorithm is much more complicated; see the paper.
> >>>
> >>>
> >>> Thank you I will look into the paper, I was wondering how not to loose
> >>> the gtmseg resolution ?
> >> I thought you wanted to turn off all PVC? If you want to correct for the
> >> tissue fraction effect, then don't use --no-tfe
> > Oh, I had to miss something. I didn’t know PVC had several components,
> whose one is tissue fraction effect… What are the different corrections
> applied during PVC ?
> Tissue fraction effect and correction for blur induced by the low res
> nature of pet. See the paper.
> > When papers mention no PVC they principally don’t correct for tissue
> fraction effect ?
> I don't know. Generally, people don't give many details on their method.
> >
> > I wanted to know what is the interest of computing a high resolution
> segmentation (gtmseg) if it goes to PET space and resliced to its lower
> resolution ?
> As I said before, this is not what happens. PETsurfer takes the TFE into
> account.
> Please see the paper for how it is done.
>

But in the case where --psf 0 --no-tfe are specified, isn't the high
resolution of gtmseg lost when rescaling intensities to mean reference
region ?

>
> >>> Concerning RBV PVC in which order and what type of interpolation are
> >>> used since PVE corrected output is on gtmseg_space ?
> >> This question does not make sense in the context of RBV. Each ROI gets a
> >> value, and this value is then assigned to all the voxels in that ROI in
> >> gtmseg prior to apply the RBV algorithm.
> > Ok thank you, so in RBV case native PET is interpolated (trilinear?)
> first to gtmseg space ?
> >
> >>>> And what about the interpolation method to use when projecting PVE
> >>>> corrected PET on surface  ?
> >>> I usually use nearest neighbor to avoid interpolation
> >>>
> >>>
> >>> Should you precise this on PETSurfer wiki since on the mri_vol2surf
> >>> command trilinear interpolation is used by default ?
> >> By default, mri_vol2surf uses nearest neighbor. mri_vol2vol uses trilin
> >> by default. An unfortunate inconsistency I made about 15 years ago and
> >> have been too afraid to change it:)
> > Thank you I didn’t know this one and supposed the trilinear as default
> as it is done in moi_vol2vol. Good to know it :)
> >
> >>> Best.
> >>>
> >>>> Thanks,
> >>>>
> >>>> Matthieu
> >>>>
> >>>> On 14/02/2019 17:44, Greve, Douglas N.,Ph.D. wrote:
> >>>>> The GTM operates on regions, so you can't do trilin interp. The
> >>>>> operations that you describe below are not used in mri_gtmpvc.
> >>> If  you
> >>>>> are trying to get something close to what the GTM does, then
> >>> use nearest
> >>>>> neighbor
> >>>>>
> >>>>> On 2/14/19 3:43 AM, Matthieu Vanhoutte wrote:
> >>>>>>  External Email - Use Caution
> >>>>>>
> >>>>>> Hi Douglas,
> >>>>>>
> >>>>>> Could you help me concerning my previous questions ?
> >>>>>>
> >>>>>> Thanks

Re: [Freesurfer] PETSurfer: "mri_gtmpvc --psf 0 --no-tfe" voxel-wise output

[Matthieu Vanhoutte]

External Email - Use Caution

> Le 14 févr. 2019 à 19:37, Greve, Douglas N.,Ph.D.  a 
> écrit :
> 
> 
> 
> On 2/14/19 1:14 PM, Matthieu Vanhoutte wrote:
>> 
>> External Email - Use Caution
>> 
>> 
>> 
>> Le jeu. 14 févr. 2019 à 18:31, Greve, Douglas N.,Ph.D. 
>> mailto:dgr...@mgh.harvard.edu>> a écrit :
>> 
>> 
>> 
>>On 2/14/19 12:16 PM, Matthieu VANHOUTTE wrote:
>>>   External Email - Use Caution
>>> 
>>> Hi Douglas,
>>> 
>>> So to register PET to gtmseg space mri_gtmpvc command use nearest
>>> neighbor, interpolation right ?
>>It does not map the PET to the gtmseg space. It maps the gtmseg to
>>the
>>PET space. Since this is a segmentation, it uses nearest neighbor.
>>But
>>the algorithm is much more complicated; see the paper.
>> 
>> 
>> Thank you I will look into the paper, I was wondering how not to loose 
>> the gtmseg resolution ?
> I thought you wanted to turn off all PVC? If you want to correct for the 
> tissue fraction effect, then don't use --no-tfe

Oh, I had to miss something. I didn’t know PVC had several components, whose 
one is tissue fraction effect… What are the different corrections applied 
during PVC ? When papers mention no PVC they principally don’t correct for 
tissue fraction effect ?

I wanted to know what is the interest of computing a high resolution 
segmentation (gtmseg) if it goes to PET space and resliced to its lower 
resolution ?

>> 
>> Concerning RBV PVC in which order and what type of interpolation are 
>> used since PVE corrected output is on gtmseg_space ?
> This question does not make sense in the context of RBV. Each ROI gets a 
> value, and this value is then assigned to all the voxels in that ROI in 
> gtmseg prior to apply the RBV algorithm.

Ok thank you, so in RBV case native PET is interpolated (trilinear?) first to 
gtmseg space ?

>> 
>>> 
>>> And what about the interpolation method to use when projecting PVE
>>> corrected PET on surface  ?
>>I usually use nearest neighbor to avoid interpolation
>> 
>> 
>> Should you precise this on PETSurfer wiki since on the mri_vol2surf 
>> command trilinear interpolation is used by default ?
> By default, mri_vol2surf uses nearest neighbor. mri_vol2vol uses trilin 
> by default. An unfortunate inconsistency I made about 15 years ago and 
> have been too afraid to change it:)

Thank you I didn’t know this one and supposed the trilinear as default as it is 
done in moi_vol2vol. Good to know it :)

>> 
>> Best.
>> 
>>> 
>>> Thanks,
>>> 
>>> Matthieu
>>> 
>>> On 14/02/2019 17:44, Greve, Douglas N.,Ph.D. wrote:
>>>> The GTM operates on regions, so you can't do trilin interp. The
>>>> operations that you describe below are not used in mri_gtmpvc.
>>If  you
>>>> are trying to get something close to what the GTM does, then
>>use nearest
>>>> neighbor
>>>> 
>>>> On 2/14/19 3:43 AM, Matthieu Vanhoutte wrote:
>>>>> External Email - Use Caution
>>>>> 
>>>>> Hi Douglas,
>>>>> 
>>>>> Could you help me concerning my previous questions ?
>>>>> 
>>>>> Thanks,
>>>>> Matthieu
>>>>> 
>>>>>> Le 11 févr. 2019 à 17:37, Matthieu VANHOUTTE
>>mailto:matthieuvanhou...@gmail.com>>
>>a écrit :
>>>>>> 
>>>>>> Hi Douglas,
>>>>>> 
>>>>>> Thanks for clarification. Why use "nearest neighbor" instead
>>of classical "trilinear" interpolation ?
>>>>>> 
>>>>>> Should it be done as well when projecting from volume to
>>surface with mri_vol2surf ?
>>>>>> 
>>>>>> Best,
>>>>>> 
>>>>>> Matthieu
>>>>>> 
>>>>>> On 11/02/2019 17:32, Greve, Douglas N.,Ph.D. wrote:
>>>>>>> It will not used trilinear interp. Try it with nearest neighbor
>>>>>>> 
>>>>>>> On 2/10/19 11:55 AM, Matthieu Vanhoutte wrote:
>>>>>>>>  External Email - Use Caution
>>>>>>>> 
>>>>>>>> Dear Douglas,
>>>>>>>> 
>>>>>>>> Before using "mri_gtmpvc --psf 0 --no-tfe -- rbv" according
>>your advice to obtain voxel-wise output rescaled w

Re: [Freesurfer] PETSurfer: "mri_gtmpvc --psf 0 --no-tfe" voxel-wise output

[Matthieu Vanhoutte]

External Email - Use Caution

Le jeu. 14 févr. 2019 à 18:31, Greve, Douglas N.,Ph.D. <
dgr...@mgh.harvard.edu> a écrit :

>
>
> On 2/14/19 12:16 PM, Matthieu VANHOUTTE wrote:
> >  External Email - Use Caution
> >
> > Hi Douglas,
> >
> > So to register PET to gtmseg space mri_gtmpvc command use nearest
> > neighbor, interpolation right ?
> It does not map the PET to the gtmseg space. It maps the gtmseg to the
> PET space. Since this is a segmentation, it uses nearest neighbor. But
> the algorithm is much more complicated; see the paper.
>

Thank you I will look into the paper, I was wondering how not to loose the
gtmseg resolution ?

Concerning RBV PVC in which order and what type of interpolation are used
since PVE corrected output is on gtmseg_space ?

>
> > And what about the interpolation method to use when projecting PVE
> > corrected PET on surface  ?
> I usually use nearest neighbor to avoid interpolation
>

Should you precise this on PETSurfer wiki since on the mri_vol2surf command
trilinear interpolation is used by default ?

Best.

>
> > Thanks,
> >
> > Matthieu
> >
> > On 14/02/2019 17:44, Greve, Douglas N.,Ph.D. wrote:
> >> The GTM operates on regions, so you can't do trilin interp. The
> >> operations that you describe below are not used in mri_gtmpvc. If  you
> >> are trying to get something close to what the GTM does, then use nearest
> >> neighbor
> >>
> >> On 2/14/19 3:43 AM, Matthieu Vanhoutte wrote:
> >>>External Email - Use Caution
> >>>
> >>> Hi Douglas,
> >>>
> >>> Could you help me concerning my previous questions ?
> >>>
> >>> Thanks,
> >>> Matthieu
> >>>
> >>>> Le 11 févr. 2019 à 17:37, Matthieu VANHOUTTE <
> matthieuvanhou...@gmail.com> a écrit :
> >>>>
> >>>> Hi Douglas,
> >>>>
> >>>> Thanks for clarification. Why use "nearest neighbor" instead of
> classical "trilinear" interpolation ?
> >>>>
> >>>> Should it be done as well when projecting from volume to surface with
> mri_vol2surf ?
> >>>>
> >>>> Best,
> >>>>
> >>>> Matthieu
> >>>>
> >>>> On 11/02/2019 17:32, Greve, Douglas N.,Ph.D. wrote:
> >>>>> It will not used trilinear interp. Try it with nearest neighbor
> >>>>>
> >>>>> On 2/10/19 11:55 AM, Matthieu Vanhoutte wrote:
> >>>>>> External Email - Use Caution
> >>>>>>
> >>>>>> Dear Douglas,
> >>>>>>
> >>>>>> Before using "mri_gtmpvc --psf 0 --no-tfe -- rbv" according your
> advice to obtain voxel-wise output rescaled without PVC correction, I have
> done sequentially the different steps to obtain this output. However, when
> comparing voxel-wise rescaled output (rbv.nii.gz) between the two methods,
> final values at each voxel are not the same…
> >>>>>>
> >>>>>> To obtain first rescaled voxel-wise output I have used sequentially
> these steps:
> >>>>>> 1.   Concatenate transforms from PET space to gtmseg.mgz
> >>>>>> 2.   Register native PET into gtmseg space (trilin.
> interpolation)
> >>>>>> 3.   Compute mean PET inside reference regions (with regions
> masks from gtmseg.mgz)
> >>>>>> 4.   Compute intensity normalized PET images in gtmseg space
> >>>>>>
> >>>>>> Doesn’t the "mri_gtmpvc --psf 0 --no-tfe -- rdv" command use these
> same steps ?
> >>>>>>
> >>>>>> Best,
> >>>>>> Matthieu
> >>>>>>
> >>>>>> ___
> >>>>>> 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
> > ___
> > 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] PETSurfer: "mri_gtmpvc --psf 0 --no-tfe" voxel-wise output

[Matthieu VANHOUTTE]

External Email - Use Caution

Hi Douglas,

So to register PET to gtmseg space mri_gtmpvc command use nearest 
neighbor, interpolation right ?

And what about the interpolation method to use when projecting PVE 
corrected PET on surface  ?

Thanks,

Matthieu

On 14/02/2019 17:44, Greve, Douglas N.,Ph.D. wrote:
> The GTM operates on regions, so you can't do trilin interp. The
> operations that you describe below are not used in mri_gtmpvc. If  you
> are trying to get something close to what the GTM does, then use nearest
> neighbor
>
> On 2/14/19 3:43 AM, Matthieu Vanhoutte wrote:
>>   External Email - Use Caution
>>
>> Hi Douglas,
>>
>> Could you help me concerning my previous questions ?
>>
>> Thanks,
>> Matthieu
>>
>>> Le 11 févr. 2019 à 17:37, Matthieu VANHOUTTE  
>>> a écrit :
>>>
>>> Hi Douglas,
>>>
>>> Thanks for clarification. Why use "nearest neighbor" instead of classical 
>>> "trilinear" interpolation ?
>>>
>>> Should it be done as well when projecting from volume to surface with 
>>> mri_vol2surf ?
>>>
>>> Best,
>>>
>>> Matthieu
>>>
>>> On 11/02/2019 17:32, Greve, Douglas N.,Ph.D. wrote:
>>>> It will not used trilinear interp. Try it with nearest neighbor
>>>>
>>>> On 2/10/19 11:55 AM, Matthieu Vanhoutte wrote:
>>>>>External Email - Use Caution
>>>>>
>>>>> Dear Douglas,
>>>>>
>>>>> Before using "mri_gtmpvc --psf 0 --no-tfe -- rbv" according your advice 
>>>>> to obtain voxel-wise output rescaled without PVC correction, I have done 
>>>>> sequentially the different steps to obtain this output. However, when 
>>>>> comparing voxel-wise rescaled output (rbv.nii.gz) between the two 
>>>>> methods, final values at each voxel are not the same…
>>>>>
>>>>> To obtain first rescaled voxel-wise output I have used sequentially these 
>>>>> steps:
>>>>> 1.Concatenate transforms from PET space to gtmseg.mgz
>>>>> 2.Register native PET into gtmseg space (trilin. interpolation)
>>>>> 3.Compute mean PET inside reference regions (with regions masks 
>>>>> from gtmseg.mgz)
>>>>> 4.Compute intensity normalized PET images in gtmseg space
>>>>>
>>>>> Doesn’t the "mri_gtmpvc --psf 0 --no-tfe -- rdv" command use these same 
>>>>> steps ?
>>>>>
>>>>> Best,
>>>>> Matthieu
>>>>>
>>>>> ___
>>>>> 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

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

Re: [Freesurfer] PETSurfer: "mri_gtmpvc --psf 0 --no-tfe" voxel-wise output

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

Could you help me concerning my previous questions ?

Thanks,
Matthieu

> Le 11 févr. 2019 à 17:37, Matthieu VANHOUTTE  a 
> écrit :
> 
> Hi Douglas,
> 
> Thanks for clarification. Why use "nearest neighbor" instead of classical 
> "trilinear" interpolation ?
> 
> Should it be done as well when projecting from volume to surface with 
> mri_vol2surf ?
> 
> Best,
> 
> Matthieu
> 
> On 11/02/2019 17:32, Greve, Douglas N.,Ph.D. wrote:
>> It will not used trilinear interp. Try it with nearest neighbor
>> 
>> On 2/10/19 11:55 AM, Matthieu Vanhoutte wrote:
>>>  External Email - Use Caution
>>> 
>>> Dear Douglas,
>>> 
>>> Before using "mri_gtmpvc --psf 0 --no-tfe -- rbv" according your advice to 
>>> obtain voxel-wise output rescaled without PVC correction, I have done 
>>> sequentially the different steps to obtain this output. However, when 
>>> comparing voxel-wise rescaled output (rbv.nii.gz) between the two methods, 
>>> final values at each voxel are not the same…
>>> 
>>> To obtain first rescaled voxel-wise output I have used sequentially these 
>>> steps:
>>> 1.  Concatenate transforms from PET space to gtmseg.mgz
>>> 2.  Register native PET into gtmseg space (trilin. interpolation)
>>> 3.  Compute mean PET inside reference regions (with regions masks from 
>>> gtmseg.mgz)
>>> 4.  Compute intensity normalized PET images in gtmseg space
>>> 
>>> Doesn’t the "mri_gtmpvc --psf 0 --no-tfe -- rdv" command use these same 
>>> steps ?
>>> 
>>> Best,
>>> Matthieu
>>> 
>>> ___
>>> 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] PETSurfer: "mri_gtmpvc --psf 0 --no-tfe" voxel-wise output

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Douglas,

Before using "mri_gtmpvc --psf 0 --no-tfe -- rbv" according your advice to 
obtain voxel-wise output rescaled without PVC correction, I have done 
sequentially the different steps to obtain this output. However, when comparing 
voxel-wise rescaled output (rbv.nii.gz) between the two methods, final values 
at each voxel are not the same…

To obtain first rescaled voxel-wise output I have used sequentially these steps:
1.  Concatenate transforms from PET space to gtmseg.mgz 
2.  Register native PET into gtmseg space (trilin. interpolation)
3.  Compute mean PET inside reference regions (with regions masks from 
gtmseg.mgz)
4.  Compute intensity normalized PET images in gtmseg space

Doesn’t the "mri_gtmpvc --psf 0 --no-tfe -- rdv" command use these same steps ?

Best,
Matthieu

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

Re: [Freesurfer] [PETSurfer] Intensity normalization of PET images without PVE correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

Any advice ?

Best.

Le jeu. 7 févr. 2019 à 23:12, Matthieu Vanhoutte <
matthieuvanhou...@gmail.com> a écrit :

> Yes that's what I mean. But does this command provide an intensity
> normalized voxel-wise image ?
>
> Could you explain me the realign & reslice steps from the native PET to
> the voxel-wise PVC PET for MGX ans RBV ?
>
> Best,
> Matthieu
>
> Le jeu. 7 févr. 2019 à 23:06, Greve, Douglas N.,Ph.D. <
> dgr...@mgh.harvard.edu> a écrit :
>
>> Do you mean the mean intensity not corrected for PVC? I would just run
>> mri_gtmpvc with --psf 0 --no-tfe to turn off PVC
>>
>> On 2/7/19 4:40 PM, Matthieu Vanhoutte wrote:
>> >
>> > External Email - Use Caution
>> >
>> > Hello experts,
>> >
>> > Anyone would have an advice on my previous questions ?
>> >
>> > Best,
>> > Matthieu
>> >
>> >
>> > Le mer. 30 janv. 2019 à 14:49, Matthieu Vanhoutte
>> > mailto:matthieuvanhou...@gmail.com>> a
>> > écrit :
>> >
>> > Hi Douglas,
>> >
>> > In order to apply intensity normalization to non-PVC PET images
>> > based on mean intensity from reference region in gtmseg.mgz, is it
>> > better to realign & reslice PET image onto gtmseg space or the
>> > reverse way ? How is it done when dealing with PVC images using
>> > gtmpvc command ?
>> >
>> > I would like to avoid too many reslicing operations before volume
>> > to surface projection, how would you deal with it ?
>> >
>> > Best,
>> > Matthieu
>> >
>> >> Le 28 janv. 2019 à 17:41, Greve, Douglas N.,Ph.D.
>> >> mailto:dgr...@mgh.harvard.edu>> a écrit :
>> >>
>> >> If you intend to use one of the aseg structures, then they are
>> >> the same.
>> >>
>> >> On 1/28/19 10:14 AM, Matthieu Vanhoutte wrote:
>> >>>
>> >>> External Email - Use Caution
>> >>>
>> >>> Hi Douglas,
>> >>>
>> >>>
>> >>>> Le 25 janv. 2019 à 18:01, Greve, Douglas N.,Ph.D.
>> >>>> mailto:dgr...@mgh.harvard.edu>> a
>> écrit :
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 1/25/19 7:57 AM, Matthieu Vanhoutte wrote:
>> >>>>>
>> >>>>> External Email - Use Caution
>> >>>>>
>> >>>>> Dear Douglas,
>> >>>>>
>> >>>>> Could you precise me:
>> >>>>> 1) Is the intensity rescaling of PET image included in the
>> >>>>> mri_gtmpvc command based on reference region in gtmseg.mgz
>> >>>>> file rather than aseg.mgz ?
>> >>>> It depends. If you are using pons, then that is not part of the
>> >>>> aseg and is generated as part of the creation of gtmseg. But
>> >>>> most of the rest of gtmseg is derived from the aseg and surfaces.
>> >>>
>> >>> Is it better to use gtmseg.mgz or aseg.mgz to extract reference
>> >>> region’s mean intensity ?
>> >>>
>> >>>
>> >>>>> 2) Is this rescaling applied before PVE correction or after
>> >>>>> (i.e. based on PVE corrected reference region’s mean intensity)
>> ?
>> >>>> After
>> >>>>>
>> >>>>> Many thanks in advance for helping.
>> >>>>>
>> >>>>> Best,
>> >>>>> Matthieu
>> >>>>>
>> >>>>>> Le 7 janv. 2019 à 17:26, Greve, Douglas N.,Ph.D.
>> >>>>>> mailto:dgr...@mgh.harvard.edu>> a
>> >>>>>> écrit :
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On 1/7/19 11:18 AM, Matthieu Vanhoutte wrote:
>> >>>>>>>
>> >>>>>>> External Email - Use Caution
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> I used the following command to obtain only rescaled
>> >>>>>>> voxel-wise PET image (with no PVC):
&

Re: [Freesurfer] [PETSurfer] Intensity normalization of PET images without PVE correction

[Matthieu Vanhoutte]

External Email - Use Caution

Yes that's what I mean. But does this command provide an intensity
normalized voxel-wise image ?

Could you explain me the realign & reslice steps from the native PET to the
voxel-wise PVC PET for MGX ans RBV ?

Best,
Matthieu

Le jeu. 7 févr. 2019 à 23:06, Greve, Douglas N.,Ph.D. <
dgr...@mgh.harvard.edu> a écrit :

> Do you mean the mean intensity not corrected for PVC? I would just run
> mri_gtmpvc with --psf 0 --no-tfe to turn off PVC
>
> On 2/7/19 4:40 PM, Matthieu Vanhoutte wrote:
> >
> > External Email - Use Caution
> >
> > Hello experts,
> >
> > Anyone would have an advice on my previous questions ?
> >
> > Best,
> > Matthieu
> >
> >
> > Le mer. 30 janv. 2019 à 14:49, Matthieu Vanhoutte
> > mailto:matthieuvanhou...@gmail.com>> a
> > écrit :
> >
> > Hi Douglas,
> >
> > In order to apply intensity normalization to non-PVC PET images
> > based on mean intensity from reference region in gtmseg.mgz, is it
> > better to realign & reslice PET image onto gtmseg space or the
> > reverse way ? How is it done when dealing with PVC images using
> > gtmpvc command ?
> >
> > I would like to avoid too many reslicing operations before volume
> > to surface projection, how would you deal with it ?
> >
> > Best,
> > Matthieu
> >
> >> Le 28 janv. 2019 à 17:41, Greve, Douglas N.,Ph.D.
> >> mailto:dgr...@mgh.harvard.edu>> a écrit :
> >>
> >> If you intend to use one of the aseg structures, then they are
> >> the same.
> >>
> >> On 1/28/19 10:14 AM, Matthieu Vanhoutte wrote:
> >>>
> >>> External Email - Use Caution
> >>>
> >>> Hi Douglas,
> >>>
> >>>
> >>>> Le 25 janv. 2019 à 18:01, Greve, Douglas N.,Ph.D.
> >>>> mailto:dgr...@mgh.harvard.edu>> a écrit
> :
> >>>>
> >>>>
> >>>>
> >>>> On 1/25/19 7:57 AM, Matthieu Vanhoutte wrote:
> >>>>>
> >>>>> External Email - Use Caution
> >>>>>
> >>>>> Dear Douglas,
> >>>>>
> >>>>> Could you precise me:
> >>>>> 1) Is the intensity rescaling of PET image included in the
> >>>>> mri_gtmpvc command based on reference region in gtmseg.mgz
> >>>>> file rather than aseg.mgz ?
> >>>> It depends. If you are using pons, then that is not part of the
> >>>> aseg and is generated as part of the creation of gtmseg. But
> >>>> most of the rest of gtmseg is derived from the aseg and surfaces.
> >>>
> >>> Is it better to use gtmseg.mgz or aseg.mgz to extract reference
> >>> region’s mean intensity ?
> >>>
> >>>
> >>>>> 2) Is this rescaling applied before PVE correction or after
> >>>>> (i.e. based on PVE corrected reference region’s mean intensity) ?
> >>>> After
> >>>>>
> >>>>> Many thanks in advance for helping.
> >>>>>
> >>>>> Best,
> >>>>> Matthieu
> >>>>>
> >>>>>> Le 7 janv. 2019 à 17:26, Greve, Douglas N.,Ph.D.
> >>>>>> mailto:dgr...@mgh.harvard.edu>> a
> >>>>>> écrit :
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 1/7/19 11:18 AM, Matthieu Vanhoutte wrote:
> >>>>>>>
> >>>>>>> External Email - Use Caution
> >>>>>>>
> >>>>>>>
> >>>>>>> I used the following command to obtain only rescaled
> >>>>>>> voxel-wise PET image (with no PVC):
> >>>>>>> /mri_gtmpvc --i PET.nii.gz --reg Pet2T1.register.dof6.lta
> >>>>>>> --psf 0 --no-tfe --seg gtmseg.mgz --default-seg-merge
> >>>>>>> --auto-mask PSF .01 --rbv --o  nopvc/
> >>>>>>>
> >>>>>>> If I omitted/--rbv/or/--mgx/option//I didn't get the
> >>>>>>> rescaled voxel-wise PET image (without PVC). Could I obtain
> >>>>>>> the rescaled voxel-wise PET image (without PVC) just 

Re: [Freesurfer] [PETSurfer] Intensity normalization of PET images without PVE correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hello experts,

Anyone would have an advice on my previous questions ?

Best,
Matthieu


Le mer. 30 janv. 2019 à 14:49, Matthieu Vanhoutte <
matthieuvanhou...@gmail.com> a écrit :

> Hi Douglas,
>
> In order to apply intensity normalization to non-PVC PET images based on
> mean intensity from reference region in gtmseg.mgz, is it better to realign
> & reslice PET image onto gtmseg space or the reverse way ? How is it done
> when dealing with PVC images using gtmpvc command ?
>
> I would like to avoid too many reslicing operations before volume to
> surface projection, how would you deal with it ?
>
> Best,
> Matthieu
>
> Le 28 janv. 2019 à 17:41, Greve, Douglas N.,Ph.D. 
> a écrit :
>
> If you intend to use one of the aseg structures, then they are the same.
>
> On 1/28/19 10:14 AM, Matthieu Vanhoutte wrote:
>
> External Email - Use Caution
> Hi Douglas,
>
>
> Le 25 janv. 2019 à 18:01, Greve, Douglas N.,Ph.D. 
> a écrit :
>
>
>
> On 1/25/19 7:57 AM, Matthieu Vanhoutte wrote:
>
> External Email - Use Caution
> Dear Douglas,
>
> Could you precise me:
> 1) Is the intensity rescaling of PET image included in the mri_gtmpvc
> command based on reference region in gtmseg.mgz file rather than aseg.mgz ?
>
> It depends. If you are using pons, then that is not part of the aseg and
> is generated as part of the creation of gtmseg. But most of the rest of
> gtmseg is derived from the aseg and surfaces.
>
>
> Is it better to use gtmseg.mgz or aseg.mgz to extract reference region’s
> mean intensity ?
>
>
> 2) Is this rescaling applied before PVE correction or after (i.e. based on
> PVE corrected reference region’s mean intensity) ?
>
> After
>
>
> Many thanks in advance for helping.
>
> Best,
> Matthieu
>
> Le 7 janv. 2019 à 17:26, Greve, Douglas N.,Ph.D. 
> a écrit :
>
>
>
> On 1/7/19 11:18 AM, Matthieu Vanhoutte wrote:
>
> External Email - Use Caution
>
> I used the following command to obtain only rescaled voxel-wise PET image
> (with no PVC):
> *mri_gtmpvc --i PET.nii.gz --reg Pet2T1.register.dof6.lta --psf 0 --no-tfe
> --seg gtmseg.mgz --default-seg-merge --auto-mask PSF .01 --rbv --o  nopvc*
>
> If I omitted *--rbv *or* --mgx* option I didn't get the rescaled
> voxel-wise PET image (without PVC). Could I obtain the rescaled voxel-wise
> PET image (without PVC) just by dividing each voxel of the native PET image
> by the mean of the reference region ?
>
> Yes
>
>
> Best,
> Matt
>
> Le lun. 7 janv. 2019 à 16:01, Greve, Douglas N.,Ph.D. <
> dgr...@mgh.harvard.edu> a écrit :
>
>> I'm not sure what you mean. If you are turning off PVC, why are you
>> computing RBV and MGX? What is your command line? What do you mean that
>> these options don't seem to work?
>>
>> On 12/21/18 2:22 PM, Matthieu Vanhoutte wrote:
>>
>> External Email - Use Caution
>> Hi Douglas,
>>
>> Thanks for helping.
>>
>> To have an only rescaled voxel-wise PET image, these options seem to work
>> only when -rbv method is used and not -mgx.
>>
>> Do you know why ?
>>
>> Best,
>> Matthieu
>>
>>
>> Le mar. 18 déc. 2018 à 17:58, Greve, Douglas N.,Ph.D. <
>> dgr...@mgh.harvard.edu> a écrit :
>>
>>> You will need to set --psf 0 and --no-tfe to fully turn off PVC.
>>>
>>> On 12/18/18 4:50 AM, Matthieu Vanhoutte wrote:
>>>
>>> External Email - Use Caution
>>> Hi Douglas,
>>>
>>> Could you help me on this point ?
>>>
>>> Best,
>>> Matthieu
>>>
>>>
>>> Le mer. 12 déc. 2018 à 10:50, Matthieu Vanhoutte <
>>> matthieuvanhou...@gmail.com> a écrit :
>>>
>>>> Dear Douglas,
>>>>
>>>> Is it possible to use mri_gtmpvc command in order to intensity
>>>> normalize PET images without applying PVE correction by setting --psf to 0 
>>>> ?
>>>>
>>>> Best,
>>>> Matthieu
>>>>
>>>
>>>
>>> ___
>>> 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
>>
>>
>> ___
>> Free

Re: [Freesurfer] [PETSurfer] Intensity normalization of PET images without PVE correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

Could you answer to my previous question ?

Best,
Matthieu

> Le 30 janv. 2019 à 14:48, Matthieu Vanhoutte  a 
> écrit :
> 
> Hi Douglas,
> 
> In order to apply intensity normalization to non-PVC PET images based on mean 
> intensity from reference region in gtmseg.mgz, is it better to realign & 
> reslice PET image onto gtmseg space or the reverse way ? How is it done when 
> dealing with PVC images using gtmpvc command ?
> 
> I would like to avoid too many reslicing operations before volume to surface 
> projection, how would you deal with it ?
> 
> Best,
> Matthieu
> 
>> Le 28 janv. 2019 à 17:41, Greve, Douglas N.,Ph.D. > <mailto:dgr...@mgh.harvard.edu>> a écrit :
>> 
>> If you intend to use one of the aseg structures, then they are the same. 
>> 
>> On 1/28/19 10:14 AM, Matthieu Vanhoutte wrote:
>>> External Email - Use Caution
>>> 
>>> Hi Douglas,
>>> 
>>> 
>>>> Le 25 janv. 2019 à 18:01, Greve, Douglas N.,Ph.D. >>> <mailto:dgr...@mgh.harvard.edu>> a écrit :
>>>> 
>>>> 
>>>> 
>>>> On 1/25/19 7:57 AM, Matthieu Vanhoutte wrote:
>>>>> External Email - Use Caution
>>>>> 
>>>>> Dear Douglas,
>>>>> 
>>>>> Could you precise me:
>>>>> 1) Is the intensity rescaling of PET image included in the mri_gtmpvc 
>>>>> command based on reference region in gtmseg.mgz file rather than aseg.mgz 
>>>>> ?
>>>> It depends. If you are using pons, then that is not part of the aseg and 
>>>> is generated as part of the creation of gtmseg. But most of the rest of 
>>>> gtmseg is derived from the aseg and surfaces.
>>> 
>>> Is it better to use gtmseg.mgz or aseg.mgz to extract reference region’s 
>>> mean intensity ?
>>> 
>>> 
>>>>> 2) Is this rescaling applied before PVE correction or after (i.e. based 
>>>>> on PVE corrected reference region’s mean intensity) ?
>>>> After
>>>>> 
>>>>> Many thanks in advance for helping.
>>>>> 
>>>>> Best,
>>>>> Matthieu
>>>>> 
>>>>>> Le 7 janv. 2019 à 17:26, Greve, Douglas N.,Ph.D. >>>>> <mailto:dgr...@mgh.harvard.edu>> a écrit :
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 1/7/19 11:18 AM, Matthieu Vanhoutte wrote:
>>>>>>> External Email - Use Caution
>>>>>>> 
>>>>>>> 
>>>>>>> I used the following command to obtain only rescaled voxel-wise PET 
>>>>>>> image (with no PVC):
>>>>>>> mri_gtmpvc --i PET.nii.gz --reg Pet2T1.register.dof6.lta --psf 0 
>>>>>>> --no-tfe --seg gtmseg.mgz --default-seg-merge --auto-mask PSF .01 --rbv 
>>>>>>> --o  nopvc
>>>>>>> 
>>>>>>> If I omitted --rbv or --mgx option I didn't get the rescaled voxel-wise 
>>>>>>> PET image (without PVC). Could I obtain the rescaled voxel-wise PET 
>>>>>>> image (without PVC) just by dividing each voxel of the native PET image 
>>>>>>> by the mean of the reference region ?
>>>>>> Yes
>>>>>>> 
>>>>>>> Best,
>>>>>>> Matt
>>>>>>> 
>>>>>>> Le lun. 7 janv. 2019 à 16:01, Greve, Douglas N.,Ph.D. 
>>>>>>> mailto:dgr...@mgh.harvard.edu>> a écrit :
>>>>>>> I'm not sure what you mean. If you are turning off PVC, why are you 
>>>>>>> computing RBV and MGX? What is your command line? What do you mean that 
>>>>>>> these options don't seem to work?
>>>>>>> 
>>>>>>> On 12/21/18 2:22 PM, Matthieu Vanhoutte wrote:
>>>>>>>> External Email - Use Caution
>>>>>>>> 
>>>>>>>> Hi Douglas,
>>>>>>>> 
>>>>>>>> Thanks for helping.
>>>>>>>> 
>>>>>>>> To have an only rescaled voxel-wise PET image, these options seem to 
>>>>>>>> work only when -rbv method is used and not -mgx.
>>>>>>>> 
>>>>>>>> Do you know why ?
>>>>>>>>

[Freesurfer] Combination of multiple PET projection: "mri_vol2surf --projfrac" vs. "mris_expand"

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Freesurfer’s experts,

I have read the paper from Marcoux, et al. « An Automated Pipeline for the 
Analysis of PET Data on the Cortical Surface ». Frontiers in Neuroinformatics 
12 (10 décembre 2018). https://doi.org/10.3389/fninf.2018.00094 
. In this paper, they propose a 
robust PET signal projection based on weighting multiple PET projections at 
different fractions of the cortical thickness. They used « mris_expand" instead 
of "mri_vol2surf --projfrac" based on the following comments:

"We mainly rely on the mris_expand function of FreeSurfer rather than on 
vol2surf. The vol2surf function allows the user to project volume data onto the 
cortical surface by sampling along the normal of the white surface, by steps 
corresponding to fractions of the cortical thickness. We observed that the main 
issue with this approach is its lack of accuracy and robustness, as there is no 
constraint to ensure that the last sample will be on the corresponding vertex 
of the pial surface. Another solution proposed by FreeSurfer is to use the 
normal fromthemid surface, starting on the side of the white surface and going 
toward the pial surface, sampling by steps proportional to the thickness. Here 
again we observed that, because of different folding patterns, sampling points 
could be located outside the cortical ribbon. Our approach, using deformable 
surfaces obtained with mris_expand, ensures that the seven surfaces that are 
used to project the signal follow the folding patterns and stay within the 
cortical ribbon."

Is "mris_expand" more accurate and robust than "mri_vol2surf --projfrac" 
according to you ?

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

Re: [Freesurfer] [PETSurfer] Intensity normalization of PET images without PVE correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

In order to apply intensity normalization to non-PVC PET images based on mean 
intensity from reference region in gtmseg.mgz, is it better to realign & 
reslice PET image onto gtmseg space or the reverse way ? How is it done when 
dealing with PVC images using gtmpvc command ?

I would like to avoid too many reslicing operations before volume to surface 
projection, how would you deal with it ?

Best,
Matthieu

> Le 28 janv. 2019 à 17:41, Greve, Douglas N.,Ph.D.  a 
> écrit :
> 
> If you intend to use one of the aseg structures, then they are the same. 
> 
> On 1/28/19 10:14 AM, Matthieu Vanhoutte wrote:
>> External Email - Use Caution
>> 
>> Hi Douglas,
>> 
>> 
>>> Le 25 janv. 2019 à 18:01, Greve, Douglas N.,Ph.D. >> <mailto:dgr...@mgh.harvard.edu>> a écrit :
>>> 
>>> 
>>> 
>>> On 1/25/19 7:57 AM, Matthieu Vanhoutte wrote:
>>>> External Email - Use Caution
>>>> 
>>>> Dear Douglas,
>>>> 
>>>> Could you precise me:
>>>> 1) Is the intensity rescaling of PET image included in the mri_gtmpvc 
>>>> command based on reference region in gtmseg.mgz file rather than aseg.mgz ?
>>> It depends. If you are using pons, then that is not part of the aseg and is 
>>> generated as part of the creation of gtmseg. But most of the rest of gtmseg 
>>> is derived from the aseg and surfaces.
>> 
>> Is it better to use gtmseg.mgz or aseg.mgz to extract reference region’s 
>> mean intensity ?
>> 
>> 
>>>> 2) Is this rescaling applied before PVE correction or after (i.e. based on 
>>>> PVE corrected reference region’s mean intensity) ?
>>> After
>>>> 
>>>> Many thanks in advance for helping.
>>>> 
>>>> Best,
>>>> Matthieu
>>>> 
>>>>> Le 7 janv. 2019 à 17:26, Greve, Douglas N.,Ph.D. >>>> <mailto:dgr...@mgh.harvard.edu>> a écrit :
>>>>> 
>>>>> 
>>>>> 
>>>>> On 1/7/19 11:18 AM, Matthieu Vanhoutte wrote:
>>>>>> External Email - Use Caution
>>>>>> 
>>>>>> 
>>>>>> I used the following command to obtain only rescaled voxel-wise PET 
>>>>>> image (with no PVC):
>>>>>> mri_gtmpvc --i PET.nii.gz --reg Pet2T1.register.dof6.lta --psf 0 
>>>>>> --no-tfe --seg gtmseg.mgz --default-seg-merge --auto-mask PSF .01 --rbv 
>>>>>> --o  nopvc
>>>>>> 
>>>>>> If I omitted --rbv or --mgx option I didn't get the rescaled voxel-wise 
>>>>>> PET image (without PVC). Could I obtain the rescaled voxel-wise PET 
>>>>>> image (without PVC) just by dividing each voxel of the native PET image 
>>>>>> by the mean of the reference region ?
>>>>> Yes
>>>>>> 
>>>>>> Best,
>>>>>> Matt
>>>>>> 
>>>>>> Le lun. 7 janv. 2019 à 16:01, Greve, Douglas N.,Ph.D. 
>>>>>> mailto:dgr...@mgh.harvard.edu>> a écrit :
>>>>>> I'm not sure what you mean. If you are turning off PVC, why are you 
>>>>>> computing RBV and MGX? What is your command line? What do you mean that 
>>>>>> these options don't seem to work?
>>>>>> 
>>>>>> On 12/21/18 2:22 PM, Matthieu Vanhoutte wrote:
>>>>>>> External Email - Use Caution
>>>>>>> 
>>>>>>> Hi Douglas,
>>>>>>> 
>>>>>>> Thanks for helping.
>>>>>>> 
>>>>>>> To have an only rescaled voxel-wise PET image, these options seem to 
>>>>>>> work only when -rbv method is used and not -mgx.
>>>>>>> 
>>>>>>> Do you know why ?
>>>>>>> 
>>>>>>> Best,
>>>>>>> Matthieu 
>>>>>>> 
>>>>>>> 
>>>>>>> Le mar. 18 déc. 2018 à 17:58, Greve, Douglas N.,Ph.D. 
>>>>>>> mailto:dgr...@mgh.harvard.edu>> a écrit :
>>>>>>> You will need to set --psf 0 and --no-tfe to fully turn off PVC. 
>>>>>>> 
>>>>>>> On 12/18/18 4:50 AM, Matthieu Vanhoutte wrote:
>>>>>>>> External Email - Use Caution
>>>>>>&

Re: [Freesurfer] [PETSurfer] Intensity normalization of PET images without PVE correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,


> Le 25 janv. 2019 à 18:01, Greve, Douglas N.,Ph.D.  a 
> écrit :
> 
> 
> 
> On 1/25/19 7:57 AM, Matthieu Vanhoutte wrote:
>> External Email - Use Caution
>> 
>> Dear Douglas,
>> 
>> Could you precise me:
>> 1) Is the intensity rescaling of PET image included in the mri_gtmpvc 
>> command based on reference region in gtmseg.mgz file rather than aseg.mgz ?
> It depends. If you are using pons, then that is not part of the aseg and is 
> generated as part of the creation of gtmseg. But most of the rest of gtmseg 
> is derived from the aseg and surfaces.

Is it better to use gtmseg.mgz or aseg.mgz to extract reference region’s mean 
intensity ?


>> 2) Is this rescaling applied before PVE correction or after (i.e. based on 
>> PVE corrected reference region’s mean intensity) ?
> After
>> 
>> Many thanks in advance for helping.
>> 
>> Best,
>> Matthieu
>> 
>>> Le 7 janv. 2019 à 17:26, Greve, Douglas N.,Ph.D. >> <mailto:dgr...@mgh.harvard.edu>> a écrit :
>>> 
>>> 
>>> 
>>> On 1/7/19 11:18 AM, Matthieu Vanhoutte wrote:
>>>> External Email - Use Caution
>>>> 
>>>> 
>>>> I used the following command to obtain only rescaled voxel-wise PET image 
>>>> (with no PVC):
>>>> mri_gtmpvc --i PET.nii.gz --reg Pet2T1.register.dof6.lta --psf 0 --no-tfe 
>>>> --seg gtmseg.mgz --default-seg-merge --auto-mask PSF .01 --rbv --o  nopvc
>>>> 
>>>> If I omitted --rbv or --mgx option I didn't get the rescaled voxel-wise 
>>>> PET image (without PVC). Could I obtain the rescaled voxel-wise PET image 
>>>> (without PVC) just by dividing each voxel of the native PET image by the 
>>>> mean of the reference region ?
>>> Yes
>>>> 
>>>> Best,
>>>> Matt
>>>> 
>>>> Le lun. 7 janv. 2019 à 16:01, Greve, Douglas N.,Ph.D. 
>>>> mailto:dgr...@mgh.harvard.edu>> a écrit :
>>>> I'm not sure what you mean. If you are turning off PVC, why are you 
>>>> computing RBV and MGX? What is your command line? What do you mean that 
>>>> these options don't seem to work?
>>>> 
>>>> On 12/21/18 2:22 PM, Matthieu Vanhoutte wrote:
>>>>> External Email - Use Caution
>>>>> 
>>>>> Hi Douglas,
>>>>> 
>>>>> Thanks for helping.
>>>>> 
>>>>> To have an only rescaled voxel-wise PET image, these options seem to work 
>>>>> only when -rbv method is used and not -mgx.
>>>>> 
>>>>> Do you know why ?
>>>>> 
>>>>> Best,
>>>>> Matthieu 
>>>>> 
>>>>> 
>>>>> Le mar. 18 déc. 2018 à 17:58, Greve, Douglas N.,Ph.D. 
>>>>> mailto:dgr...@mgh.harvard.edu>> a écrit :
>>>>> You will need to set --psf 0 and --no-tfe to fully turn off PVC. 
>>>>> 
>>>>> On 12/18/18 4:50 AM, Matthieu Vanhoutte wrote:
>>>>>> External Email - Use Caution
>>>>>> 
>>>>>> Hi Douglas,
>>>>>> 
>>>>>> Could you help me on this point ?
>>>>>> 
>>>>>> Best,
>>>>>> Matthieu
>>>>>> 
>>>>>> 
>>>>>> Le mer. 12 déc. 2018 à 10:50, Matthieu Vanhoutte 
>>>>>> mailto:matthieuvanhou...@gmail.com>> a 
>>>>>> écrit :
>>>>>> Dear Douglas,
>>>>>> 
>>>>>> Is it possible to use mri_gtmpvc command in order to intensity normalize 
>>>>>> PET images without applying PVE correction by setting --psf to 0 ?
>>>>>> 
>>>>>> Best,
>>>>>> Matthieu
>>>>>> 
>>>>>> 
>>>>>> ___
>>>>>> Freesurfer mailing list
>>>>>> Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>
>>>>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 
>>>>>> <https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer>
>>>>> ___
>>>>> Freesurfer mailing list
>>>>> Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harv

Re: [Freesurfer] [PETSurfer] Intensity normalization of PET images without PVE correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

Please find comments inline below.

best,
Matthieu

> Le 25 janv. 2019 à 18:01, Greve, Douglas N.,Ph.D.  a 
> écrit :
> 
> 
> 
> On 1/25/19 7:57 AM, Matthieu Vanhoutte wrote:
>> External Email - Use Caution
>> 
>> Dear Douglas,
>> 
>> Could you precise me:
>> 1) Is the intensity rescaling of PET image included in the mri_gtmpvc 
>> command based on reference region in gtmseg.mgz file rather than aseg.mgz ?
> It depends. If you are using pons, then that is not part of the aseg and is 
> generated as part of the creation of gtmseg. But most of the rest of gtmseg 
> is derived from the aseg and surfaces.
>> 2) Is this rescaling applied before PVE correction or after (i.e. based on 
>> PVE corrected reference region’s mean intensity) ?
> After

Thank you for this clarification. But do you use mean PET signal inside the 
reference region after the PVE correction, since in the particular case of pons 
there is no PVE correction applied to white matter ?

Do you see any objection whether intensity normalization was done before PVE 
correction based on the mean PET signal inside the reference region ?

>> 
>> Many thanks in advance for helping.
>> 
>> Best,
>> Matthieu
>> 
>>> Le 7 janv. 2019 à 17:26, Greve, Douglas N.,Ph.D. >> <mailto:dgr...@mgh.harvard.edu>> a écrit :
>>> 
>>> 
>>> 
>>> On 1/7/19 11:18 AM, Matthieu Vanhoutte wrote:
>>>> External Email - Use Caution
>>>> 
>>>> 
>>>> I used the following command to obtain only rescaled voxel-wise PET image 
>>>> (with no PVC):
>>>> mri_gtmpvc --i PET.nii.gz --reg Pet2T1.register.dof6.lta --psf 0 --no-tfe 
>>>> --seg gtmseg.mgz --default-seg-merge --auto-mask PSF .01 --rbv --o  nopvc
>>>> 
>>>> If I omitted --rbv or --mgx option I didn't get the rescaled voxel-wise 
>>>> PET image (without PVC). Could I obtain the rescaled voxel-wise PET image 
>>>> (without PVC) just by dividing each voxel of the native PET image by the 
>>>> mean of the reference region ?
>>> Yes
>>>> 
>>>> Best,
>>>> Matt
>>>> 
>>>> Le lun. 7 janv. 2019 à 16:01, Greve, Douglas N.,Ph.D. 
>>>> mailto:dgr...@mgh.harvard.edu>> a écrit :
>>>> I'm not sure what you mean. If you are turning off PVC, why are you 
>>>> computing RBV and MGX? What is your command line? What do you mean that 
>>>> these options don't seem to work?
>>>> 
>>>> On 12/21/18 2:22 PM, Matthieu Vanhoutte wrote:
>>>>> External Email - Use Caution
>>>>> 
>>>>> Hi Douglas,
>>>>> 
>>>>> Thanks for helping.
>>>>> 
>>>>> To have an only rescaled voxel-wise PET image, these options seem to work 
>>>>> only when -rbv method is used and not -mgx.
>>>>> 
>>>>> Do you know why ?
>>>>> 
>>>>> Best,
>>>>> Matthieu 
>>>>> 
>>>>> 
>>>>> Le mar. 18 déc. 2018 à 17:58, Greve, Douglas N.,Ph.D. 
>>>>> mailto:dgr...@mgh.harvard.edu>> a écrit :
>>>>> You will need to set --psf 0 and --no-tfe to fully turn off PVC. 
>>>>> 
>>>>> On 12/18/18 4:50 AM, Matthieu Vanhoutte wrote:
>>>>>> External Email - Use Caution
>>>>>> 
>>>>>> Hi Douglas,
>>>>>> 
>>>>>> Could you help me on this point ?
>>>>>> 
>>>>>> Best,
>>>>>> Matthieu
>>>>>> 
>>>>>> 
>>>>>> Le mer. 12 déc. 2018 à 10:50, Matthieu Vanhoutte 
>>>>>> mailto:matthieuvanhou...@gmail.com>> a 
>>>>>> écrit :
>>>>>> Dear Douglas,
>>>>>> 
>>>>>> Is it possible to use mri_gtmpvc command in order to intensity normalize 
>>>>>> PET images without applying PVE correction by setting --psf to 0 ?
>>>>>> 
>>>>>> Best,
>>>>>> Matthieu
>>>>>> 
>>>>>> 
>>>>>> ___
>>>>>> Freesurfer mailing list
>>>>>> Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>
>>>>>> https://mail.nmr.mgh.harvard.edu/mailman

Re: [Freesurfer] [PETSurfer] Intensity normalization of PET images without PVE correction

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Douglas,

Could you precise me:
1) Is the intensity rescaling of PET image included in the mri_gtmpvc command 
based on reference region in gtmseg.mgz file rather than aseg.mgz ?
2) Is this rescaling applied before PVE correction or after (i.e. based on PVE 
corrected reference region’s mean intensity) ?

Many thanks in advance for helping.

Best,
Matthieu

> Le 7 janv. 2019 à 17:26, Greve, Douglas N.,Ph.D.  a 
> écrit :
> 
> 
> 
> On 1/7/19 11:18 AM, Matthieu Vanhoutte wrote:
>> External Email - Use Caution
>> 
>> 
>> I used the following command to obtain only rescaled voxel-wise PET image 
>> (with no PVC):
>> mri_gtmpvc --i PET.nii.gz --reg Pet2T1.register.dof6.lta --psf 0 --no-tfe 
>> --seg gtmseg.mgz --default-seg-merge --auto-mask PSF .01 --rbv --o  nopvc
>> 
>> If I omitted --rbv or --mgx option I didn't get the rescaled voxel-wise PET 
>> image (without PVC). Could I obtain the rescaled voxel-wise PET image 
>> (without PVC) just by dividing each voxel of the native PET image by the 
>> mean of the reference region ?
> Yes
>> 
>> Best,
>> Matt
>> 
>> Le lun. 7 janv. 2019 à 16:01, Greve, Douglas N.,Ph.D. 
>> mailto:dgr...@mgh.harvard.edu>> a écrit :
>> I'm not sure what you mean. If you are turning off PVC, why are you 
>> computing RBV and MGX? What is your command line? What do you mean that 
>> these options don't seem to work?
>> 
>> On 12/21/18 2:22 PM, Matthieu Vanhoutte wrote:
>>> External Email - Use Caution
>>> 
>>> Hi Douglas,
>>> 
>>> Thanks for helping.
>>> 
>>> To have an only rescaled voxel-wise PET image, these options seem to work 
>>> only when -rbv method is used and not -mgx.
>>> 
>>> Do you know why ?
>>> 
>>> Best,
>>> Matthieu 
>>> 
>>> 
>>> Le mar. 18 déc. 2018 à 17:58, Greve, Douglas N.,Ph.D. 
>>> mailto:dgr...@mgh.harvard.edu>> a écrit :
>>> You will need to set --psf 0 and --no-tfe to fully turn off PVC. 
>>> 
>>> On 12/18/18 4:50 AM, Matthieu Vanhoutte wrote:
>>>> External Email - Use Caution
>>>> 
>>>> Hi Douglas,
>>>> 
>>>> Could you help me on this point ?
>>>> 
>>>> Best,
>>>> Matthieu
>>>> 
>>>> 
>>>> Le mer. 12 déc. 2018 à 10:50, Matthieu Vanhoutte 
>>>> mailto:matthieuvanhou...@gmail.com>> a écrit 
>>>> :
>>>> Dear Douglas,
>>>> 
>>>> Is it possible to use mri_gtmpvc command in order to intensity normalize 
>>>> PET images without applying PVE correction by setting --psf to 0 ?
>>>> 
>>>> Best,
>>>> Matthieu
>>>> 
>>>> 
>>>> ___
>>>> Freesurfer mailing list
>>>> Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>
>>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 
>>>> <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 
>>> <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 
>>> <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 
>> <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 
>> <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 
> <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] [PETSurfer] Intensity normalization of PET images without PVE correction

[Matthieu Vanhoutte]

External Email - Use Caution

I used the following command to obtain only rescaled voxel-wise PET image
(with no PVC):
*mri_gtmpvc --i PET.nii.gz --reg Pet2T1.register.dof6.lta --psf 0 --no-tfe
--seg gtmseg.mgz --default-seg-merge --auto-mask PSF .01 --rbv --o  nopvc*

If I omitted *--rbv *or* --mgx* option I didn't get the rescaled voxel-wise
PET image (without PVC). Could I obtain the rescaled voxel-wise PET image
(without PVC) just by dividing each voxel of the native PET image by the
mean of the reference region ?

Best,
Matt

Le lun. 7 janv. 2019 à 16:01, Greve, Douglas N.,Ph.D. <
dgr...@mgh.harvard.edu> a écrit :

> I'm not sure what you mean. If you are turning off PVC, why are you
> computing RBV and MGX? What is your command line? What do you mean that
> these options don't seem to work?
>
> On 12/21/18 2:22 PM, Matthieu Vanhoutte wrote:
>
> External Email - Use Caution
> Hi Douglas,
>
> Thanks for helping.
>
> To have an only rescaled voxel-wise PET image, these options seem to work
> only when -rbv method is used and not -mgx.
>
> Do you know why ?
>
> Best,
> Matthieu
>
>
> Le mar. 18 déc. 2018 à 17:58, Greve, Douglas N.,Ph.D. <
> dgr...@mgh.harvard.edu> a écrit :
>
>> You will need to set --psf 0 and --no-tfe to fully turn off PVC.
>>
>> On 12/18/18 4:50 AM, Matthieu Vanhoutte wrote:
>>
>> External Email - Use Caution
>> Hi Douglas,
>>
>> Could you help me on this point ?
>>
>> Best,
>> Matthieu
>>
>>
>> Le mer. 12 déc. 2018 à 10:50, Matthieu Vanhoutte <
>> matthieuvanhou...@gmail.com> a écrit :
>>
>>> Dear Douglas,
>>>
>>> Is it possible to use mri_gtmpvc command in order to intensity normalize
>>> PET images without applying PVE correction by setting --psf to 0 ?
>>>
>>> Best,
>>> Matthieu
>>>
>>
>>
>> ___
>> 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 
> 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

Re: [Freesurfer] Robust PET signal projection

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

Could you answer to my previous request ?

Best,
Matt

> Le 21 déc. 2018 à 20:31, Matthieu Vanhoutte  a 
> écrit :
> 
> Thanks Douglas.
> 
> Is there a way to compute a weighted average in one command with fscalc ?
> 
> Best,
> Matthieu
> 
> 
> Le mar. 18 déc. 2018 à 18:03, Greve, Douglas N.,Ph.D.  <mailto:dgr...@mgh.harvard.edu>> a écrit :
> you can use mri_vol2surf to sample at different depths. If you want a simple 
> average across cortex, then you can use --projfrac-avg .35 .65 .05
> If you want to do more sophisticated weighting, then you will have to sample 
> at each layer and then combine the files (eg, fscalc). Unless you have very 
> small voxels, it probably will not make a difference. 
> 
> On 12/18/18 4:50 AM, Matthieu Vanhoutte wrote:
>> External Email - Use Caution
>> 
>> Dear experts,
>> 
>> Is there any advice on this point ?
>> 
>> Best,
>> Matthieu
>> 
>> 
>> Le mer. 12 déc. 2018 à 10:47, Matthieu Vanhoutte 
>> mailto:matthieuvanhou...@gmail.com>> a écrit :
>> Dear Freesurfer's experts,
>> 
>> In order to have a robust PET signal projection, is it possible compute the 
>> projected PET signal as a weighted average of the PET signal intersecting 
>> with the surfaces ranging from 35 to 65% of the cortical tickness with a 
>> step t=5% ?
>> 
>> More weight would be given to the surfaces located near the mid distance 
>> between the pial and white surfaces as they have a higher probability to be 
>> well located within the cortex (using a normal distribution for example).
>> 
>> Thank you for helping.
>> 
>> Best,
>> Matthieu
>> 
>> 
>> ___
>> Freesurfer mailing list
>> Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>
>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 
>> <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 
> <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] [PETSurfer] Intensity normalization of PET images without PVE correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

Could you answer to my previous request ?

Best,
Matt

> Le 21 déc. 2018 à 20:22, Matthieu Vanhoutte  a 
> écrit :
> 
> Hi Douglas,
> 
> Thanks for helping.
> 
> To have an only rescaled voxel-wise PET image, these options seem to work 
> only when -rbv method is used and not -mgx.
> 
> Do you know why ?
> 
> Best,
> Matthieu 
> 
> 
> Le mar. 18 déc. 2018 à 17:58, Greve, Douglas N.,Ph.D.  <mailto:dgr...@mgh.harvard.edu>> a écrit :
> You will need to set --psf 0 and --no-tfe to fully turn off PVC. 
> 
> On 12/18/18 4:50 AM, Matthieu Vanhoutte wrote:
>> External Email - Use Caution
>> 
>> Hi Douglas,
>> 
>> Could you help me on this point ?
>> 
>> Best,
>> Matthieu
>> 
>> 
>> Le mer. 12 déc. 2018 à 10:50, Matthieu Vanhoutte 
>> mailto:matthieuvanhou...@gmail.com>> a écrit :
>> Dear Douglas,
>> 
>> Is it possible to use mri_gtmpvc command in order to intensity normalize PET 
>> images without applying PVE correction by setting --psf to 0 ?
>> 
>> Best,
>> Matthieu
>> 
>> 
>> ___
>> Freesurfer mailing list
>> Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>
>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 
>> <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 
> <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] [PETsurfer] Use of MGX and RBV partial volume correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

Could you answer to my previous request ?

Best,
Matt

> Le 21 déc. 2018 à 20:29, Matthieu Vanhoutte  a 
> écrit :
> 
> Hi Douglas,
> 
> Thanks for these clarifications. I have however one misunderstanding.
> 
> When sampling PVC corrected PET image onto surface:
> - I use bbpet2anat.lta when MGX was used as specified un tutorial
> - I use rbv2anat.lta when RBV was used
> 
> But why not to use template.reg.lta computed by mri_coreg ? What are the 
> differences between those different files ?
> 
> Best,
> Matthieu
> 
> Le mar. 18 déc. 2018 à 18:13, Greve, Douglas N.,Ph.D.  <mailto:dgr...@mgh.harvard.edu>> a écrit :
> 
> 
> On 12/7/18 9:29 AM, Matthieu Vanhoutte wrote:
> >  External Email - Use Caution
> >
> > Hi Douglas,
> >
> > Thanks for these clarifications. I added some others questions inline below.
> >
> > Best,
> > Matthieu
> >
> >> Le 6 déc. 2018 à 17:25, Greve, Douglas N.,Ph.D.  >> <mailto:dgr...@mgh.harvard.edu>> a écrit :
> >>
> >>
> >>
> >> On 11/30/2018 07:15 AM, Matthieu Vanhoutte wrote:
> >>>  External Email - Use Caution
> >>>
> >>> Hi Douglas,
> >>>
> >>> Thank you for answering. Please find below new questions.
> >>> Bien cordialement,
> >>>
> >>>
> >>> Le ven. 30 nov. 2018 à 00:00, Greve, Douglas N.,Ph.D.
> >>> mailto:dgr...@mgh.harvard.edu> 
> >>> <mailto:dgr...@mgh.harvard.edu <mailto:dgr...@mgh.harvard.edu>>> a écrit :
> >>>
> >>> Hi Matthieu, sorry for the delay
> >>>
> >>> On 11/29/2018 12:50 PM, Matthieu Vanhoutte wrote:
> >>>>External Email - Use Caution
> >>>>
> >>>> Dear Freesurfer's experts,
> >>>>
> >>>> I tried to use PETSurfer to correct partial volume effect on my
> >>> FDG PET images, testing both Muller-Gartner and RBV corrections.
> >>>> I ran the commands specified in PETSurfer website and used the
> >>> two following commands for both MGX and RBV corrections respectively:
> >>>> mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51
> >>> --psf-row 5.51 --psf-slice 5.9 --seg gtmseg.mgz
> >>> --default-seg-merge --auto-mask PSF .01 --mgx .01 --o ./gtmpvc.output
> >>>> mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51
> >>> --psf-row 5.51 --psf-slice 5.9 --seg gtmseg.mgz
> >>> --default-seg-merge --auto-mask PSF .01 --rbv --o rbv.output.orig
> >>>> 1) However, I found that cortical output mgx.ctxgm.nii.gz of MGX
> >>> correction encompass more than just GM and values at the
> >>> boundaries of mgx.ctxgm.nii.gz seem to me very high or aberrant.
> >>> This is expected. The MG method gives you a value every place that
> >>> there
> >>> is GM signal *in the PET volume after partial volume effects*. So
> >>> basically, if you were to take the cortical ribbon and smooth it
> >>> by your
> >>> PSF, every non-zero voxel has some GM in it (which is why the
> >>> edges are
> >>> so high). When you run it with --mgx .01, it will exclude voxels that
> >>> have less than 1% GM after smoothing. If you you are disturbed by the
> >>> wide ribbon, just make the threshold higher. In theory, every point
> >>> along the surface normal gives you a valid answer, but the further
> >>> from
> >>> the center of the ribbon, the noisier it is going to be, so we
> >>> generally
> >>> only sample it at the center (--projfrac 0.5 to mri_vol2surf).
> >>>
> >>>
> >>> Basically, please find below the mgx.ctxgm with threshold set at 0.01:
> >>> image.png
> >>>
> >>> Then threshold set at 0.1:
> >>> image.png
> >>>
> >>> Values at some parts of the cortex (olfactory, visual) are not the
> >>> same between the two thresholds. In the first one in these parts of
> >>> the brain, values are higher than the second and seem kind of
> >>> aberrant. Is there no reason to prefer a threshold at 0.1 than 0.01 ?
> >>> For example, in (Douglas et al., 2016, NeuroImage) a threshold of 0.3
> >>> has been found to be optimal: how determine visually or quanti

Re: [Freesurfer] Which T1 volume to use for coregistration with PET volume

[Matthieu Vanhoutte]

External Email - Use Caution

Thank you Douglas for this clarification.

So, correction of inhomogeneities and intensity normalization would have no 
positive effect on the PET/MR coregistration ?

Best,
Matt

> Le 3 janv. 2019 à 20:04, Greve, Douglas N.,Ph.D.  a 
> écrit :
> 
> I doubt it would make much difference. If your PET has lots of 
> extracerebral uptake, then I might use something that has not been skull 
> stripped (eg, orig.mgz, T1.mgz, nu.mgz). If it does not  have much 
> extracerebral, then using brain.mgz is probably better.
> 
> On 12/31/18 10:53 AM, Bruce Fischl wrote:
>> HI Matt
>> 
>> yes, I would agree, but Doug will give you the definitive answer
>> 
>> cheers
>> Bruce
>> On Fri, 28 Dec 2018, Matthieu Vanhoutte wrote:
>> 
>>>External Email - Use Caution
>>> 
>>> Dear Freesurfer’s experts,
>>> 
>>> I used mri_coreg command to coregister PET image onto T1 volume. 
>>> Basically, this command coregister PET image onto orig.mgz volume 
>>> (default target). However, I wonder if T1.mgz wouldn’t be a better 
>>> target since it has been corrected for inhomogeneities and intensity 
>>> normalized ?
>>> 
>>> Thanks for helping !
>>> 
>>> Best,
>>> Matt
>>> 
>>> ___
>>> 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

[Freesurfer] Which T1 volume to use for coregistration with PET volume

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Freesurfer’s experts,

I used mri_coreg command to coregister PET image onto T1 volume. Basically, 
this command coregister PET image onto orig.mgz volume (default target). 
However, I wonder if T1.mgz wouldn’t be a better target since it has been 
corrected for inhomogeneities and intensity normalized ?

Thanks for helping !

Best,
Matt

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

Re: [Freesurfer] Robust PET signal projection

[Matthieu Vanhoutte]

External Email - Use Caution

Thanks Douglas.

Is there a way to compute a weighted average in one command with fscalc ?

Best,
Matthieu


Le mar. 18 déc. 2018 à 18:03, Greve, Douglas N.,Ph.D. <
dgr...@mgh.harvard.edu> a écrit :

> you can use mri_vol2surf to sample at different depths. If you want a
> simple average across cortex, then you can use --projfrac-avg .35 .65 .05
> If you want to do more sophisticated weighting, then you will have to
> sample at each layer and then combine the files (eg, fscalc). Unless you
> have very small voxels, it probably will not make a difference.
>
> On 12/18/18 4:50 AM, Matthieu Vanhoutte wrote:
>
> External Email - Use Caution
> Dear experts,
>
> Is there any advice on this point ?
>
> Best,
> Matthieu
>
>
> Le mer. 12 déc. 2018 à 10:47, Matthieu Vanhoutte <
> matthieuvanhou...@gmail.com> a écrit :
>
>> Dear Freesurfer's experts,
>>
>> In order to have a robust PET signal projection, is it possible compute
>> the projected PET signal as a weighted average of the PET signal
>> intersecting with the surfaces ranging from 35 to 65% of the cortical
>> tickness with a step t=5% ?
>>
>> More weight would be given to the surfaces located near the mid distance
>> between the pial and white surfaces as they have a higher probability to be
>> well located within the cortex (using a normal distribution for example).
>>
>> Thank you for helping.
>>
>> Best,
>> Matthieu
>>
>
>
> ___
> 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

Re: [Freesurfer] [PETsurfer] Use of MGX and RBV partial volume correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

Thanks for these clarifications. I have however one misunderstanding.

When sampling PVC corrected PET image onto surface:
- I use bbpet2anat.lta when MGX was used as specified un tutorial
- I use rbv2anat.lta when RBV was used

But why not to use template.reg.lta computed by mri_coreg ? What are the
differences between those different files ?

Best,
Matthieu

Le mar. 18 déc. 2018 à 18:13, Greve, Douglas N.,Ph.D. <
dgr...@mgh.harvard.edu> a écrit :

>
>
> On 12/7/18 9:29 AM, Matthieu Vanhoutte wrote:
> >  External Email - Use Caution
> >
> > Hi Douglas,
> >
> > Thanks for these clarifications. I added some others questions inline
> below.
> >
> > Best,
> > Matthieu
> >
> >> Le 6 déc. 2018 à 17:25, Greve, Douglas N.,Ph.D. 
> a écrit :
> >>
> >>
> >>
> >> On 11/30/2018 07:15 AM, Matthieu Vanhoutte wrote:
> >>>  External Email - Use Caution
> >>>
> >>> Hi Douglas,
> >>>
> >>> Thank you for answering. Please find below new questions.
> >>> Bien cordialement,
> >>>
> >>>
> >>> Le ven. 30 nov. 2018 à 00:00, Greve, Douglas N.,Ph.D.
> >>> mailto:dgr...@mgh.harvard.edu>> a écrit :
> >>>
> >>> Hi Matthieu, sorry for the delay
> >>>
> >>> On 11/29/2018 12:50 PM, Matthieu Vanhoutte wrote:
> >>>>External Email - Use Caution
> >>>>
> >>>> Dear Freesurfer's experts,
> >>>>
> >>>> I tried to use PETSurfer to correct partial volume effect on my
> >>> FDG PET images, testing both Muller-Gartner and RBV corrections.
> >>>> I ran the commands specified in PETSurfer website and used the
> >>> two following commands for both MGX and RBV corrections
> respectively:
> >>>> mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51
> >>> --psf-row 5.51 --psf-slice 5.9 --seg gtmseg.mgz
> >>> --default-seg-merge --auto-mask PSF .01 --mgx .01 --o
> ./gtmpvc.output
> >>>> mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51
> >>> --psf-row 5.51 --psf-slice 5.9 --seg gtmseg.mgz
> >>> --default-seg-merge --auto-mask PSF .01 --rbv --o rbv.output.orig
> >>>> 1) However, I found that cortical output mgx.ctxgm.nii.gz of MGX
> >>> correction encompass more than just GM and values at the
> >>> boundaries of mgx.ctxgm.nii.gz seem to me very high or aberrant.
> >>> This is expected. The MG method gives you a value every place that
> >>> there
> >>> is GM signal *in the PET volume after partial volume effects*. So
> >>> basically, if you were to take the cortical ribbon and smooth it
> >>> by your
> >>> PSF, every non-zero voxel has some GM in it (which is why the
> >>> edges are
> >>> so high). When you run it with --mgx .01, it will exclude voxels
> that
> >>> have less than 1% GM after smoothing. If you you are disturbed by
> the
> >>> wide ribbon, just make the threshold higher. In theory, every point
> >>> along the surface normal gives you a valid answer, but the further
> >>> from
> >>> the center of the ribbon, the noisier it is going to be, so we
> >>> generally
> >>> only sample it at the center (--projfrac 0.5 to mri_vol2surf).
> >>>
> >>>
> >>> Basically, please find below the mgx.ctxgm with threshold set at 0.01:
> >>> image.png
> >>>
> >>> Then threshold set at 0.1:
> >>> image.png
> >>>
> >>> Values at some parts of the cortex (olfactory, visual) are not the
> >>> same between the two thresholds. In the first one in these parts of
> >>> the brain, values are higher than the second and seem kind of
> >>> aberrant. Is there no reason to prefer a threshold at 0.1 than 0.01 ?
> >>> For example, in (Douglas et al., 2016, NeuroImage) a threshold of 0.3
> >>> has been found to be optimal: how determine visually or quantitatively
> >>> this optimal threshold ?
> >> So when you click on the same voxel in both images, you get different
> >> values? Or is it just that the color scale is changing? The threshold
> >> should not change the values, just what is in or out of the final mask.
> >> The threshold of 0.3 was ch

Re: [Freesurfer] [PETSurfer] Intensity normalization of PET images without PVE correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

Thanks for helping.

To have an only rescaled voxel-wise PET image, these options seem to work
only when -rbv method is used and not -mgx.

Do you know why ?

Best,
Matthieu


Le mar. 18 déc. 2018 à 17:58, Greve, Douglas N.,Ph.D. <
dgr...@mgh.harvard.edu> a écrit :

> You will need to set --psf 0 and --no-tfe to fully turn off PVC.
>
> On 12/18/18 4:50 AM, Matthieu Vanhoutte wrote:
>
> External Email - Use Caution
> Hi Douglas,
>
> Could you help me on this point ?
>
> Best,
> Matthieu
>
>
> Le mer. 12 déc. 2018 à 10:50, Matthieu Vanhoutte <
> matthieuvanhou...@gmail.com> a écrit :
>
>> Dear Douglas,
>>
>> Is it possible to use mri_gtmpvc command in order to intensity normalize
>> PET images without applying PVE correction by setting --psf to 0 ?
>>
>> Best,
>> Matthieu
>>
>
>
> ___
> 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

Re: [Freesurfer] [PETsurfer] Use of MGX and RBV partial volume correction

[Matthieu Vanhoutte]

External Email - Use Caution

>
> Hi Douglas,
>
> Could you help me about my previous mail with questions ?
>
> Thanks,
> Matthieu
>
>
> Le ven. 7 déc. 2018 à 14:31, Matthieu Vanhoutte <
> matthieuvanhou...@gmail.com> a écrit :
>
>> Hi Douglas,
>>
>> Thanks for these clarifications. I added some others questions inline
>> below.
>>
>> Best,
>> Matthieu
>>
>> > Le 6 déc. 2018 à 17:25, Greve, Douglas N.,Ph.D. 
>> a écrit :
>> >
>> >
>> >
>> > On 11/30/2018 07:15 AM, Matthieu Vanhoutte wrote:
>> >>
>> >> External Email - Use Caution
>> >>
>> >> Hi Douglas,
>> >>
>> >> Thank you for answering. Please find below new questions.
>> >> Bien cordialement,
>> >>
>> >>
>> >> Le ven. 30 nov. 2018 à 00:00, Greve, Douglas N.,Ph.D.
>> >> mailto:dgr...@mgh.harvard.edu>> a écrit :
>> >>
>> >>Hi Matthieu, sorry for the delay
>> >>
>> >>On 11/29/2018 12:50 PM, Matthieu Vanhoutte wrote:
>> >>>   External Email - Use Caution
>> >>>
>> >>> Dear Freesurfer's experts,
>> >>>
>> >>> I tried to use PETSurfer to correct partial volume effect on my
>> >>FDG PET images, testing both Muller-Gartner and RBV corrections.
>> >>>
>> >>> I ran the commands specified in PETSurfer website and used the
>> >>two following commands for both MGX and RBV corrections
>> respectively:
>> >>>
>> >>> mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51
>> >>--psf-row 5.51 --psf-slice 5.9 --seg gtmseg.mgz
>> >>--default-seg-merge --auto-mask PSF .01 --mgx .01 --o
>> ./gtmpvc.output
>> >>>
>> >>> mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51
>> >>--psf-row 5.51 --psf-slice 5.9 --seg gtmseg.mgz
>> >>--default-seg-merge --auto-mask PSF .01 --rbv --o rbv.output.orig
>> >>>
>> >>> 1) However, I found that cortical output mgx.ctxgm.nii.gz of MGX
>> >>correction encompass more than just GM and values at the
>> >>boundaries of mgx.ctxgm.nii.gz seem to me very high or aberrant.
>> >>This is expected. The MG method gives you a value every place that
>> >>there
>> >>is GM signal *in the PET volume after partial volume effects*. So
>> >>basically, if you were to take the cortical ribbon and smooth it
>> >>by your
>> >>PSF, every non-zero voxel has some GM in it (which is why the
>> >>edges are
>> >>so high). When you run it with --mgx .01, it will exclude voxels
>> that
>> >>have less than 1% GM after smoothing. If you you are disturbed by
>> the
>> >>wide ribbon, just make the threshold higher. In theory, every point
>> >>along the surface normal gives you a valid answer, but the further
>> >>from
>> >>the center of the ribbon, the noisier it is going to be, so we
>> >>generally
>> >>only sample it at the center (--projfrac 0.5 to mri_vol2surf).
>> >>
>> >>
>> >> Basically, please find below the mgx.ctxgm with threshold set at 0.01:
>> >> image.png
>> >>
>> >> Then threshold set at 0.1:
>> >> image.png
>> >>
>> >> Values at some parts of the cortex (olfactory, visual) are not the
>> >> same between the two thresholds. In the first one in these parts of
>> >> the brain, values are higher than the second and seem kind of
>> >> aberrant. Is there no reason to prefer a threshold at 0.1 than 0.01 ?
>> >> For example, in (Douglas et al., 2016, NeuroImage) a threshold of 0.3
>> >> has been found to be optimal: how determine visually or quantitatively
>> >> this optimal threshold ?
>> > So when you click on the same voxel in both images, you get different
>> > values? Or is it just that the color scale is changing? The threshold
>> > should not change the values, just what is in or out of the final mask.
>> > The threshold of 0.3 was chosen mainly because it worked for the ROI
>> > analysis. In general, you should use GTM instead of MG for ROI
>> analysis.
>> > For surface-based analysis, the threshold is not critical because the
>> GM
>> > PVF is gene

Re: [Freesurfer] Robust PET signal projection

[Matthieu Vanhoutte]

External Email - Use Caution

Dear experts,

Is there any advice on this point ?

Best,
Matthieu


Le mer. 12 déc. 2018 à 10:47, Matthieu Vanhoutte <
matthieuvanhou...@gmail.com> a écrit :

> Dear Freesurfer's experts,
>
> In order to have a robust PET signal projection, is it possible compute
> the projected PET signal as a weighted average of the PET signal
> intersecting with the surfaces ranging from 35 to 65% of the cortical
> tickness with a step t=5% ?
>
> More weight would be given to the surfaces located near the mid distance
> between the pial and white surfaces as they have a higher probability to be
> well located within the cortex (using a normal distribution for example).
>
> Thank you for helping.
>
> Best,
> Matthieu
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] [PETSurfer] Intensity normalization of PET images without PVE correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

Could you help me on this point ?

Best,
Matthieu


Le mer. 12 déc. 2018 à 10:50, Matthieu Vanhoutte <
matthieuvanhou...@gmail.com> a écrit :

> Dear Douglas,
>
> Is it possible to use mri_gtmpvc command in order to intensity normalize
> PET images without applying PVE correction by setting --psf to 0 ?
>
> Best,
> Matthieu
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] [PETSurfer] Intensity normalization of PET images without PVE correction

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Douglas,

Is it possible to use mri_gtmpvc command in order to intensity normalize
PET images without applying PVE correction by setting --psf to 0 ?

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

[Freesurfer] Robust PET signal projection

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Freesurfer's experts,

In order to have a robust PET signal projection, is it possible compute the
projected PET signal as a weighted average of the PET signal intersecting
with the surfaces ranging from 35 to 65% of the cortical tickness with a
step t=5% ?

More weight would be given to the surfaces located near the mid distance
between the pial and white surfaces as they have a higher probability to be
well located within the cortex (using a normal distribution for example).

Thank you for helping.

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

Re: [Freesurfer] [PETsurfer] Use of MGX and RBV partial volume correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

Could you help me about my previous mail with questions ?

Thanks,
Matthieu


Le ven. 7 déc. 2018 à 14:31, Matthieu Vanhoutte 
a écrit :

> Hi Douglas,
>
> Thanks for these clarifications. I added some others questions inline
> below.
>
> Best,
> Matthieu
>
> > Le 6 déc. 2018 à 17:25, Greve, Douglas N.,Ph.D. 
> a écrit :
> >
> >
> >
> > On 11/30/2018 07:15 AM, Matthieu Vanhoutte wrote:
> >>
> >> External Email - Use Caution
> >>
> >> Hi Douglas,
> >>
> >> Thank you for answering. Please find below new questions.
> >> Bien cordialement,
> >>
> >>
> >> Le ven. 30 nov. 2018 à 00:00, Greve, Douglas N.,Ph.D.
> >> mailto:dgr...@mgh.harvard.edu>> a écrit :
> >>
> >>Hi Matthieu, sorry for the delay
> >>
> >>On 11/29/2018 12:50 PM, Matthieu Vanhoutte wrote:
> >>>   External Email - Use Caution
> >>>
> >>> Dear Freesurfer's experts,
> >>>
> >>> I tried to use PETSurfer to correct partial volume effect on my
> >>FDG PET images, testing both Muller-Gartner and RBV corrections.
> >>>
> >>> I ran the commands specified in PETSurfer website and used the
> >>two following commands for both MGX and RBV corrections respectively:
> >>>
> >>> mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51
> >>--psf-row 5.51 --psf-slice 5.9 --seg gtmseg.mgz
> >>--default-seg-merge --auto-mask PSF .01 --mgx .01 --o ./gtmpvc.output
> >>>
> >>> mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51
> >>--psf-row 5.51 --psf-slice 5.9 --seg gtmseg.mgz
> >>--default-seg-merge --auto-mask PSF .01 --rbv --o rbv.output.orig
> >>>
> >>> 1) However, I found that cortical output mgx.ctxgm.nii.gz of MGX
> >>correction encompass more than just GM and values at the
> >>boundaries of mgx.ctxgm.nii.gz seem to me very high or aberrant.
> >>This is expected. The MG method gives you a value every place that
> >>there
> >>is GM signal *in the PET volume after partial volume effects*. So
> >>basically, if you were to take the cortical ribbon and smooth it
> >>by your
> >>PSF, every non-zero voxel has some GM in it (which is why the
> >>edges are
> >>so high). When you run it with --mgx .01, it will exclude voxels that
> >>have less than 1% GM after smoothing. If you you are disturbed by the
> >>wide ribbon, just make the threshold higher. In theory, every point
> >>along the surface normal gives you a valid answer, but the further
> >>from
> >>the center of the ribbon, the noisier it is going to be, so we
> >>generally
> >>only sample it at the center (--projfrac 0.5 to mri_vol2surf).
> >>
> >>
> >> Basically, please find below the mgx.ctxgm with threshold set at 0.01:
> >> image.png
> >>
> >> Then threshold set at 0.1:
> >> image.png
> >>
> >> Values at some parts of the cortex (olfactory, visual) are not the
> >> same between the two thresholds. In the first one in these parts of
> >> the brain, values are higher than the second and seem kind of
> >> aberrant. Is there no reason to prefer a threshold at 0.1 than 0.01 ?
> >> For example, in (Douglas et al., 2016, NeuroImage) a threshold of 0.3
> >> has been found to be optimal: how determine visually or quantitatively
> >> this optimal threshold ?
> > So when you click on the same voxel in both images, you get different
> > values? Or is it just that the color scale is changing? The threshold
> > should not change the values, just what is in or out of the final mask.
> > The threshold of 0.3 was chosen mainly because it worked for the ROI
> > analysis. In general, you should use GTM instead of MG for ROI analysis.
> > For surface-based analysis, the threshold is not critical because the GM
> > PVF is generally pretty high in cortex. It will make more of a
> > difference in subcortical analysis.
>
> Yes, thresholding at 0.01 and 0.1 gave me different values in the same
> voxel in both images. Whereas when thresholding between 0.1 and 0.3 gave me
> same values. What could it be due to ?
>
> GTM is always computed in the *.stat file whatever the method specified in
> mri_gtmpvc command ?
>
> If threshold is not critical for cortical surface,

Re: [Freesurfer] Longitudinal stream : LME and limits of model

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Martin,

I come back on my previous question concerning survival bias in LME.

Do you have an advice ?

Best,
Matthieu

> Le 19 oct. 2018 à 16:30, Matthieu Vanhoutte  a 
> écrit :
> 
> Hi Martin,
> 
> Do you mean that high attrition (less time points with time) would induce 
> more variance on the slope estimates but this effect would be compensated by 
> LME modeling ?
> 
> Would there be proportion of early drop outs to respect in order to 
> compensate bias with LME ?
> 
> Thanks,
> Matthieu
> 
> 
> Le ven. 19 oct. 2018 à 16:19, Martin Reuter  <mailto:mreu...@nmr.mgh.harvard.edu>> a écrit :
> Hi Matthieu, 
> 
> in LME it is OK if subjects have differently many time points in
> general. You need to ask a statistician about your specific setup, but
> I think it might be OK (basically less time points, means more variance
> on the slope estimates, but that should be considered in LME). But I am
> not a statistician. 
> 
> Best, Martin
> 
> 
> On Wed, 2018-10-17 at 18:46 +0200, Matthieu Vanhoutte wrote:
> > External Email - Use Caution
> > Hi Martin,
> > 
> > Thanks for your answer.
> > 
> > I actually compare neurospychological scores at baseline between
> > drop-out subjects and subjects with full time-points. If I ever find
> > that drop-out subjects are more severely affected than the subjects
> > with full time-points, then there might be a bias in the results of
> > my LME study ?
> > 
> > How could I argue that significant patterns found in my LME study
> > between both groups are still valid accounting for this bias ? Is LME
> > method robust enough for compensating this kind of drop-out ?
> > 
> > Best,
> > Matthieu
> > 
> > 
> > Le mer. 17 oct. 2018 à 18:33, Martin Reuter  > edu> a écrit :
> > > Hi Matthieu, 
> > > 
> > > 1) survival analysis is typically used if you want to detect if the
> > > time to an event is longer in one group vs the other (e.g. one
> > > group
> > > gets placebo the other drug and we want to know if recurrence is
> > > later
> > > in the drug group). Not sure this is what you need. The nice thing
> > > is,
> > > it can deal with drop-outs
> > > 
> > > 2) No, you can directly test that (e.g. do more dieseased drop out
> > > than
> > > healthy, or are the dropouts on average more advanced (test-scores,
> > > hippo-volume etc) than the diseased at baseline... many options.
> > > you
> > > could also test interactions with age , gender etc. However, not
> > > finding an interaction may not mean there is no bias, it is just
> > > small
> > > enough to go undetected with your data size. 
> > > 
> > > 3) Survival analysis is a different analysis than LME. 
> > > 
> > > Best, Martin
> > > 
> > > On Tue, 2018-10-16 at 16:15 +, Matthieu Vanhoutte wrote:
> > > > External Email - Use Caution
> > > > Hi Martin,
> > > > 
> > > > It's been a long time since this discussion but I return on this
> > > from
> > > > now... The problem is that I followed longitudinal images of two
> > > > groups where I had mainly missing time points at the end. Than
> > > you
> > > > suggested:
> > > > If you have mainly missing time points at the end, this will bias
> > > > your analysis to some extend, as the remaining ones may be
> > > extremely
> > > > healthy, as probably the more diseased ones drop out. You may
> > > want to
> > > > do a time-to-event (or survival-analysis) which considers early
> > > drop-
> > > > out.
> > > > 
> > > > 1) I know the survival analysis toolbox on matlab, but now I
> > > would
> > > > like to know what information will this survival analysis give to
> > > me
> > > > ? 
> > > > 2) Will this analysis tell me if there is a bias ?
> > > > 3) How to consider early drop-out with this type of analysis
> > > based on
> > > > mass-univariate LME analysis of longitudinal neuroimaging data ?
> > > > 
> > > > Thanks in advance for helping.
> > > > 
> > > > Best,
> > > > Matthieu
> > > > 
> > > > Le mer. 14 déc. 2016 à 22:14, Martin Reuter  > > ard.
> > > > edu> a écrit :
> > > > > Hi Matthieu,
> > > > >

Re: [Freesurfer] [PETsurfer] Use of MGX and RBV partial volume correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

Thanks for these clarifications. I added some others questions inline below.

Best,
Matthieu

> Le 6 déc. 2018 à 17:25, Greve, Douglas N.,Ph.D.  a 
> écrit :
> 
> 
> 
> On 11/30/2018 07:15 AM, Matthieu Vanhoutte wrote:
>> 
>>External Email - Use Caution
>> 
>> Hi Douglas,
>> 
>> Thank you for answering. Please find below new questions.
>> Bien cordialement,
>> 
>> 
>> Le ven. 30 nov. 2018 à 00:00, Greve, Douglas N.,Ph.D. 
>> mailto:dgr...@mgh.harvard.edu>> a écrit :
>> 
>>   Hi Matthieu, sorry for the delay
>> 
>>   On 11/29/2018 12:50 PM, Matthieu Vanhoutte wrote:
>>>  External Email - Use Caution
>>> 
>>> Dear Freesurfer's experts,
>>> 
>>> I tried to use PETSurfer to correct partial volume effect on my
>>   FDG PET images, testing both Muller-Gartner and RBV corrections.
>>> 
>>> I ran the commands specified in PETSurfer website and used the
>>   two following commands for both MGX and RBV corrections respectively:
>>> 
>>> mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51
>>   --psf-row 5.51 --psf-slice 5.9 --seg gtmseg.mgz
>>   --default-seg-merge --auto-mask PSF .01 --mgx .01 --o ./gtmpvc.output
>>> 
>>> mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51
>>   --psf-row 5.51 --psf-slice 5.9 --seg gtmseg.mgz
>>   --default-seg-merge --auto-mask PSF .01 --rbv --o rbv.output.orig
>>> 
>>> 1) However, I found that cortical output mgx.ctxgm.nii.gz of MGX
>>   correction encompass more than just GM and values at the
>>   boundaries of mgx.ctxgm.nii.gz seem to me very high or aberrant.
>>   This is expected. The MG method gives you a value every place that
>>   there
>>   is GM signal *in the PET volume after partial volume effects*. So
>>   basically, if you were to take the cortical ribbon and smooth it
>>   by your
>>   PSF, every non-zero voxel has some GM in it (which is why the
>>   edges are
>>   so high). When you run it with --mgx .01, it will exclude voxels that
>>   have less than 1% GM after smoothing. If you you are disturbed by the
>>   wide ribbon, just make the threshold higher. In theory, every point
>>   along the surface normal gives you a valid answer, but the further
>>   from
>>   the center of the ribbon, the noisier it is going to be, so we
>>   generally
>>   only sample it at the center (--projfrac 0.5 to mri_vol2surf).
>> 
>> 
>> Basically, please find below the mgx.ctxgm with threshold set at 0.01:
>> image.png
>> 
>> Then threshold set at 0.1:
>> image.png
>> 
>> Values at some parts of the cortex (olfactory, visual) are not the 
>> same between the two thresholds. In the first one in these parts of 
>> the brain, values are higher than the second and seem kind of 
>> aberrant. Is there no reason to prefer a threshold at 0.1 than 0.01 ? 
>> For example, in (Douglas et al., 2016, NeuroImage) a threshold of 0.3 
>> has been found to be optimal: how determine visually or quantitatively 
>> this optimal threshold ?
> So when you click on the same voxel in both images, you get different 
> values? Or is it just that the color scale is changing? The threshold 
> should not change the values, just what is in or out of the final mask. 
> The threshold of 0.3 was chosen mainly because it worked for the ROI 
> analysis. In general, you should use GTM instead of MG for ROI analysis. 
> For surface-based analysis, the threshold is not critical because the GM 
> PVF is generally pretty high in cortex. It will make more of a 
> difference in subcortical analysis.

Yes, thresholding at 0.01 and 0.1 gave me different values in the same voxel in 
both images. Whereas when thresholding between 0.1 and 0.3 gave me same values. 
What could it be due to ?

GTM is always computed in the *.stat file whatever the method specified in 
mri_gtmpvc command ?

If threshold is not critical for cortical surface, how to determine the best 
threshold for subcortical analysis ? Is it better to have more in the final 
mask ?

>> 
>> 
>>> 
>>> 2) Concerning RBV correction, output rbv.nii.gz seems to me
>>   following more precisely the GM ribbon. However contrary to what
>>   is said in PETSurfer website, rbv.nii.gz seems to be in the
>>   anatomical space (not in native PET) at the resolution of
>>   gtmseg.mgz. How then map rbv.nii.gz to the anatomical space when
>>   mapping the volume to the surface ?
>>   Where does it say this? It should be in the anatomical spac

Re: [Freesurfer] [PETsurfer] Use of MGX and RBV partial volume correction

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Douglas,

Thanks for these clarifications. I added some others questions inline below.

Best,
Matthieu

> Le 6 déc. 2018 à 17:25, Greve, Douglas N.,Ph.D.  a 
> écrit :
> 
> 
> 
> On 11/30/2018 07:15 AM, Matthieu Vanhoutte wrote:
>> 
>> External Email - Use Caution
>> 
>> Hi Douglas,
>> 
>> Thank you for answering. Please find below new questions.
>> Bien cordialement,
>> 
>> 
>> Le ven. 30 nov. 2018 à 00:00, Greve, Douglas N.,Ph.D. 
>> mailto:dgr...@mgh.harvard.edu>> a écrit :
>> 
>>Hi Matthieu, sorry for the delay
>> 
>>On 11/29/2018 12:50 PM, Matthieu Vanhoutte wrote:
>>>   External Email - Use Caution
>>> 
>>> Dear Freesurfer's experts,
>>> 
>>> I tried to use PETSurfer to correct partial volume effect on my
>>FDG PET images, testing both Muller-Gartner and RBV corrections.
>>> 
>>> I ran the commands specified in PETSurfer website and used the
>>two following commands for both MGX and RBV corrections respectively:
>>> 
>>> mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51
>>--psf-row 5.51 --psf-slice 5.9 --seg gtmseg.mgz
>>--default-seg-merge --auto-mask PSF .01 --mgx .01 --o ./gtmpvc.output
>>> 
>>> mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51
>>--psf-row 5.51 --psf-slice 5.9 --seg gtmseg.mgz
>>--default-seg-merge --auto-mask PSF .01 --rbv --o rbv.output.orig
>>> 
>>> 1) However, I found that cortical output mgx.ctxgm.nii.gz of MGX
>>correction encompass more than just GM and values at the
>>boundaries of mgx.ctxgm.nii.gz seem to me very high or aberrant.
>>This is expected. The MG method gives you a value every place that
>>there
>>is GM signal *in the PET volume after partial volume effects*. So
>>basically, if you were to take the cortical ribbon and smooth it
>>by your
>>PSF, every non-zero voxel has some GM in it (which is why the
>>edges are
>>so high). When you run it with --mgx .01, it will exclude voxels that
>>have less than 1% GM after smoothing. If you you are disturbed by the
>>wide ribbon, just make the threshold higher. In theory, every point
>>along the surface normal gives you a valid answer, but the further
>>from
>>the center of the ribbon, the noisier it is going to be, so we
>>generally
>>only sample it at the center (--projfrac 0.5 to mri_vol2surf).
>> 
>> 
>> Basically, please find below the mgx.ctxgm with threshold set at 0.01:
>> image.png
>> 
>> Then threshold set at 0.1:
>> image.png
>> 
>> Values at some parts of the cortex (olfactory, visual) are not the 
>> same between the two thresholds. In the first one in these parts of 
>> the brain, values are higher than the second and seem kind of 
>> aberrant. Is there no reason to prefer a threshold at 0.1 than 0.01 ? 
>> For example, in (Douglas et al., 2016, NeuroImage) a threshold of 0.3 
>> has been found to be optimal: how determine visually or quantitatively 
>> this optimal threshold ?
> So when you click on the same voxel in both images, you get different 
> values? Or is it just that the color scale is changing? The threshold 
> should not change the values, just what is in or out of the final mask. 
> The threshold of 0.3 was chosen mainly because it worked for the ROI 
> analysis. In general, you should use GTM instead of MG for ROI analysis. 
> For surface-based analysis, the threshold is not critical because the GM 
> PVF is generally pretty high in cortex. It will make more of a 
> difference in subcortical analysis.

Yes, thresholding at 0.01 and 0.1 gave me different values in the same voxel in 
both images. Whereas when thresholding between 0.1 and 0.3 gave me same values. 
What could it be due to ?

GTM is always computed in the *.stat file whatever the method specified in 
mri_gtmpvc command ?

If threshold is not critical for cortical surface, how to determine the best 
threshold for subcortical analysis ? Is it better to have more in the final 
mask ?

>> 
>> 
>>> 
>>> 2) Concerning RBV correction, output rbv.nii.gz seems to me
>>following more precisely the GM ribbon. However contrary to what
>>is said in PETSurfer website, rbv.nii.gz seems to be in the
>>anatomical space (not in native PET) at the resolution of
>>gtmseg.mgz. How then map rbv.nii.gz to the anatomical space when
>>mapping the volume to the surface ?
>>Where does it say th

[Freesurfer] [PETsurfer] Use of MGX and RBV partial volume correction

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Freesurfer's experts, 

I tried to use PETSurfer to correct partial volume effect on my FDG PET images, 
testing both Muller-Gartner and RBV corrections. 

I ran the commands specified in PETSurfer website and used the two following 
commands for both MGX and RBV corrections respectively: 

mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51 --psf-row 5.51 
--psf-slice 5.9 --seg gtmseg.mgz --default-seg-merge --auto-mask PSF .01 --mgx 
.01 --o ./gtmpvc.output 

mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51 --psf-row 5.51 
--psf-slice 5.9 --seg gtmseg.mgz --default-seg-merge --auto-mask PSF .01 --rbv 
--o rbv.output.orig 

1) However, I found that cortical output mgx.ctxgm.nii.gz of MGX correction 
encompass more than just GM and values at the boundaries of mgx.ctxgm.nii.gz 
seem to me very high or aberrant. 

2) Concerning RBV correction, output rbv.nii.gz seems to me following more 
precisely the GM ribbon. However contrary to what is said in PETSurfer website, 
rbv.nii.gz seems to be in the anatomical space (not in native PET) at the 
resolution of gtmseg.mgz. How then map rbv.nii.gz to the anatomical space when 
mapping the volume to the surface ? 

3) What are the advantages/inconveniences of RBV vs GMX ? 

4) Would it be beneficial to upsample native PET to the anatomical resolution 
before launching gtmpvc in order to preserve the high resolution of the 
anatomical tissues during partial volume correction ? 

Could you have a look at and give me back your opinion on these questions ? I 
could send the associated files if needed.

Thank you. 

Best, Matthieu

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

[Freesurfer] [PETSurfer] MGX and RBV Correction

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Freesurfer's experts, I tried to use PETSurfer to correct partial
volume effect on my FDG PET images, testing both Muller-Gartner and RBV
corrections. I ran the commands specified in PETSurfer website and used the
two following commands for both MGX and RBV corrections respectively:
mri_gtmpvc --i PET.nii.gz --reg register.dof6.lta --psf-col 5.51 --psf-row
5.51 --psf-slice 5.9 --seg gtmseg.mgz --default-seg-merge --auto-mask PSF
.01 --mgx .01 --o ./gtmpvc.output mri_gtmpvc --i PET.nii.gz --reg
register.dof6.lta --psf-col 5.51 --psf-row 5.51 --psf-slice 5.9 --seg
gtmseg.mgz --default-seg-merge --auto-mask PSF .01 --rbv --o
rbv.output.orig 1) However, I found that cortical output mgx.ctxgm.nii.gz
of MGX correction encompass more than just GM and values at the boundaries
of mgx.ctxgm.nii.gz seem to me very high or aberrant. 2) Concerning RBV
correction, output rbv.nii.gz seems to me following more precisely the GM
ribbon. However contrary to what is said in PETSurfer website, rbv.nii.gz
seems to be in the anatomical space (not in native PET) at the resolution
of gtmseg.mgz. How then map rbv.nii.gz to the anatomical space when mapping
the volume to the surface ? 3) What are the advantages/inconveniences of
RBV vs GMX ? 4) Would it be beneficial to upsample native PET to the
anatomical resolution before launching gtmpvc in order to preserve the high
resolution of the anatomical tissues during partial volume correction ?
Thank you. Best, Matthieu
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Longitudinal stream : LME and limits of model

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Martin,

Do you mean that high attrition (less time points with time) would induce
more variance on the slope estimates but this effect would be compensated
by LME modeling ?

Would there be proportion of early drop outs to respect in order to
compensate bias with LME ?

Thanks,
Matthieu


Le ven. 19 oct. 2018 à 16:19, Martin Reuter  a
écrit :

> Hi Matthieu,
>
> in LME it is OK if subjects have differently many time points in
> general. You need to ask a statistician about your specific setup, but
> I think it might be OK (basically less time points, means more variance
> on the slope estimates, but that should be considered in LME). But I am
> not a statistician.
>
> Best, Martin
>
>
> On Wed, 2018-10-17 at 18:46 +0200, Matthieu Vanhoutte wrote:
> > External Email - Use Caution
> > Hi Martin,
> >
> > Thanks for your answer.
> >
> > I actually compare neurospychological scores at baseline between
> > drop-out subjects and subjects with full time-points. If I ever find
> > that drop-out subjects are more severely affected than the subjects
> > with full time-points, then there might be a bias in the results of
> > my LME study ?
> >
> > How could I argue that significant patterns found in my LME study
> > between both groups are still valid accounting for this bias ? Is LME
> > method robust enough for compensating this kind of drop-out ?
> >
> > Best,
> > Matthieu
> >
> >
> > Le mer. 17 oct. 2018 à 18:33, Martin Reuter  > edu> a écrit :
> > > Hi Matthieu,
> > >
> > > 1) survival analysis is typically used if you want to detect if the
> > > time to an event is longer in one group vs the other (e.g. one
> > > group
> > > gets placebo the other drug and we want to know if recurrence is
> > > later
> > > in the drug group). Not sure this is what you need. The nice thing
> > > is,
> > > it can deal with drop-outs
> > >
> > > 2) No, you can directly test that (e.g. do more dieseased drop out
> > > than
> > > healthy, or are the dropouts on average more advanced (test-scores,
> > > hippo-volume etc) than the diseased at baseline... many options.
> > > you
> > > could also test interactions with age , gender etc. However, not
> > > finding an interaction may not mean there is no bias, it is just
> > > small
> > > enough to go undetected with your data size.
> > >
> > > 3) Survival analysis is a different analysis than LME.
> > >
> > > Best, Martin
> > >
> > > On Tue, 2018-10-16 at 16:15 +, Matthieu Vanhoutte wrote:
> > > > External Email - Use Caution
> > > > Hi Martin,
> > > >
> > > > It's been a long time since this discussion but I return on this
> > > from
> > > > now... The problem is that I followed longitudinal images of two
> > > > groups where I had mainly missing time points at the end. Than
> > > you
> > > > suggested:
> > > > If you have mainly missing time points at the end, this will bias
> > > > your analysis to some extend, as the remaining ones may be
> > > extremely
> > > > healthy, as probably the more diseased ones drop out. You may
> > > want to
> > > > do a time-to-event (or survival-analysis) which considers early
> > > drop-
> > > > out.
> > > >
> > > > 1) I know the survival analysis toolbox on matlab, but now I
> > > would
> > > > like to know what information will this survival analysis give to
> > > me
> > > > ?
> > > > 2) Will this analysis tell me if there is a bias ?
> > > > 3) How to consider early drop-out with this type of analysis
> > > based on
> > > > mass-univariate LME analysis of longitudinal neuroimaging data ?
> > > >
> > > > Thanks in advance for helping.
> > > >
> > > > Best,
> > > > Matthieu
> > > >
> > > > Le mer. 14 déc. 2016 à 22:14, Martin Reuter  > > ard.
> > > > edu> a écrit :
> > > > > Hi Matthieu,
> > > > >
> > > > > 1. yes, LME needs to be done first so that values can be
> > > sampled
> > > > > from the fitted model for the SA.
> > > > >
> > > > > 2. yes, I was talking about gradient non-linearities etc that
> > > could
> > > > > be in the image from the acquisition

Re: [Freesurfer] Longitudinal stream : LME and limits of model

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Martin,

Thanks for your answer.

I actually compare neurospychological scores at baseline between drop-out
subjects and subjects with full time-points. If I ever find that drop-out
subjects are more severely affected than the subjects with full
time-points, then there might be a bias in the results of my LME study ?

How could I argue that significant patterns found in my LME study between
both groups are still valid accounting for this bias ? Is LME method robust
enough for compensating this kind of drop-out ?

Best,
Matthieu


Le mer. 17 oct. 2018 à 18:33, Martin Reuter  a
écrit :

> Hi Matthieu,
>
> 1) survival analysis is typically used if you want to detect if the
> time to an event is longer in one group vs the other (e.g. one group
> gets placebo the other drug and we want to know if recurrence is later
> in the drug group). Not sure this is what you need. The nice thing is,
> it can deal with drop-outs
>
> 2) No, you can directly test that (e.g. do more dieseased drop out than
> healthy, or are the dropouts on average more advanced (test-scores,
> hippo-volume etc) than the diseased at baseline... many options. you
> could also test interactions with age , gender etc. However, not
> finding an interaction may not mean there is no bias, it is just small
> enough to go undetected with your data size.
>
> 3) Survival analysis is a different analysis than LME.
>
> Best, Martin
>
> On Tue, 2018-10-16 at 16:15 +, Matthieu Vanhoutte wrote:
> > External Email - Use Caution
> > Hi Martin,
> >
> > It's been a long time since this discussion but I return on this from
> > now... The problem is that I followed longitudinal images of two
> > groups where I had mainly missing time points at the end. Than you
> > suggested:
> > If you have mainly missing time points at the end, this will bias
> > your analysis to some extend, as the remaining ones may be extremely
> > healthy, as probably the more diseased ones drop out. You may want to
> > do a time-to-event (or survival-analysis) which considers early drop-
> > out.
> >
> > 1) I know the survival analysis toolbox on matlab, but now I would
> > like to know what information will this survival analysis give to me
> > ?
> > 2) Will this analysis tell me if there is a bias ?
> > 3) How to consider early drop-out with this type of analysis based on
> > mass-univariate LME analysis of longitudinal neuroimaging data ?
> >
> > Thanks in advance for helping.
> >
> > Best,
> > Matthieu
> >
> > Le mer. 14 déc. 2016 à 22:14, Martin Reuter  > edu> a écrit :
> > > Hi Matthieu,
> > >
> > > 1. yes, LME needs to be done first so that values can be sampled
> > > from the fitted model for the SA.
> > >
> > > 2. yes, I was talking about gradient non-linearities etc that could
> > > be in the image from the acquisition. We currently don’t use non-
> > > linear registration across time points (only rigid).
> > >
> > > Best, Martin
> > >
> > >
> > > > On Nov 22, 2016, at 9:31 PM, Matthieu Vanhoutte  > > > e...@gmail.com> wrote:
> > > >
> > > > Hi Martin,
> > > >
> > > > Please see inline below:
> > > >
> > > > > Le 22 nov. 2016 à 17:04, Martin Reuter  > > > > .edu> a écrit :
> > > > >
> > > > > Hi Matthieu,
> > > > > (also inline)
> > > > >
> > > > > > On Nov 21, 2016, at 10:28 PM, Matthieu Vanhoutte  > > > > > hou...@gmail.com> wrote:
> > > > > >
> > > > > > Hi Martin,
> > > > > >
> > > > > > Thanks for replying. Please see inline below:
> > > > > >
> > > > > > > Le 21 nov. 2016 à 20:26, Martin Reuter  > > > > > > vard.edu> a écrit :
> > > > > > >
> > > > > > > Hi Matthieu,
> > > > > > >
> > > > > > > a few quick answers. Maybe Jorge knows more.
> > > > > > > Generally number of subjects / time points etc. cannot be
> > > > > > > specified generally. All depends on how noisy your data is
> > > > > > > and how large the effect is that you expect to detect. You
> > > > > > > can do a power analysis in order to figure out how many
> > > > > > > subject / time points would be needed. There are some tools
> > > > > > > for that in the LME toolbox:
> >

Re: [Freesurfer] Longitudinal stream : LME and limits of model

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Martin,

It's been a long time since this discussion but I return on this from
now... The problem is that I followed longitudinal images of two groups
where I had mainly missing time points at the end. Than you suggested:
*If you have mainly missing time points at the end, this will bias your
analysis to some extend, as the remaining ones may be extremely healthy, as
probably the more diseased ones drop out. You may want to do a
time-to-event (or survival-analysis) which considers early drop-out.*

1) I know the survival analysis toolbox on matlab, but now I would like to
know what information will this survival analysis give to me ?
2) Will this analysis tell me if there is a bias ?
3) How to consider early drop-out with this type of analysis based on
mass-univariate LME analysis of longitudinal neuroimaging data ?

Thanks in advance for helping.

Best,
Matthieu

Le mer. 14 déc. 2016 à 22:14, Martin Reuter  a
écrit :

> Hi Matthieu,
>
> 1. yes, LME needs to be done first so that values can be sampled from the
> fitted model for the SA.
>
> 2. yes, I was talking about gradient non-linearities etc that could be in
> the image from the acquisition. We currently don’t use non-linear
> registration across time points (only rigid).
>
> Best, Martin
>
>
> On Nov 22, 2016, at 9:31 PM, Matthieu Vanhoutte <
> matthieuvanhou...@gmail.com> wrote:
>
> Hi Martin,
>
> Please see inline below:
>
> Le 22 nov. 2016 à 17:04, Martin Reuter  a
> écrit :
>
> Hi Matthieu,
> (also inline)
>
> On Nov 21, 2016, at 10:28 PM, Matthieu Vanhoutte <
> matthieuvanhou...@gmail.com> wrote:
>
> Hi Martin,
>
> Thanks for replying. Please see inline below:
>
> Le 21 nov. 2016 à 20:26, Martin Reuter  a
> écrit :
>
> Hi Matthieu,
>
> a few quick answers. Maybe Jorge knows more.
> Generally number of subjects / time points etc. cannot be specified
> generally. All depends on how noisy your data is and how large the effect
> is that you expect to detect. You can do a power analysis in order to
> figure out how many subject / time points would be needed. There are some
> tools for that in the LME toolbox:
>
> https://surfer.nmr.mgh.harvard.edu/fswiki/LinearMixedEffectsModels#Poweranalysis
>
>
> 1. see above
> 2. yes, also time points can miss from the middle. If you have mainly
> missing time points at the end, this will bias your analysis to some
> extend, as the remaining ones may be extremely healthy, as probably the
> more diseased ones drop out. You may want to do a time-to-event (or
> survival-analysis) which considers early drop-out.
>
>
> Is there any way to do with Freesurfer this kind of analysis ?
>
>
> https://surfer.nmr.mgh.harvard.edu/fswiki/SurvivalAnalysis
> Yes, there is also a paper where we do this. It is a combination of LME
> and Survival Analysis (as for the SA you need to have measurements of all
> subjects at all time points, so you estimate that from the LME model).
>
>
> Thank you for the link, I will take a look at. So if understand, this
> analysis has to be done after LME statistical analysis ? Thereafter since
> SA need all time points, LME model will allow me to estimate missing time
> points ?
>
>
>
> 3. see above (power analysis)
> 4. GIGO means garbage in, garbage out, so the less you QC, the more likely
> will your results be junk. The more you QC the less likely will it be junk,
> but could still be. The FS wiki has lots of tutorial information on
> checking freesurfer recons. For longitudinal, you should additionally check
> the surfaces in the base, the brain mask in the base, and the alignment of
> the time points (although there is some wiggle space for the alignment, as
> most things are allowed to evolve further for each time point).
>
>
> For the alignment of the time points, should I better comparing brainmask
> or norm.mgz ?
>
>
> It does not really matter, I would use norm.mgz. I would load images on
> top of each other and then use the opacity slider in Freeview to blend
> between them (that way the eye can pick up small motions). I would not
> worry too much about local deformations which could be caused by
> non-linearity (gradient). But if you see global misalignment (rotation,
> translation) it is a cause for concern) .
>
>
> Ok thank you. The non-linearity you are talking about are well provoked by
> MRI system and not non-linear registration between time points and template
> base, aren’t they ?
>
> Best regards,
> Matthieu
>
>
>
> In order to avoid bias by adding further time points in the model by the
> -add recon all command, is this better for each subject to take into
> account all the time points existing for it or o

Re: [Freesurfer] Troubles to determine the type of recon editing needed

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Bram,

According recon-all help "If a subject has enlarged ventricles due to
atrophy, include the -bigventricles
flag with the -autorecon2 stage in order to prevent surfaces extending into
the ventricle regions. The flag directly affects the binary
mri_ca_register, and mris_make_surfaces indirectly via aseg.presurf.mgz.

So doesn't this mean that we should only out the -bigventricles flag for
the -autorecon2 stage of recon-all ?

Best,
Matthieu

Le mer. 19 sept. 2018 à 15:17, Diamond, Bram Ryder <
brdiam...@mgh.harvard.edu> a écrit :

> Yes - if you've used the -bigventricles flag, you should always include it
> with the recon-all command.
>
>
> Bram
> --
> *From:* freesurfer-boun...@nmr.mgh.harvard.edu <
> freesurfer-boun...@nmr.mgh.harvard.edu> on behalf of Matthieu Vanhoutte <
> matthieuvanhou...@gmail.com>
> *Sent:* Tuesday, September 18, 2018 12:45:23 PM
> *To:* Freesurfer support list
> *Subject:* Re: [Freesurfer] Troubles to determine the type of recon
> editing needed
>
>
> External Email - Use Caution
>
> Ok I will test it on normal subjects.
>
> Do I have to put this -bigventricles flag on all recon-all commands
> following manual editing of brainmask, white matter,...etc or just once at
> the first recon-all -all command ?
>
> Best,
> Matthieu
>
> Le mar. 18 sept. 2018 à 18:03, Bruce Fischl 
> a écrit :
>
> I think it should be ok. It will be a bit slower, but shouldn't reduce
> accuracy I don't think. Try it and see
> Bruce
> On Tue, 18 Sep 2018, Matthieu
> Vanhoutte wrote:
>
> >
> > External Email - Use Caution
> >
> > Hi Bruce,
> >
> > Thanks, but in this case will recon-all with -bigventricles flag work
> well on normal patients
> > without big ventricles ?
> >
> > Best,
> > Matthieu
> >
> > 2018-09-18 15:56 GMT+00:00 Bruce Fischl :
> >   Hi Matthieu
> >
> >   yes, you will want to run all of your subjects with it
> >
> >   cheers
> >   Bruce
> >   On Tue, 18 Sep 2018, Matthieu Vanhoutte wrote:
> >
> >
> > External Email - Use Caution
> >
> > Dear Bram,
> >
> > It looks like the -bigventricles flag fixed my problem with
> my specific
> > subject. Not only, this took
> > into account large ventricles but also corrected grey matter
> segmentation
> > from extra Dura tissue
> > that was erroneously segmented in GM.
> >
> > I understand the first point of amelioration allowed by the
> flag but don't
> > understand where the
> > second point come from ?
> >
> > If I used the -bigventricles flag for all my atrophied and
> large ventricles
> > patients and not for my
> > healthy patients, wouldn't it introduce a bias when further
> statistically
> > comparing groups between
> > them ?
> >
> > Best,
> > Matthieu
> >
> > 2018-09-14 15:35 GMT+00:00 Diamond, Bram Ryder <
> brdiam...@mgh.harvard.edu>:
> >   If you haven't already, you may want to run the
> subject through
> > recon-all with the
> >   -bigventricles flag since it looks like the
> lateral ventricle was
> > significantly
> >   mislabeled in the aseg. If using the -bigventricles
> flag doesn't fix
> > your problem, you
> >   can edit the aseg.mgz manually by following the
> directions in this
> > tutorial. Then run
> >   the following command (again, substituting 
> for your
> > subject's id):
> > recon-all -autorecon2-noaseg -autorecon3 -subjid 
> >
> > I would try this before doing the wm.mgz edits I suggested
> in my previous
> > email.
> >
> > Best,
> > Bram
> >
> >
> ___
> > _
> > From: freesurfer-boun...@nmr.mgh.harvard.edu
> >  on
> > behalf of Diamond, Bram Ryder 
> > Sent: Friday, September 14, 2018 11:07:42 AM
> > To: matthieuvanhou...@gmail.com
> > Cc: freesurfer@nmr.mgh.harvard.edu;
> astev...@nmr.mgh.harvard.edu
> > 

Re: [Freesurfer] Troubles to determine the type of recon editing needed

[Matthieu Vanhoutte]

External Email - Use Caution

Ok I will test it on normal subjects.

Do I have to put this -bigventricles flag on all recon-all commands
following manual editing of brainmask, white matter,...etc or just once at
the first recon-all -all command ?

Best,
Matthieu

Le mar. 18 sept. 2018 à 18:03, Bruce Fischl  a
écrit :

> I think it should be ok. It will be a bit slower, but shouldn't reduce
> accuracy I don't think. Try it and see
> Bruce
> On Tue, 18 Sep 2018, Matthieu
> Vanhoutte wrote:
>
> >
> > External Email - Use Caution
> >
> > Hi Bruce,
> >
> > Thanks, but in this case will recon-all with -bigventricles flag work
> well on normal patients
> > without big ventricles ?
> >
> > Best,
> > Matthieu
> >
> > 2018-09-18 15:56 GMT+00:00 Bruce Fischl :
> >   Hi Matthieu
> >
> >   yes, you will want to run all of your subjects with it
> >
> >   cheers
> >   Bruce
> >   On Tue, 18 Sep 2018, Matthieu Vanhoutte wrote:
> >
> >
> > External Email - Use Caution
> >
> > Dear Bram,
> >
> > It looks like the -bigventricles flag fixed my problem with
> my specific
> > subject. Not only, this took
> > into account large ventricles but also corrected grey matter
> segmentation
> > from extra Dura tissue
> > that was erroneously segmented in GM.
> >
> > I understand the first point of amelioration allowed by the
> flag but don't
> > understand where the
> > second point come from ?
> >
> > If I used the -bigventricles flag for all my atrophied and
> large ventricles
> > patients and not for my
> > healthy patients, wouldn't it introduce a bias when further
> statistically
> > comparing groups between
> > them ?
> >
> > Best,
> > Matthieu
> >
> > 2018-09-14 15:35 GMT+00:00 Diamond, Bram Ryder <
> brdiam...@mgh.harvard.edu>:
> >   If you haven't already, you may want to run the
> subject through
> > recon-all with the
> >   -bigventricles flag since it looks like the
> lateral ventricle was
> > significantly
> >   mislabeled in the aseg. If using the -bigventricles
> flag doesn't fix
> > your problem, you
> >   can edit the aseg.mgz manually by following the
> directions in this
> > tutorial. Then run
> >   the following command (again, substituting 
> for your
> > subject's id):
> > recon-all -autorecon2-noaseg -autorecon3 -subjid 
> >
> > I would try this before doing the wm.mgz edits I suggested
> in my previous
> > email.
> >
> > Best,
> > Bram
> >
> >
> ___
> > _
> > From: freesurfer-boun...@nmr.mgh.harvard.edu
> >  on
> > behalf of Diamond, Bram Ryder 
> > Sent: Friday, September 14, 2018 11:07:42 AM
> > To: matthieuvanhou...@gmail.com
> > Cc: freesurfer@nmr.mgh.harvard.edu;
> astev...@nmr.mgh.harvard.edu
> > Subject: [Freesurfer] Troubles to determine the type of
> recon editing needed
> >
> >
> > Hi Matthieu,
> >
> >
> > I've taken a look through the files you shared with us and I
> see the poor
> > surfaces in the
> > posterior right hemisphere you were referring to in your
> message. It looks
> > like your subject
> > has a combination of abnormally large ventricles and
> significant wm
> > abnormalities, so I'm
> > surprised FreeSurfer did as well as it did.
> >
> >
> > As for the recon editing - I would recommend editing the
> wm.mgz to more
> > accurately represent
> > the wm from slice 84 to 39. You can take a look at the white
> matter edits
> > tutorial for details
> > on how to do that. Then run the following command
> (substituting 
> > for your
> > subject's id):
> >
> >
> > recon-all -autorecon2-wm -autorecon3 

Re: [Freesurfer] Troubles to determine the type of recon editing needed

[Matthieu Vanhoutte]

External Email - Use Caution

Hi Bruce,

Thanks, but in this case will recon-all with -bigventricles flag work well
on normal patients without big ventricles ?

Best,
Matthieu

2018-09-18 15:56 GMT+00:00 Bruce Fischl :

> Hi Matthieu
>
> yes, you will want to run all of your subjects with it
>
> cheers
> Bruce
> On Tue, 18 Sep 2018, Matthieu Vanhoutte wrote:
>
>
>> External Email - Use Caution
>>
>> Dear Bram,
>>
>> It looks like the -bigventricles flag fixed my problem with my specific
>> subject. Not only, this took
>> into account large ventricles but also corrected grey matter segmentation
>> from extra Dura tissue
>> that was erroneously segmented in GM.
>>
>> I understand the first point of amelioration allowed by the flag but
>> don't understand where the
>> second point come from ?
>>
>> If I used the -bigventricles flag for all my atrophied and large
>> ventricles patients and not for my
>> healthy patients, wouldn't it introduce a bias when further statistically
>> comparing groups between
>> them ?
>>
>> Best,
>> Matthieu
>>
>> 2018-09-14 15:35 GMT+00:00 Diamond, Bram Ryder > >:
>>   If you haven't already, you may want to run the subject through
>> recon-all with the
>>   -bigventricles flag since it looks like the lateral ventricle was
>> significantly
>>   mislabeled in the aseg. If using the -bigventricles flag doesn't
>> fix your problem, you
>>   can edit the aseg.mgz manually by following the directions in this
>> tutorial. Then run
>>   the following command (again, substituting  for your
>> subject's id):
>> recon-all -autorecon2-noaseg -autorecon3 -subjid 
>>
>> I would try this before doing the wm.mgz edits I suggested in my previous
>> email.
>>
>> Best,
>> Bram
>>
>> 
>> 
>>
>> From: freesurfer-boun...@nmr.mgh.harvard.edu <
>> freesurfer-boun...@nmr.mgh.harvard.edu> on
>> behalf of Diamond, Bram Ryder 
>> Sent: Friday, September 14, 2018 11:07:42 AM
>> To: matthieuvanhou...@gmail.com
>> Cc: freesurfer@nmr.mgh.harvard.edu; astev...@nmr.mgh.harvard.edu
>> Subject: [Freesurfer] Troubles to determine the type of recon editing
>> needed
>>
>> Hi Matthieu,
>>
>>
>> I've taken a look through the files you shared with us and I see the poor
>> surfaces in the
>> posterior right hemisphere you were referring to in your message. It
>> looks like your subject
>> has a combination of abnormally large ventricles and significant wm
>> abnormalities, so I'm
>> surprised FreeSurfer did as well as it did.
>>
>>
>> As for the recon editing - I would recommend editing the wm.mgz to more
>> accurately represent
>> the wm from slice 84 to 39. You can take a look at the white matter edits
>> tutorial for details
>> on how to do that. Then run the following command (substituting 
>> for your
>> subject's id):
>>
>>
>> recon-all -autorecon2-wm -autorecon3 -subjid 
>>
>>
>> The surface reconstruction may also benefit from labeling the right
>> lateral ventricle in the
>> wm.mgz (as an intensity of 250) - but I'm not certain since you didn't
>> send us the surfaces
>> for the left hemisphere. Before you do that, edit the wm.mgz as explained
>> in the tutorial and
>> tell us how that goes.
>>
>>
>> All the best,
>>
>> Bram
>>
>>
>> Bram R. Diamond, BSc
>> Research Technician II
>> Laboratory for Computational Neuroimaging
>> Martinos Center for Biomedical Imaging
>> Massachusetts General Hospital
>> 149 13th Street
>> Charlestown, MA 02129
>> (p): 617-726-6598
>>
>> The information in this e-mail is intended only for the person to whom it
>> is
>> addressed. If you believe this e-mail was sent to you in error and the
>> e-mail
>> contains patient information, please contact the Partners Compliance
>> HelpLine at
>> http://www.partners.org/complianceline . If the e-mail was sent to you
>> in error
>> but does not contain patient information, please contact the sender and
>> properly
>> dispose of the e-mail.
>>
>>
>>
>>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
> The information in this e

Re: [Freesurfer] Troubles to determine the type of recon editing needed

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Bram,

It looks like the -bigventricles flag fixed my problem with my specific
subject. Not only, this took into account large ventricles but also
corrected grey matter segmentation from extra Dura tissue that was
erroneously segmented in GM.

I understand the first point of amelioration allowed by the flag but don't
understand where the second point come from ?

If I used the -bigventricles flag for all my atrophied and large ventricles
patients and not for my healthy patients, wouldn't it introduce a bias when
further statistically comparing groups between them ?

Best,
Matthieu

2018-09-14 15:35 GMT+00:00 Diamond, Bram Ryder :

> If you haven't already, you may want to run the subject through recon-all
> with the -bigventricles flag since it looks like the lateral ventricle was
> significantly mislabeled in the aseg. If using the -bigventricles flag
> doesn't fix your problem, you can edit the aseg.mgz manually by following
> the directions in this tutorial
> .
> Then run the following command (again, substituting  for your
> subject's id):
>
> recon-all -autorecon2-noaseg -autorecon3 -subjid 
>
> I would try this before doing the wm.mgz edits I suggested in my previous
> email.
>
> Best,
> Bram
> --
> *From:* freesurfer-boun...@nmr.mgh.harvard.edu <
> freesurfer-boun...@nmr.mgh.harvard.edu> on behalf of Diamond, Bram Ryder <
> brdiam...@mgh.harvard.edu>
> *Sent:* Friday, September 14, 2018 11:07:42 AM
> *To:* matthieuvanhou...@gmail.com
> *Cc:* freesurfer@nmr.mgh.harvard.edu; astev...@nmr.mgh.harvard.edu
> *Subject:* [Freesurfer] Troubles to determine the type of recon editing
> needed
>
>
> Hi Matthieu,
>
>
> I've taken a look through the files you shared with us and I see the poor
> surfaces in the posterior right hemisphere you were referring to in your
> message. It looks like your subject has a combination of abnormally large
> ventricles and significant wm abnormalities, so I'm surprised FreeSurfer
> did as well as it did.
>
>
> As for the recon editing - I would recommend editing the wm.mgz to more
> accurately represent the wm from slice 84 to 39. You can take a look at the 
> white
> matter edits tutorial
> 
> for details on how to do that. Then run the following command (substituting
>  for your subject's id):
>
>
> recon-all -autorecon2-wm -autorecon3 -subjid 
>
>
> The surface reconstruction may also benefit from labeling the right
> lateral ventricle in the wm.mgz (as an intensity of 250) - but I'm not
> certain since you didn't send us the surfaces for the left hemisphere.
> Before you do that, edit the wm.mgz as explained in the tutorial and tell
> us how that goes.
>
>
> All the best,
>
> Bram
>
>
> *Bram R. Diamond, BSc*
> Research Technician II
> Laboratory for Computational Neuroimaging
> Martinos Center for Biomedical Imaging
> Massachusetts General Hospital
> 149 13th Street
> 
>
> Charlestown, MA 02129
> 
> (p): 617-726-6598
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

Re: [Freesurfer] Troubles to determine the type of recon editing needed

[Matthieu Vanhoutte]

External Email - Use Caution

Dear Bram,

Thank you for your answer. As soon as possible I will run recon-all with
the -bigventricles flag.

Concerning the manual editing I don't understand well the aim of editing
aseg.mgz since it seems to most concern subcortical structures and
statistics and not have an impact on surfaces computed ?

Best,
Matthieu

Le ven. 14 sept. 2018 à 17:35, Diamond, Bram Ryder <
brdiam...@mgh.harvard.edu> a écrit :

> If you haven't already, you may want to run the subject through recon-all
> with the -bigventricles flag since it looks like the lateral ventricle was
> significantly mislabeled in the aseg. If using the -bigventricles flag
> doesn't fix your problem, you can edit the aseg.mgz manually by following
> the directions in this tutorial
> .
> Then run the following command (again, substituting  for your
> subject's id):
>
> recon-all -autorecon2-noaseg -autorecon3 -subjid 
>
> I would try this before doing the wm.mgz edits I suggested in my previous
> email.
>
> Best,
> Bram
> --
> *From:* freesurfer-boun...@nmr.mgh.harvard.edu <
> freesurfer-boun...@nmr.mgh.harvard.edu> on behalf of Diamond, Bram Ryder <
> brdiam...@mgh.harvard.edu>
> *Sent:* Friday, September 14, 2018 11:07:42 AM
> *To:* matthieuvanhou...@gmail.com
> *Cc:* freesurfer@nmr.mgh.harvard.edu; astev...@nmr.mgh.harvard.edu
> *Subject:* [Freesurfer] Troubles to determine the type of recon editing
> needed
>
>
> Hi Matthieu,
>
>
> I've taken a look through the files you shared with us and I see the poor
> surfaces in the posterior right hemisphere you were referring to in your
> message. It looks like your subject has a combination of abnormally large
> ventricles and significant wm abnormalities, so I'm surprised FreeSurfer
> did as well as it did.
>
>
> As for the recon editing - I would recommend editing the wm.mgz to more
> accurately represent the wm from slice 84 to 39. You can take a look at the 
> white
> matter edits tutorial
> 
> for details on how to do that. Then run the following command (substituting
>  for your subject's id):
>
>
> recon-all -autorecon2-wm -autorecon3 -subjid 
>
>
> The surface reconstruction may also benefit from labeling the right
> lateral ventricle in the wm.mgz (as an intensity of 250) - but I'm not
> certain since you didn't send us the surfaces for the left hemisphere.
> Before you do that, edit the wm.mgz as explained in the tutorial and tell
> us how that goes.
>
>
> All the best,
>
> Bram
>
>
> *Bram R. Diamond, BSc*
> Research Technician II
> Laboratory for Computational Neuroimaging
> Martinos Center for Biomedical Imaging
> Massachusetts General Hospital
> 149 13th Street
> Charlestown, MA 02129
> (p): 617-726-6598
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

[Freesurfer] Compare longitudinal evolution of two vertex-wise data

[Matthieu Vanhoutte]

Dear experts,

Do you know if there would be a mean to compare longitudinal evolution of
two vertex-wise data (i.e. kind of longitudinal correlation) with LME tools
or others ?

Best regards,
Matthieu
___
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] Effect of continuous time-varying covariate across time in LME models

[Matthieu Vanhoutte]

Dear Freesurfer's experts,

Would anybody have advice concerning my requests in below mail ?

Thanks in advance.

Best regards,
Matthieu

2017-07-01 11:37 GMT+00:00 Matthieu Vanhoutte <matthieuvanhou...@gmail.com>:

> Dear Freesurfer’s experts,
>
> I would like to test if neuropsychological score across time (continuous
> time-varying covariate) has an effect on metabolism maps. However, I don’t
> manage to understand how to define design matrix and contrast associated to
> assess it with LME models.
>
> I picked up from one former mailing list discussion including Jorge:
>
> *we recommended to order the columns of the design matrix in the following 
> way:
>
> Column 1: the intercept term (which is a column of ones)
>
> Colum 2: the time covariate if it varies across subjects (eg. time from
> baseline)
>
> Column 3-q: any time-varying covariates (eg. training: 0 before training, 1
> after training)
>
> Column q+1-r: the group covariates of interest (eg. a binary variable
> indicating whether or not the subject is a patient), for n groups you will 
> have
> n-1 binary covariates
>
> Column r+1-s: interactions between group covariates with the time-varying
> covariates (only the interesting interactions)
>
> Column s+1-p: any other nuisance time-invariant covariates (eg.
> age-at-baseline, gender, etc...)*
>
>
> 1) If I apply these advices, I would define in Column 3 my
> neuropsychological scores as my time-varying covariate but should I have to
> normalize these scores ?
>
> 2) If I want to correlate my metabolic maps (inputs) with my
> neuropsychological time-varying covariate should I have to define a column
> of interaction between neuropsychological time-varying covariate and (group
> or time) ?
>
> 3) How should I define contrast matrix to assess this effect ?
>
> Thank you for your advices !!
>
> Best regards,
> Matthieu
>
>
>
___
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] Effect of continuous time-varying covariate across time in LME models

[Matthieu Vanhoutte]

Dear Freesurfer’s experts,

I would like to test if neuropsychological score across time (continuous 
time-varying covariate) has an effect on metabolism maps. However, I don’t 
manage to understand how to define design matrix and contrast associated to 
assess it with LME models.

I picked up from one former mailing list discussion including Jorge:
we recommended to order the columns of the design matrix in the following way:

Column 1: the intercept term (which is a column of ones)

Colum 2: the time covariate if it varies across subjects (eg. time from 
baseline)

Column 3-q: any time-varying covariates (eg. training: 0 before training, 1 
after training)

Column q+1-r: the group covariates of interest (eg. a binary variable 
indicating whether or not the subject is a patient), for n groups you will have 
n-1 binary covariates

Column r+1-s: interactions between group covariates with the time-varying 
covariates (only the interesting interactions)

Column s+1-p: any other nuisance time-invariant covariates (eg. 
age-at-baseline, gender, etc...)

1) If I apply these advices, I would define in Column 3 my neuropsychological 
scores as my time-varying covariate but should I have to normalize these scores 
?

2) If I want to correlate my metabolic maps (inputs) with my neuropsychological 
time-varying covariate should I have to define a column of interaction between 
neuropsychological time-varying covariate and (group or time) ?

3) How should I define contrast matrix to assess this effect ?

Thank you for your advices !!

Best regards,
Matthieu


___
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] Surface area of a define volume projection on cortical surface

[Matthieu Vanhoutte]

Dear Freesurfer's experts,

Given the well known size of a voxel I would like to know the equivalent
surface area once projected on the white fsaverage cortical surface.

Could anyone give me a proper way of computing this ?

Best regards,
Matthieu
___
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] LME : longitudinal correlations between imaging and cognition scores

[Matthieu Vanhoutte]

Hi Martin,

Thank you this helps !

Please find last question below inline.

Best,
Matthieu

Le 18 mai 2017 10:33 AM, "Martin Reuter" <mreu...@nmr.mgh.harvard.edu> a
écrit :

Hi Matthieu,


1) you would put a column of score and a column of score X time.  The first
allows you to test if the intercept changes based on scores (e.g. if
hippocampal volume is affected by the score, controlling for whatever else
you included, e.g. age and gender etc) and the second interaction allows
you to test if the the slopes are affected by score (so if atrophy rates
are different at different score levels).

2) if your effect for that interaction column is positive, there is a
positive correlation (higher score, slower atrophy (or even brain growth),
and lower score with faster atrophy - this is what you would expect) if
there is a negative effect, it would mean the opposite.

How do you deduce this from combination of atrophy, score and time ?
I know that positive leads to positive correlation and when group X time is
negative means that cortical thickness decreases with time.
However I can't manage to understand relation between cortical thickness
and score X time. Could you explain me ?

Best, Martin


On 05/17/2017 11:12 PM, Matthieu Vanhoutte wrote:

Hi Martin,

I will read up on interpretation of time varying covariates.

If initially I use score as variable fixed across time, and define a
variable for 'score x time' interaction:
1) Would putting only 1 to 'score x time' column (for contrast) test for
progression of correlation patterns between atrophy and score ?
2) How to interpret this according to sign  of contrast (knowing that
decrease in score means worse performance) ?

Many thanks for your time and lights !

Best,
Matthieu

Le 17 mai 2017 1:46 PM, "Martin Reuter" <mreu...@nmr.mgh.harvard.edu> a
écrit :

Hi Matthieu,

replacing time by score is very different from adding score as a covariate.
Often scores are crude and often they are constant in controls (always full
score), and only vary slightly in diseased. In those cases it may not be
good to use score as a time variable.

I would either add avg. score as a variable (fixed across time - would
probably do this for intial testing anyway) or score as time-varying
covariate, but would read up on how to interpret results in the presence of
time-varying-covariates. I am not a statistician.
Best, Martin


On 05/16/2017 08:09 PM, Matthieu Vanhoutte wrote:

Hi Martin,

Thank you for this detailed answer.

Are replacing time by score or include score as time-varying covariate
leading to the same result because of looking at the same effect ?

My willing would be to find patterns of atrophy rate/progression correlated
with cognitive score. In context of AD which method would be the best for
you ?

Best,
Matthieu


Le 16 mai 2017 11:17 AM, "Martin Reuter" <mreu...@nmr.mgh.harvard.edu> a
écrit :

Hi Matthieu,

one option is to replace time with score in the model. That should be
straight forward.

The other option is to include score as a time-varying covariate. If your
score is not varying much across time and you are more interested if the
average score (or baseline score) affects atrophy rates, you can also
include is as a standard (fixed across time) co-variate (such as baseline
age) with a time (and a group  etc) interaction.

Sorry, but I cannot do your design. Ultimately the model is the research
question that you are asking and it is important that this is done
correctly. Maybe there is a local biostats person that you can talk to?

Best, Martin



On 05/15/2017 08:20 PM, Matthieu Vanhoutte wrote:

Hi Martin,

Thank you. How should this variable be coded ? Should it be as age
covariate where age at baseline is used along all time points of each
subject ?

Could you provide me an example of design matrix, I don't manage to see
what does it look like to.

Best regards,
Matthieu


Le 14 mai 2017 8:08 PM, "Martin Reuter" <mreu...@nmr.mgh.harvard.edu> a
écrit :

Hi Matthieu,

yes, that is possible. Instead of group, you use a variable for your score
(and interaction etc). Sometimes it may also makes sense to use score
instead of time.

Best, Martin


> On 12 May 2017, at 10:51, Matthieu Vanhoutte <matthieuvanhou...@gmail.com>
wrote:
>
> Dear Freesurfer's experts,
>
> I have searched through the mailing list but haven't found any answer to
my question.
>
> Is it possible with LME model to make correlations between for example
cortical thickness surface data and cognition scores along time ? As it is
possible to test for interaction of group X time, is this also in the same
way feasible to test for coognition score X time on cortical thickness ?
>
> Many thanks for your advice !
>
> Best regards,
> Matthieu
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvar

Re: [Freesurfer] LME : longitudinal correlations between imaging and cognition scores

[Matthieu Vanhoutte]

Hi Martin,

I will read up on interpretation of time varying covariates.

If initially I use score as variable fixed across time, and define a
variable for 'score x time' interaction:
1) Would putting only 1 to 'score x time' column (for contrast) test for
progression of correlation patterns between atrophy and score ?
2) How to interpret this according to sign  of contrast (knowing that
decrease in score means worse performance) ?

Many thanks for your time and lights !

Best,
Matthieu

Le 17 mai 2017 1:46 PM, "Martin Reuter" <mreu...@nmr.mgh.harvard.edu> a
écrit :

Hi Matthieu,

replacing time by score is very different from adding score as a covariate.
Often scores are crude and often they are constant in controls (always full
score), and only vary slightly in diseased. In those cases it may not be
good to use score as a time variable.

I would either add avg. score as a variable (fixed across time - would
probably do this for intial testing anyway) or score as time-varying
covariate, but would read up on how to interpret results in the presence of
time-varying-covariates. I am not a statistician.
Best, Martin


On 05/16/2017 08:09 PM, Matthieu Vanhoutte wrote:

Hi Martin,

Thank you for this detailed answer.

Are replacing time by score or include score as time-varying covariate
leading to the same result because of looking at the same effect ?

My willing would be to find patterns of atrophy rate/progression correlated
with cognitive score. In context of AD which method would be the best for
you ?

Best,
Matthieu


Le 16 mai 2017 11:17 AM, "Martin Reuter" <mreu...@nmr.mgh.harvard.edu> a
écrit :

Hi Matthieu,

one option is to replace time with score in the model. That should be
straight forward.

The other option is to include score as a time-varying covariate. If your
score is not varying much across time and you are more interested if the
average score (or baseline score) affects atrophy rates, you can also
include is as a standard (fixed across time) co-variate (such as baseline
age) with a time (and a group  etc) interaction.

Sorry, but I cannot do your design. Ultimately the model is the research
question that you are asking and it is important that this is done
correctly. Maybe there is a local biostats person that you can talk to?

Best, Martin



On 05/15/2017 08:20 PM, Matthieu Vanhoutte wrote:

Hi Martin,

Thank you. How should this variable be coded ? Should it be as age
covariate where age at baseline is used along all time points of each
subject ?

Could you provide me an example of design matrix, I don't manage to see
what does it look like to.

Best regards,
Matthieu


Le 14 mai 2017 8:08 PM, "Martin Reuter" <mreu...@nmr.mgh.harvard.edu> a
écrit :

Hi Matthieu,

yes, that is possible. Instead of group, you use a variable for your score
(and interaction etc). Sometimes it may also makes sense to use score
instead of time.

Best, Martin


> On 12 May 2017, at 10:51, Matthieu Vanhoutte <matthieuvanhou...@gmail.com>
wrote:
>
> Dear Freesurfer's experts,
>
> I have searched through the mailing list but haven't found any answer to
my question.
>
> Is it possible with LME model to make correlations between for example
cortical thickness surface data and cognition scores along time ? As it is
possible to test for interaction of group X time, is this also in the same
way feasible to test for coognition score X time on cortical thickness ?
>
> Many thanks for your advice !
>
> Best regards,
> Matthieu
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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


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




___
Freesurfer mailing
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.e
du/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/compli
anceline . If the e-mail was sent to you in error 

Re: [Freesurfer] LME : longitudinal correlations between imaging and cognition scores

[Matthieu Vanhoutte]

Hi Martin,

Thank you for this detailed answer.

Are replacing time by score or include score as time-varying covariate
leading to the same result because of looking at the same effect ?

My willing would be to find patterns of atrophy rate/progression correlated
with cognitive score. In context of AD which method would be the best for
you ?

Best,
Matthieu


Le 16 mai 2017 11:17 AM, "Martin Reuter" <mreu...@nmr.mgh.harvard.edu> a
écrit :

Hi Matthieu,

one option is to replace time with score in the model. That should be
straight forward.

The other option is to include score as a time-varying covariate. If your
score is not varying much across time and you are more interested if the
average score (or baseline score) affects atrophy rates, you can also
include is as a standard (fixed across time) co-variate (such as baseline
age) with a time (and a group  etc) interaction.

Sorry, but I cannot do your design. Ultimately the model is the research
question that you are asking and it is important that this is done
correctly. Maybe there is a local biostats person that you can talk to?

Best, Martin



On 05/15/2017 08:20 PM, Matthieu Vanhoutte wrote:

Hi Martin,

Thank you. How should this variable be coded ? Should it be as age
covariate where age at baseline is used along all time points of each
subject ?

Could you provide me an example of design matrix, I don't manage to see
what does it look like to.

Best regards,
Matthieu


Le 14 mai 2017 8:08 PM, "Martin Reuter" <mreu...@nmr.mgh.harvard.edu> a
écrit :

Hi Matthieu,

yes, that is possible. Instead of group, you use a variable for your score
(and interaction etc). Sometimes it may also makes sense to use score
instead of time.

Best, Martin


> On 12 May 2017, at 10:51, Matthieu Vanhoutte <matthieuvanhou...@gmail.com>
wrote:
>
> Dear Freesurfer's experts,
>
> I have searched through the mailing list but haven't found any answer to
my question.
>
> Is it possible with LME model to make correlations between for example
cortical thickness surface data and cognition scores along time ? As it is
possible to test for interaction of group X time, is this also in the same
way feasible to test for coognition score X time on cortical thickness ?
>
> Many thanks for your advice !
>
> Best regards,
> Matthieu
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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


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




___
Freesurfer mailing
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


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


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

Re: [Freesurfer] LME : longitudinal correlations between imaging and cognition scores

[Matthieu Vanhoutte]

Hi Martin,

Thank you. How should this variable be coded ? Should it be as age
covariate where age at baseline is used along all time points of each
subject ?

Could you provide me an example of design matrix, I don't manage to see
what does it look like to.

Best regards,
Matthieu


Le 14 mai 2017 8:08 PM, "Martin Reuter" <mreu...@nmr.mgh.harvard.edu> a
écrit :

Hi Matthieu,

yes, that is possible. Instead of group, you use a variable for your score
(and interaction etc). Sometimes it may also makes sense to use score
instead of time.

Best, Martin


> On 12 May 2017, at 10:51, Matthieu Vanhoutte <matthieuvanhou...@gmail.com>
wrote:
>
> Dear Freesurfer's experts,
>
> I have searched through the mailing list but haven't found any answer to
my question.
>
> Is it possible with LME model to make correlations between for example
cortical thickness surface data and cognition scores along time ? As it is
possible to test for interaction of group X time, is this also in the same
way feasible to test for coognition score X time on cortical thickness ?
>
> Many thanks for your advice !
>
> Best regards,
> Matthieu
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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


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


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] LME : longitudinal correlations between imaging and cognition scores

[Matthieu Vanhoutte]

Dear Freesurfer's experts,

I have searched through the mailing list but haven't found any answer to my
question.

Is it possible with LME model to make correlations between for example
cortical thickness surface data and cognition scores along time ? As it is
possible to test for interaction of group X time, is this also in the same
way feasible to test for coognition score X time on cortical thickness ?

Many thanks for your advice !

Best regards,
Matthieu
___
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] Longitudinal: obtain rigid registration matrix from cross to long subject

[Matthieu Vanhoutte]

Thank you Anastasia.

Best regards,
Matthieu

2017-03-24 15:50 GMT+01:00 Yendiki, Anastasia <ayend...@mgh.harvard.edu>:

> They're under $base/mri/transforms/*.lta.
>
> --
> *From:* freesurfer-boun...@nmr.mgh.harvard.edu [
> freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Matthieu Vanhoutte [
> matthieuvanhou...@gmail.com]
> *Sent:* Friday, March 24, 2017 10:43 AM
> *To:* Freesurfer support list
> *Subject:* [Freesurfer] Longitudinal: obtain rigid registration matrix
> from cross to long subject
>
> Dear Freesurfer's experts,
>
> I would like to obtain the rigid registration matrix of the transformation
> between cross and long subject. Where could I find this (.dat or .lta file)
> ?
>
> Best regards,
> Matthieu
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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

[Freesurfer] Longitudinal: obtain rigid registration matrix from cross to long subject

[Matthieu Vanhoutte]

Dear Freesurfer's experts,

I would like to obtain the rigid registration matrix of the transformation
between cross and long subject. Where could I find this (.dat or .lta file)
?

Best regards,
Matthieu
___
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] Recon-all : mri_watershed Error: indices out of bounds

[Matthieu Vanhoutte]

Dear Freesurfer's experts,

I ran a classic recon-all and got stucked on a problem I couldn't find in
the mailing list: "*mri_watershed Error: indices out of bounds*"

*mri_watershed -T1 -brain_atlas
/home/global//freesurfer5.3//average/RB_all_withskull_2008-03-26.gca
transforms/talairach_with_skull.lta T1.mgz brainmask.auto.mgz *


*Mode:  T1 normalized volume*
*Mode:  Use the information of atlas (default parms, --help for
details)*

***
*The input file is T1.mgz*
*The output file is brainmask.auto.mgz*
*Weighting the input with atlas information before watershed*

**WATERSHED***
*Sorting...*
*  first estimation of the COG coord: x=125 y=200 z=49 r=52*
*  first estimation of the main basin volume: 593173 voxels*
*mri_watershed Error: indices out of bounds*

*Linux woody 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux*

*recon-all -s 207078_M1_2013-01-29 exited with ERRORS at Thu Mar 16
14:57:24 CET 2017*


Do you have idea or clue to this problem ?

Best regards,
Matthieu
___
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] Longitudinal stream with v6 but cross with v5.3

[Matthieu Vanhoutte]

Dear Antonin,

Thanks for the advices.

Best,
Matthieu

> Le 30 janv. 2017 à 17:45, Antonin Skoch <a...@ikem.cz> a écrit :
> 
> Dear Matthieu,
> 
> your issue is discussed here:
> 
> http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg51092.html
> 
> and indirectly also here:
> http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg5.html
> 
> I think that with V6.0 you maybe could get slightly better results (some bugs 
> have been fixed and some tools improved), but definitelly it would require to 
> re-inspect your data after reprocessing.
> 
> Antonin Skoch
> 
> 
> Dear experts,
> 
> Does anybody could answer my last request ?
> Best,
> Matthieu
> 
> 2017-01-26 9:58 GMT+01:00 Matthieu Vanhoutte <matthieuvanhou...@gmail.com>:
> 
> > Dear FS's experts,
> >
> > I have run all my cross with v5.3 and hesitate to run all longitudinal
> > process with v6. Does that make sense and will improve the process or would
> > it be risky to do this ?
> >
> > Many thanks for your lights !
> >
> > Best regards,
> > Matthieu
> 
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> 
> 
> The information in this e-mail is intended only for the person to whom it is
> addressed. If you believe this e-mail was sent to you in error and the e-mail
> contains patient information, please contact the Partners Compliance HelpLine 
> at
> http://www.partners.org/complianceline . If the e-mail was sent to you in 
> error
> but does not contain patient information, please contact the sender and 
> properly
> dispose of the e-mail.


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

Re: [Freesurfer] Longitudinal stream with v6 but cross with v5.3

[Matthieu Vanhoutte]

Dear experts,

Does anybody could answer my last request ?

Best,
Matthieu

2017-01-26 9:58 GMT+01:00 Matthieu Vanhoutte <matthieuvanhou...@gmail.com>:

> Dear FS's experts,
>
> I have run all my cross with v5.3 and hesitate to run all longitudinal
> process with v6. Does that make sense and will improve the process or would
> it be risky to do this ?
>
> Many thanks for your lights !
>
> Best regards,
> Matthieu
>
___
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] Longitudinal stream with v6 but cross with v5.3

[Matthieu Vanhoutte]

Dear FS's experts,

I have run all my cross with v5.3 and hesitate to run all longitudinal
process with v6. Does that make sense and will improve the process or would
it be risky to do this ?

Many thanks for your lights !

Best regards,
Matthieu
___
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] Longitudinal stream : LME and limits of model

[Matthieu Vanhoutte]

Dear FS's experts,

Could you answer me about questions from below inline precedent mail ?

Best regards,
Matthieu


2016-11-22 21:31 GMT+01:00 Matthieu Vanhoutte <matthieuvanhou...@gmail.com>:

> Hi Martin,
>
> Please see inline below:
>
> Le 22 nov. 2016 à 17:04, Martin Reuter <mreu...@nmr.mgh.harvard.edu> a
> écrit :
>
> Hi Matthieu,
> (also inline)
>
> On Nov 21, 2016, at 10:28 PM, Matthieu Vanhoutte <
> matthieuvanhou...@gmail.com> wrote:
>
> Hi Martin,
>
> Thanks for replying. Please see inline below:
>
> Le 21 nov. 2016 à 20:26, Martin Reuter <mreu...@nmr.mgh.harvard.edu> a
> écrit :
>
> Hi Matthieu,
>
> a few quick answers. Maybe Jorge knows more.
> Generally number of subjects / time points etc. cannot be specified
> generally. All depends on how noisy your data is and how large the effect
> is that you expect to detect. You can do a power analysis in order to
> figure out how many subject / time points would be needed. There are some
> tools for that in the LME toolbox:
> https://surfer.nmr.mgh.harvard.edu/fswiki/LinearMixedEffectsModels#
> Poweranalysis
>
> 1. see above
> 2. yes, also time points can miss from the middle. If you have mainly
> missing time points at the end, this will bias your analysis to some
> extend, as the remaining ones may be extremely healthy, as probably the
> more diseased ones drop out. You may want to do a time-to-event (or
> survival-analysis) which considers early drop-out.
>
>
> Is there any way to do with Freesurfer this kind of analysis ?
>
>
> https://surfer.nmr.mgh.harvard.edu/fswiki/SurvivalAnalysis
> Yes, there is also a paper where we do this. It is a combination of LME
> and Survival Analysis (as for the SA you need to have measurements of all
> subjects at all time points, so you estimate that from the LME model).
>
>
>
Thank you for the link, I will take a look at. So if understand, this
analysis has to be done after LME statistical analysis ? Thereafter since
SA need all time points, LME model will allow me to estimate missing time
points ?


>
>
>
> 3. see above (power analysis)
> 4. GIGO means garbage in, garbage out, so the less you QC, the more likely
> will your results be junk. The more you QC the less likely will it be junk,
> but could still be. The FS wiki has lots of tutorial information on
> checking freesurfer recons. For longitudinal, you should additionally check
> the surfaces in the base, the brain mask in the base, and the alignment of
> the time points (although there is some wiggle space for the alignment, as
> most things are allowed to evolve further for each time point).
>
>
> For the alignment of the time points, should I better comparing brainmask
> or norm.mgz ?
>
>
> It does not really matter, I would use norm.mgz. I would load images on
> top of each other and then use the opacity slider in Freeview to blend
> between them (that way the eye can pick up small motions). I would not
> worry too much about local deformations which could be caused by
> non-linearity (gradient). But if you see global misalignment (rotation,
> translation) it is a cause for concern) .
>
>
>
 Ok thank you. The non-linearity you are talking about are well provoked by
MRI system and not non-linear registration between time points and template
base, aren’t they ?


>
>
> In order to avoid bias by adding further time points in the model by the
> -add recon all command, is this better for each subject to take into
> account all the time points existing for it or only the ones that I will
> include in the model (three time points / subject ; if existing 6 time
> points for any subject ?)
>
>
> Usually it is recommended to run all time points in the model (so a base
> with 6 time points) and not use the - - add flag. Also, Linear Mixed
> Effects models deal well with missing time points. It is perfectly OK to
> have differently many time points per subject for that. You should still
> check if there is a bias (e.g. one group always has 3 time points the other
> 6) that would not be good. Maybe also consult with a local biostatistician
> if you are not comfortable with the stats. The LME tools are matlab, and so
> are the survival-analysis scripts.
>
> Best, Martin
>
>
>
> Best regards,
> Matthieu
>
>
> Best, Martin
>
> On Nov 21, 2016, at 7:07 PM, Matthieu Vanhoutte <
> matthieuvanhou...@gmail.com> wrote:
>
> Dear Freesurfer’s experts,
>
> I would have some questions regarding the LME model to be used in
> longitudinal stream:
>
> 1) Which are the ratio limits or % of missing timepoints accepted ?
> (according time, I have less and less subjects time points)
>
> 2) Is it possible to 

Re: [Freesurfer] Longitudinal stream : LME and limits of model

[Matthieu Vanhoutte]

Hi Martin,

Please see inline below:

> Le 22 nov. 2016 à 17:04, Martin Reuter <mreu...@nmr.mgh.harvard.edu> a écrit :
> 
> Hi Matthieu, 
> (also inline)
> 
>> On Nov 21, 2016, at 10:28 PM, Matthieu Vanhoutte 
>> <matthieuvanhou...@gmail.com <mailto:matthieuvanhou...@gmail.com>> wrote:
>> 
>> Hi Martin,
>> 
>> Thanks for replying. Please see inline below:
>> 
>>> Le 21 nov. 2016 à 20:26, Martin Reuter <mreu...@nmr.mgh.harvard.edu 
>>> <mailto:mreu...@nmr.mgh.harvard.edu>> a écrit :
>>> 
>>> Hi Matthieu, 
>>> 
>>> a few quick answers. Maybe Jorge knows more. 
>>> Generally number of subjects / time points etc. cannot be specified 
>>> generally. All depends on how noisy your data is and how large the effect 
>>> is that you expect to detect. You can do a power analysis in order to 
>>> figure out how many subject / time points would be needed. There are some 
>>> tools for that in the LME toolbox:
>>> https://surfer.nmr.mgh.harvard.edu/fswiki/LinearMixedEffectsModels#Poweranalysis
>>>  
>>> <https://surfer.nmr.mgh.harvard.edu/fswiki/LinearMixedEffectsModels#Poweranalysis>
>>>  
>>> 
>>> 1. see above
>>> 2. yes, also time points can miss from the middle. If you have mainly 
>>> missing time points at the end, this will bias your analysis to some 
>>> extend, as the remaining ones may be extremely healthy, as probably the 
>>> more diseased ones drop out. You may want to do a time-to-event (or 
>>> survival-analysis) which considers early drop-out.
>> 
>> Is there any way to do with Freesurfer this kind of analysis ?
> 
> https://surfer.nmr.mgh.harvard.edu/fswiki/SurvivalAnalysis 
> <https://surfer.nmr.mgh.harvard.edu/fswiki/SurvivalAnalysis> 
> Yes, there is also a paper where we do this. It is a combination of LME and 
> Survival Analysis (as for the SA you need to have measurements of all 
> subjects at all time points, so you estimate that from the LME model). 

Thank you for the link, I will take a look at. So if understand, this analysis 
has to be done after LME statistical analysis ? Thereafter since SA need all 
time points, LME model will allow me to estimate missing time points ?

> 
>> 
>>> 3. see above (power analysis)
>>> 4. GIGO means garbage in, garbage out, so the less you QC, the more likely 
>>> will your results be junk. The more you QC the less likely will it be junk, 
>>> but could still be. The FS wiki has lots of tutorial information on 
>>> checking freesurfer recons. For longitudinal, you should additionally check 
>>> the surfaces in the base, the brain mask in the base, and the alignment of 
>>> the time points (although there is some wiggle space for the alignment, as 
>>> most things are allowed to evolve further for each time point). 
>> 
>> For the alignment of the time points, should I better comparing brainmask or 
>> norm.mgz ?
> 
> It does not really matter, I would use norm.mgz. I would load images on top 
> of each other and then use the opacity slider in Freeview to blend between 
> them (that way the eye can pick up small motions). I would not worry too much 
> about local deformations which could be caused by non-linearity (gradient). 
> But if you see global misalignment (rotation, translation) it is a cause for 
> concern) .

Ok thank you. The non-linearity you are talking about are well provoked by MRI 
system and not non-linear registration between time points and template base, 
aren’t they ?

Best regards,
Matthieu

> 
>> 
>> In order to avoid bias by adding further time points in the model by the 
>> -add recon all command, is this better for each subject to take into account 
>> all the time points existing for it or only the ones that I will include in 
>> the model (three time points / subject ; if existing 6 time points for any 
>> subject ?)
>> 
> 
> Usually it is recommended to run all time points in the model (so a base with 
> 6 time points) and not use the - - add flag. Also, Linear Mixed Effects 
> models deal well with missing time points. It is perfectly OK to have 
> differently many time points per subject for that. You should still check if 
> there is a bias (e.g. one group always has 3 time points the other 6) that 
> would not be good. Maybe also consult with a local biostatistician if you are 
> not comfortable with the stats. The LME tools are matlab, and so are the 
> survival-analysis scripts. 
> 
> Best, Martin
> 
> 
> 
>> Best regards,
>> Matthieu
>> 
>>> 
>>> Best, Martin

Re: [Freesurfer] Longitudinal stream : LME and limits of model

[Matthieu Vanhoutte]

Hi Martin,

Thanks for replying. Please see inline below:

> Le 21 nov. 2016 à 20:26, Martin Reuter <mreu...@nmr.mgh.harvard.edu> a écrit :
> 
> Hi Matthieu, 
> 
> a few quick answers. Maybe Jorge knows more. 
> Generally number of subjects / time points etc. cannot be specified 
> generally. All depends on how noisy your data is and how large the effect is 
> that you expect to detect. You can do a power analysis in order to figure out 
> how many subject / time points would be needed. There are some tools for that 
> in the LME toolbox:
> https://surfer.nmr.mgh.harvard.edu/fswiki/LinearMixedEffectsModels#Poweranalysis
>  
> <https://surfer.nmr.mgh.harvard.edu/fswiki/LinearMixedEffectsModels#Poweranalysis>
>  
> 
> 1. see above
> 2. yes, also time points can miss from the middle. If you have mainly missing 
> time points at the end, this will bias your analysis to some extend, as the 
> remaining ones may be extremely healthy, as probably the more diseased ones 
> drop out. You may want to do a time-to-event (or survival-analysis) which 
> considers early drop-out.

Is there any way to do with Freesurfer this kind of analysis ?

> 3. see above (power analysis)
> 4. GIGO means garbage in, garbage out, so the less you QC, the more likely 
> will your results be junk. The more you QC the less likely will it be junk, 
> but could still be. The FS wiki has lots of tutorial information on checking 
> freesurfer recons. For longitudinal, you should additionally check the 
> surfaces in the base, the brain mask in the base, and the alignment of the 
> time points (although there is some wiggle space for the alignment, as most 
> things are allowed to evolve further for each time point). 

For the alignment of the time points, should I better comparing brainmask or 
norm.mgz ?

In order to avoid bias by adding further time points in the model by the -add 
recon all command, is this better for each subject to take into account all the 
time points existing for it or only the ones that I will include in the model 
(three time points / subject ; if existing 6 time points for any subject ?)

Best regards,
Matthieu

> 
> Best, Martin
> 
>> On Nov 21, 2016, at 7:07 PM, Matthieu Vanhoutte <matthieuvanhou...@gmail.com 
>> <mailto:matthieuvanhou...@gmail.com>> wrote:
>> 
>> Dear Freesurfer’s experts,
>> 
>> I would have some questions regarding the LME model to be used in 
>> longitudinal stream:
>> 
>> 1) Which are the ratio limits or % of missing timepoints accepted ? 
>> (according time, I have less and less subjects time points)
>> 
>> 2) Is it possible to include patients that would miss the first timepoint 
>> but got the others ?
>> 
>> 3) Considering a group in longitudinal study, which is the number of 
>> subjects minimal of this group accepted for LME modeling ?
>> 
>> 4) Finally, concerning quality control and among a big number of total time 
>> points, which essential controls are necessary ? (Control of norm.mgz of the 
>> base, alignment of longitudinal timepoints on base,… ?)
>> 
>> Best regards,
>> Matthieu
>> 
>> 
>> ___
>> 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
> 
> 
> The information in this e-mail is intended only for the person to whom it is
> addressed. If you believe this e-mail was sent to you in error and the e-mail
> contains patient information, please contact the Partners Compliance HelpLine 
> at
> http://www.partners.org/complianceline . If the e-mail was sent to you in 
> error
> but does not contain patient information, please contact the sender and 
> properly
> dispose of the e-mail.

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


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

[Freesurfer] Longitudinal stream : LME and limits of model

[Matthieu Vanhoutte]

Dear Freesurfer’s experts,

I would have some questions regarding the LME model to be used in longitudinal 
stream:

1) Which are the ratio limits or % of missing timepoints accepted ? (according 
time, I have less and less subjects time points)

2) Is it possible to include patients that would miss the first timepoint but 
got the others ?

3) Considering a group in longitudinal study, which is the number of subjects 
minimal of this group accepted for LME modeling ?

4) Finally, concerning quality control and among a big number of total time 
points, which essential controls are necessary ? (Control of norm.mgz of the 
base, alignment of longitudinal timepoints on base,… ?)

Best regards,
Matthieu


___
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] Longitudinal surface analysis of PET data

[Matthieu Vanhoutte]

Hi Martin,

Thank you for clarifications !

1) What do you mean by "If, for some reason, the pet and MR (cross) are
already very close in space" ?

2) How could it be possible to directly register to the long time point ?
Since I use a rigid registration, the long time point T1 will not have been
deformed (affine or non linear) ?

Best regards,
Matthieu

2016-11-18 11:18 GMT+01:00 Martin Reuter <mreu...@nmr.mgh.harvard.edu>:

> Hi Matthieu,
>
> to clarify, you can directly register to the long time point.
>
> If, for some reason, the pet and MR (cross) are already very close in
> space, it may make sense to first register to that, then concatenate that
> transform with the one from cross to long and then map the PET there. Don’t
> map it twice, instead concatenate the transforms.
> mri_concatenate_lta will do that.
>
> You find the transforms from base to each time point in the long
> mri/transforms directory and probably also in the base/mri/transforms dir.
>
> Best, Martin
>
> On Nov 14, 2016, at 5:49 PM, Matthieu Vanhoutte <
> matthieuvanhou...@gmail.com> wrote:
>
> Thank you !
>
> Best regards,
> Matthieu
>
> 2016-11-14 17:48 GMT+01:00 Douglas N Greve <gr...@nmr.mgh.harvard.edu>:
>
>> Rigid.
>>
>>
>> On 11/14/2016 11:43 AM, Matthieu Vanhoutte wrote:
>> > Still using rigid-body registration on --long subject directory ?
>> >
>> >  Or is affine registration in this case needed ?
>> >
>> > Best regards,
>> > Matthieu
>> >
>> > 2016-11-14 17:12 GMT+01:00 Douglas N Greve <gr...@nmr.mgh.harvard.edu
>> > <mailto:gr...@nmr.mgh.harvard.edu>>:
>> >
>> > I would just register the pet to the closest (in time) anatomical
>> >
>> >
>> > On 11/14/2016 07:20 AM, Matthieu Vanhoutte wrote:
>> > > Dear Freesurfer's experts,
>> > >
>> > > I come back to you concerning questions of registrations.
>> > >
>> > > Since during the longitudinal process each --long subject
>> directory
>> > > has been registered onto the common --base template, shouldn't I:
>> > >
>> > > 1) Register PET data onto the subject cross-sectional directory
>> > > (native data) with rigid-body transformation
>> > > 2) Then take into account the registration between --cross and
>> > --long
>> > > directory subject and apply the registration to the PET first
>> > > registered onto native space ? In this case, how and where is this
>> > > transformation has been saved ?
>> > >
>> > > Best regards,
>> > > Matthieu
>> > >
>> > > 2016-09-30 23:05 GMT+02:00 Douglas N Greve
>> > <gr...@nmr.mgh.harvard.edu <mailto:gr...@nmr.mgh.harvard.edu>
>> > > <mailto:gr...@nmr.mgh.harvard.edu
>> > <mailto:gr...@nmr.mgh.harvard.edu>>>:
>> > >
>> > > Yes
>> > >
>> > >
>> > > On 09/30/2016 05:05 PM, Matthieu Vanhoutte wrote:
>> > > >
>> > > > Hi Douglas,
>> > > >
>> > > > Does the surface of the closest MRI time point mean the
>> > surface
>> > > of the
>> > > > -long subject time point directory rather than
>> cross-sectional
>> > > subject
>> > > > time point directory ?
>> > > >
>> > > > Best regards,
>> > > > Matthieu
>> > > >
>> > > >
>> > > > Le 30 sept. 2016 9:14 PM, "Douglas N Greve"
>> >     > <gr...@nmr.mgh.harvard.edu
>> > <mailto:gr...@nmr.mgh.harvard.edu>
>> > <mailto:gr...@nmr.mgh.harvard.edu <mailto:gr...@nmr.mgh.harvard.edu
>> >>
>> > > > <mailto:gr...@nmr.mgh.harvard.edu
>> > <mailto:gr...@nmr.mgh.harvard.edu>
>> > > <mailto:gr...@nmr.mgh.harvard.edu
>> > <mailto:gr...@nmr.mgh.harvard.edu>>>> a écrit :
>> > > >
>> > > > There is no such long process for PET. The idea is
>> > that you
>> > > > process the
>> > > > MRI in a longitudinal way, then sample the PET data
>> > onto the
>> > >

Re: [Freesurfer] Longitudinal surface analysis of PET data

[Matthieu Vanhoutte]

Thank you !

Best regards,
Matthieu

2016-11-14 17:48 GMT+01:00 Douglas N Greve <gr...@nmr.mgh.harvard.edu>:

> Rigid.
>
>
> On 11/14/2016 11:43 AM, Matthieu Vanhoutte wrote:
> > Still using rigid-body registration on --long subject directory ?
> >
> >  Or is affine registration in this case needed ?
> >
> > Best regards,
> > Matthieu
> >
> > 2016-11-14 17:12 GMT+01:00 Douglas N Greve <gr...@nmr.mgh.harvard.edu
> > <mailto:gr...@nmr.mgh.harvard.edu>>:
> >
> > I would just register the pet to the closest (in time) anatomical
> >
> >
> > On 11/14/2016 07:20 AM, Matthieu Vanhoutte wrote:
> > > Dear Freesurfer's experts,
> > >
> > > I come back to you concerning questions of registrations.
> > >
> > > Since during the longitudinal process each --long subject directory
> > > has been registered onto the common --base template, shouldn't I:
> > >
> > > 1) Register PET data onto the subject cross-sectional directory
> > > (native data) with rigid-body transformation
> > > 2) Then take into account the registration between --cross and
> > --long
> > > directory subject and apply the registration to the PET first
> > > registered onto native space ? In this case, how and where is this
> > > transformation has been saved ?
> > >
> > > Best regards,
> > > Matthieu
> > >
> > > 2016-09-30 23:05 GMT+02:00 Douglas N Greve
> > <gr...@nmr.mgh.harvard.edu <mailto:gr...@nmr.mgh.harvard.edu>
> > > <mailto:gr...@nmr.mgh.harvard.edu
> > <mailto:gr...@nmr.mgh.harvard.edu>>>:
> > >
> > > Yes
> > >
> > >
> > > On 09/30/2016 05:05 PM, Matthieu Vanhoutte wrote:
> > > >
> > > > Hi Douglas,
> > > >
> > > > Does the surface of the closest MRI time point mean the
> > surface
> > > of the
> > > > -long subject time point directory rather than
> cross-sectional
> > > subject
> > > > time point directory ?
> > > >
> > > > Best regards,
> > > > Matthieu
> > > >
> > > >
> > > > Le 30 sept. 2016 9:14 PM, "Douglas N Greve"
> > > <gr...@nmr.mgh.harvard.edu
> > <mailto:gr...@nmr.mgh.harvard.edu>
> > <mailto:gr...@nmr.mgh.harvard.edu <mailto:gr...@nmr.mgh.harvard.edu
> >>
> > > > <mailto:gr...@nmr.mgh.harvard.edu
> > <mailto:gr...@nmr.mgh.harvard.edu>
> > > <mailto:gr...@nmr.mgh.harvard.edu
> > <mailto:gr...@nmr.mgh.harvard.edu>>>> a écrit :
> > > >
> > > > There is no such long process for PET. The idea is
> > that you
> > > > process the
> > > > MRI in a longitudinal way, then sample the PET data
> > onto the
> > > > surface of
> > > > the closest MRI time point. Then proceed in a way
> > similar to the
> > > > thickness analysis
> > > >
> > > >
> > > > On 09/29/2016 11:08 AM, Matthieu Vanhoutte wrote:
> > > > > Dear Freesurfer's experts,
> > > > >
> > > > > Could you answer me about my last question with no
> > > response in the
> > > > > mail below ?
> > > > >
> > > > > When using cortical thickness in longitudinal analysis
> > > with LME, we
> > > > > used lh.thickness or rh.thickness from -long subject
> > > directories.
> > > > > These data followed particular processing steps
> > including
> > > > > registrations in order to use them with more
> > precision in
> > > > longitudinal
> > > > > studies, didn't they ?
> > > > >
> > > > > My problem is that I would like to perform longitudinal
> > > study on PET
> > > > > data images with LME. So I wonder if I just have to
> > > resample onto
> &g

Re: [Freesurfer] Longitudinal surface analysis of PET data

[Matthieu Vanhoutte]

Still using rigid-body registration on --long subject directory ?

 Or is affine registration in this case needed ?

Best regards,
Matthieu

2016-11-14 17:12 GMT+01:00 Douglas N Greve <gr...@nmr.mgh.harvard.edu>:

> I would just register the pet to the closest (in time) anatomical
>
>
> On 11/14/2016 07:20 AM, Matthieu Vanhoutte wrote:
> > Dear Freesurfer's experts,
> >
> > I come back to you concerning questions of registrations.
> >
> > Since during the longitudinal process each --long subject directory
> > has been registered onto the common --base template, shouldn't I:
> >
> > 1) Register PET data onto the subject cross-sectional directory
> > (native data) with rigid-body transformation
> > 2) Then take into account the registration between --cross and --long
> > directory subject and apply the registration to the PET first
> > registered onto native space ? In this case, how and where is this
> > transformation has been saved ?
> >
> > Best regards,
> > Matthieu
> >
> > 2016-09-30 23:05 GMT+02:00 Douglas N Greve <gr...@nmr.mgh.harvard.edu
> > <mailto:gr...@nmr.mgh.harvard.edu>>:
> >
> > Yes
> >
> >
> > On 09/30/2016 05:05 PM, Matthieu Vanhoutte wrote:
> > >
> > > Hi Douglas,
> > >
> > > Does the surface of the closest MRI time point mean the surface
> > of the
> > > -long subject time point directory rather than cross-sectional
> > subject
> > > time point directory ?
> > >
> > > Best regards,
> > > Matthieu
> > >
> > >
> > > Le 30 sept. 2016 9:14 PM, "Douglas N Greve"
> > <gr...@nmr.mgh.harvard.edu <mailto:gr...@nmr.mgh.harvard.edu>
> > > <mailto:gr...@nmr.mgh.harvard.edu
> > <mailto:gr...@nmr.mgh.harvard.edu>>> a écrit :
> > >
> > > There is no such long process for PET. The idea is that you
> > > process the
> > > MRI in a longitudinal way, then sample the PET data onto the
> > > surface of
> > > the closest MRI time point. Then proceed in a way similar to
> the
> > > thickness analysis
> > >
> > >
> > > On 09/29/2016 11:08 AM, Matthieu Vanhoutte wrote:
> > > > Dear Freesurfer's experts,
> > > >
> > > > Could you answer me about my last question with no
> > response in the
> > > > mail below ?
> > > >
> > > > When using cortical thickness in longitudinal analysis
> > with LME, we
> > > > used lh.thickness or rh.thickness from -long subject
> > directories.
> > > > These data followed particular processing steps including
> > > > registrations in order to use them with more precision in
> > > longitudinal
> > > > studies, didn't they ?
> > > >
> > > > My problem is that I would like to perform longitudinal
> > study on PET
> > > > data images with LME. So I wonder if I just have to
> > resample onto
> > > > -long cortical subject surface ? Do I need to follow the
> > same steps
> > > > than cortical thickness from cross-sectional to -long subject
> > > > directories ? If this is the case, which commands should I
> > use to
> > > > mimic cortical thickness longitudinal data ?
> > > >
> > > > Many thanks in advance for helping !
> > > >
> > > > Best regards,
> > > > Matthieu
> > > >
> > > > 2016-09-18 23:02 GMT+02:00 Matthieu Vanhoutte
> > > > <matthieuvanhou...@gmail.com
> > <mailto:matthieuvanhou...@gmail.com>
> > > <mailto:matthieuvanhou...@gmail.com
> > <mailto:matthieuvanhou...@gmail.com>>
> > > <mailto:matthieuvanhou...@gmail.com
> > <mailto:matthieuvanhou...@gmail.com>
> > > <mailto:matthieuvanhou...@gmail.com <mailto:matthieuvanhoutte@
> gmail.com>>>>:
> > > >
> > > > Hi Martin,
> > > >
> > > > Thanks for your answer. However, it seems to me that
> > cortical
> > > > t

Re: [Freesurfer] Longitudinal surface analysis of PET data

[Matthieu Vanhoutte]

Dear Freesurfer's experts,

I come back to you concerning questions of registrations.

Since during the longitudinal process each --long subject directory has
been registered onto the common --base template, shouldn't I:

1) Register PET data onto the subject cross-sectional directory (native
data) with rigid-body transformation
2) Then take into account the registration between --cross and --long
directory subject and apply the registration to the PET first registered
onto native space ? In this case, how and where is this transformation has
been saved ?

Best regards,
Matthieu

2016-09-30 23:05 GMT+02:00 Douglas N Greve <gr...@nmr.mgh.harvard.edu>:

> Yes
>
>
> On 09/30/2016 05:05 PM, Matthieu Vanhoutte wrote:
> >
> > Hi Douglas,
> >
> > Does the surface of the closest MRI time point mean the surface of the
> > -long subject time point directory rather than cross-sectional subject
> > time point directory ?
> >
> > Best regards,
> > Matthieu
> >
> >
> > Le 30 sept. 2016 9:14 PM, "Douglas N Greve" <gr...@nmr.mgh.harvard.edu
> > <mailto:gr...@nmr.mgh.harvard.edu>> a écrit :
> >
> > There is no such long process for PET. The idea is that you
> > process the
> > MRI in a longitudinal way, then sample the PET data onto the
> > surface of
> > the closest MRI time point. Then proceed in a way similar to the
> > thickness analysis
> >
> >
> > On 09/29/2016 11:08 AM, Matthieu Vanhoutte wrote:
> > > Dear Freesurfer's experts,
> > >
> > > Could you answer me about my last question with no response in the
> > > mail below ?
> > >
> > > When using cortical thickness in longitudinal analysis with LME, we
> > > used lh.thickness or rh.thickness from -long subject directories.
> > > These data followed particular processing steps including
> > > registrations in order to use them with more precision in
> > longitudinal
> > > studies, didn't they ?
> > >
> > > My problem is that I would like to perform longitudinal study on
> PET
> > > data images with LME. So I wonder if I just have to resample onto
> > > -long cortical subject surface ? Do I need to follow the same steps
> > > than cortical thickness from cross-sectional to -long subject
> > > directories ? If this is the case, which commands should I use to
> > > mimic cortical thickness longitudinal data ?
> > >
> > > Many thanks in advance for helping !
> > >
> > > Best regards,
> > > Matthieu
> > >
> > > 2016-09-18 23:02 GMT+02:00 Matthieu Vanhoutte
> > > <matthieuvanhou...@gmail.com
> > <mailto:matthieuvanhou...@gmail.com>
> > <mailto:matthieuvanhou...@gmail.com
> > <mailto:matthieuvanhou...@gmail.com>>>:
> > >
> > > Hi Martin,
> > >
> > > Thanks for your answer. However, it seems to me that cortical
> > > thickness follow a particular process with the recon-all -long
> > > process, isn’t it ? Is there any resample onto average time
> > > subject then other operation following ?
> > >
> > > Best regards,
> > > Matthieu
> > >
> > > > Le 18 sept. 2016 à 16:26, Martin Reuter
> > > <mreu...@nmr.mgh.harvard.edu
> > <mailto:mreu...@nmr.mgh.harvard.edu>
> > <mailto:mreu...@nmr.mgh.harvard.edu
> > <mailto:mreu...@nmr.mgh.harvard.edu>>>
> > > a écrit :
> > > >
> > > > Hi Matthieu,
> > > >
> > > > I never used PET data, but once you manage to resample you
> pet
> > > data onto the surface, you will have a file similar to the
> > > thickness file for each subjects. Instead of thickness it holds
> > > you PET information. From that point on everything should be
> > > identical to the thickness analysis.
> > > >
> > > > So this is really more a question how to get your PET data
> > > sampled onto the surface. If no one else replies, write that
> > into
> > > the subject line and repost.
> > > >
> > > > Best, Martin
> > > >
> > > >
> > > >> On Sep 17, 2016, at 7:37 AM, Matthieu Va

Re: [Freesurfer] Mean intensity with mri_segstats : different results with .annot or .label

[Matthieu Vanhoutte]

Is it better to compute mean to weight by number of vertices or surface
area ?

Best,
Matthieu

Le 11 nov. 2016 11:33 PM, "Douglas N Greve" <gr...@nmr.mgh.harvard.edu> a
écrit :

> Vertices do not have equal areas and are not equally spaced
>
>
> On 11/11/2016 05:11 PM, Matthieu Vanhoutte wrote:
> >
> > Thank you Douglas for giving me a way to compute area from segmented
> > surface data.
> >
> > Are vertices equally spaced along cortex or do triangles all have same
> > area ?
> >
> > Best,
> > Matthieu
> >
> >
> > Le 11 nov. 2016 10:55 PM, "Douglas N Greve" <gr...@nmr.mgh.harvard.edu
> > <mailto:gr...@nmr.mgh.harvard.edu>> a écrit :
> >
> > If you want to do it on fsaverage, then
> >
> > mris_segstats --i $SUBJECTS/fsaverage/surf/lh.white.avg.area.mgh
> --seg
> > lh.sign_clust.bin.mgh
> > --excludeid 0 --sum lh.bin.area.sum --accumulate
> >
> >
> >
> >
> > On 11/11/2016 04:48 PM, Matthieu Vanhoutte wrote:
> > >
> > > Dear Douglas,
> > >
> > > Yes I would like to in order to compute mean of some means.
> > Maybe not
> > > if it is equivalent to number of vertices (are vertices distributed
> > > equaly distant on the cortical surface ?)
> > >
> > > In case I need surface area, do I have to convert overlay to
> > > annotation file to be used with mri_segstats ?
> > >
> > > Best regards,
> > > Matthieu
> > >
> > >
> > > Le 11 nov. 2016 9:21 PM, "Douglas N Greve"
> > <gr...@nmr.mgh.harvard.edu <mailto:gr...@nmr.mgh.harvard.edu>
> > > <mailto:gr...@nmr.mgh.harvard.edu
> > <mailto:gr...@nmr.mgh.harvard.edu>>> a écrit :
> > >
> > > NVox is the number of vertices. The Volume_mm3 is not
> > meaningful.
> > > Do you
> > > want area?
> > >
> > >
> > > On 11/11/2016 04:53 AM, Matthieu Vanhoutte wrote:
> > > > Dear Douglas,
> > > >
> > > > I come back to you concerning stats made from binary .mgh
> > > surface data
> > > > file:
> > > >
> > > > mri_segstats --i lh.fsaverage.sm10.mgh --seg
> > lh.sign_clust.bin.mgh
> > > > --excludeid 0 --sum lh.bin.sum --avgwf lh.wav.bin.txt
> > > >
> > > > In the output file « lh.bin.sum » all is considered as volume
> > > > input/output as you could see below:
> > > >
> > > > /# InVolFileTimeStamp  2016/04/28 09:46:19 /
> > > > /# InVolFrame 0 /
> > > > /# ExcludeSegId 0 /
> > > > /# Only reporting non-empty segmentations/
> > > > /# VoxelVolume_mm3 1 /
> > > > /# TableCol  1 ColHeader Index /
> > > > /# TableCol  1 FieldName Index /
> > > > /# TableCol  1 Units NA /
> > > > /# TableCol  2 ColHeader SegId /
> > > > /# TableCol  2 FieldName Segmentation Id/
> > > > /# TableCol  2 Units NA/
> > > > /# TableCol  3 ColHeader NVoxels /
> > > > /# TableCol  3 FieldName Number of Voxels/
> > > > /# TableCol  3 Units unitless/
> > > > /# TableCol  4 ColHeader Volume_mm3/
> > > > /# TableCol  4 FieldName Volume/
> > > > /# TableCol  4 Units mm^3/
> > > > /# TableCol  5 ColHeader Mean /
> > > > /# TableCol  5 FieldName Intensity Mean/
> > > > /# TableCol  5 Units unknown/
> > > > /# TableCol  6 ColHeader StdDev/
> > > > /# TableCol  6 FieldName Itensity StdDev/
> > > > /# TableCol  6 Units unknown/
> > > > /# TableCol  7 ColHeader Min/
> > > > /# TableCol  7 FieldName Intensity Min/
> > > > /# TableCol  7 Units unknown/
> > > > /# TableCol  8 ColHeader Max/
> > > > /# TableCol  8 FieldName Intensity Max/
> > > > /# TableCol  8 Units unknown/
> > > > /# TableCol  9 ColHeader Range/
> > > > /# TableCol  9 FieldName Intensity Range/
> > > > /# TableCol  9 Units unknown/
> > >

Re: [Freesurfer] Mean intensity with mri_segstats : different results with .annot or .label

[Matthieu Vanhoutte]

Thank you Douglas for giving me a way to compute area from segmented
surface data.

Are vertices equally spaced along cortex or do triangles all have same area
?

Best,
Matthieu

Le 11 nov. 2016 10:55 PM, "Douglas N Greve" <gr...@nmr.mgh.harvard.edu> a
écrit :

If you want to do it on fsaverage, then

mris_segstats --i $SUBJECTS/fsaverage/surf/lh.white.avg.area.mgh --seg
lh.sign_clust.bin.mgh
--excludeid 0 --sum lh.bin.area.sum --accumulate




On 11/11/2016 04:48 PM, Matthieu Vanhoutte wrote:
>
> Dear Douglas,
>
> Yes I would like to in order to compute mean of some means. Maybe not
> if it is equivalent to number of vertices (are vertices distributed
> equaly distant on the cortical surface ?)
>
> In case I need surface area, do I have to convert overlay to
> annotation file to be used with mri_segstats ?
>
> Best regards,
> Matthieu
>
>
> Le 11 nov. 2016 9:21 PM, "Douglas N Greve" <gr...@nmr.mgh.harvard.edu
> <mailto:gr...@nmr.mgh.harvard.edu>> a écrit :
>
> NVox is the number of vertices. The Volume_mm3 is not meaningful.
> Do you
> want area?
>
>
> On 11/11/2016 04:53 AM, Matthieu Vanhoutte wrote:
> > Dear Douglas,
> >
> > I come back to you concerning stats made from binary .mgh
> surface data
> > file:
> >
> > mri_segstats --i lh.fsaverage.sm10.mgh --seg lh.sign_clust.bin.mgh
> > --excludeid 0 --sum lh.bin.sum --avgwf lh.wav.bin.txt
> >
> > In the output file « lh.bin.sum » all is considered as volume
> > input/output as you could see below:
> >
> > /# InVolFileTimeStamp  2016/04/28 09:46:19 /
> > /# InVolFrame 0 /
> > /# ExcludeSegId 0 /
> > /# Only reporting non-empty segmentations/
> > /# VoxelVolume_mm3 1 /
> > /# TableCol  1 ColHeader Index /
> > /# TableCol  1 FieldName Index /
> > /# TableCol  1 Units NA /
> > /# TableCol  2 ColHeader SegId /
> > /# TableCol  2 FieldName Segmentation Id/
> > /# TableCol  2 Units NA/
> > /# TableCol  3 ColHeader NVoxels /
> > /# TableCol  3 FieldName Number of Voxels/
> > /# TableCol  3 Units unitless/
> > /# TableCol  4 ColHeader Volume_mm3/
> > /# TableCol  4 FieldName Volume/
> > /# TableCol  4 Units mm^3/
> > /# TableCol  5 ColHeader Mean /
> > /# TableCol  5 FieldName Intensity Mean/
> > /# TableCol  5 Units unknown/
> > /# TableCol  6 ColHeader StdDev/
> > /# TableCol  6 FieldName Itensity StdDev/
> > /# TableCol  6 Units unknown/
> > /# TableCol  7 ColHeader Min/
> > /# TableCol  7 FieldName Intensity Min/
> > /# TableCol  7 Units unknown/
> > /# TableCol  8 ColHeader Max/
> > /# TableCol  8 FieldName Intensity Max/
> > /# TableCol  8 Units unknown/
> > /# TableCol  9 ColHeader Range/
> > /# TableCol  9 FieldName Intensity Range/
> > /# TableCol  9 Units unknown/
> > /# NRows 1 /
> > /# NTableCols 9 /
> > /# ColHeaders  Index SegId NVoxels Volume_mm3 StructName Mean StdDev
> > Min Max Range /
> > /  1   1 1151011510.0  Seg0001 7.6819  1.4396
> > 4.486210.9042 6.4180 /
> >
> > As my inputs are all surface data could I consider that NVoxels is
> > equal to NVertices and Volume_mm3 is equal to SurfaceArea_mm2 ?
> >
> > Best regards,
> > Matthieu
> >
> >> Le 10 nov. 2016 à 23:18, Matthieu Vanhoutte
> >> <matthieuvanhou...@gmail.com
> <mailto:matthieuvanhou...@gmail.com>
> <mailto:matthieuvanhou...@gmail.com
> <mailto:matthieuvanhou...@gmail.com>>> a
> >> écrit :
> >>
> >> Thank you Douglas !
> >>
> >>
> >> Le 10 nov. 2016 7:21 PM, "Douglas N Greve"
> <gr...@nmr.mgh.harvard.edu <mailto:gr...@nmr.mgh.harvard.edu>
> >> <mailto:gr...@nmr.mgh.harvard.edu
> <mailto:gr...@nmr.mgh.harvard.edu>>> a écrit :
> >>
> >> You need to weight by the number of vertices
> >>
> >> n = [27805 2321 552];
> >>   m = [8.8194 10.3661 10.3365];
> >> sum(n.*m)/sum(n)
> >>
> >> ans =
> >>
> >>  8.9637
> >>
> >>
> >> On 11/10/2016 06:44 AM, Matthieu Vanhoutte wrote:
> >> > Dear Freesurfer's experts,
> >> &g

Re: [Freesurfer] Mean intensity with mri_segstats : different results with .annot or .label

[Matthieu Vanhoutte]

Dear Douglas,

Yes I would like to in order to compute mean of some means. Maybe not if it
is equivalent to number of vertices (are vertices distributed equaly
distant on the cortical surface ?)

In case I need surface area, do I have to convert overlay to annotation
file to be used with mri_segstats ?

Best regards,
Matthieu

Le 11 nov. 2016 9:21 PM, "Douglas N Greve" <gr...@nmr.mgh.harvard.edu> a
écrit :

> NVox is the number of vertices. The Volume_mm3 is not meaningful. Do you
> want area?
>
>
> On 11/11/2016 04:53 AM, Matthieu Vanhoutte wrote:
> > Dear Douglas,
> >
> > I come back to you concerning stats made from binary .mgh surface data
> > file:
> >
> > mri_segstats --i lh.fsaverage.sm10.mgh --seg lh.sign_clust.bin.mgh
> > --excludeid 0 --sum lh.bin.sum --avgwf lh.wav.bin.txt
> >
> > In the output file « lh.bin.sum » all is considered as volume
> > input/output as you could see below:
> >
> > /# InVolFileTimeStamp  2016/04/28 09:46:19 /
> > /# InVolFrame 0 /
> > /# ExcludeSegId 0 /
> > /# Only reporting non-empty segmentations/
> > /# VoxelVolume_mm3 1 /
> > /# TableCol  1 ColHeader Index /
> > /# TableCol  1 FieldName Index /
> > /# TableCol  1 Units NA /
> > /# TableCol  2 ColHeader SegId /
> > /# TableCol  2 FieldName Segmentation Id/
> > /# TableCol  2 Units NA/
> > /# TableCol  3 ColHeader NVoxels /
> > /# TableCol  3 FieldName Number of Voxels/
> > /# TableCol  3 Units unitless/
> > /# TableCol  4 ColHeader Volume_mm3/
> > /# TableCol  4 FieldName Volume/
> > /# TableCol  4 Units mm^3/
> > /# TableCol  5 ColHeader Mean /
> > /# TableCol  5 FieldName Intensity Mean/
> > /# TableCol  5 Units unknown/
> > /# TableCol  6 ColHeader StdDev/
> > /# TableCol  6 FieldName Itensity StdDev/
> > /# TableCol  6 Units unknown/
> > /# TableCol  7 ColHeader Min/
> > /# TableCol  7 FieldName Intensity Min/
> > /# TableCol  7 Units unknown/
> > /# TableCol  8 ColHeader Max/
> > /# TableCol  8 FieldName Intensity Max/
> > /# TableCol  8 Units unknown/
> > /# TableCol  9 ColHeader Range/
> > /# TableCol  9 FieldName Intensity Range/
> > /# TableCol  9 Units unknown/
> > /# NRows 1 /
> > /# NTableCols 9 /
> > /# ColHeaders  Index SegId NVoxels Volume_mm3 StructName Mean StdDev
> > Min Max Range /
> > /  1   1 1151011510.0  Seg0001 7.6819 1.4396
> > 4.486210.9042 6.4180 /
> >
> > As my inputs are all surface data could I consider that NVoxels is
> > equal to NVertices and Volume_mm3 is equal to SurfaceArea_mm2 ?
> >
> > Best regards,
> > Matthieu
> >
> >> Le 10 nov. 2016 à 23:18, Matthieu Vanhoutte
> >> <matthieuvanhou...@gmail.com <mailto:matthieuvanhou...@gmail.com>> a
> >> écrit :
> >>
> >> Thank you Douglas !
> >>
> >>
> >> Le 10 nov. 2016 7:21 PM, "Douglas N Greve" <gr...@nmr.mgh.harvard.edu
> >> <mailto:gr...@nmr.mgh.harvard.edu>> a écrit :
> >>
> >> You need to weight by the number of vertices
> >>
> >> n = [27805 2321 552];
> >>   m = [8.8194 10.3661 10.3365];
> >> sum(n.*m)/sum(n)
> >>
> >> ans =
> >>
> >>  8.9637
> >>
> >>
> >> On 11/10/2016 06:44 AM, Matthieu Vanhoutte wrote:
> >> > Dear Freesurfer's experts,
> >> >
> >> > Could anyone please explain me the difference I got with
> >> command line
> >> > in below mail ?
> >> >
> >> > Best regards,
> >> > Matthieu
> >> >
> >> > 2016-08-12 12:07 GMT+02:00 Matthieu Vanhoutte
> >> > <matthieuvanhou...@gmail.com
> >> <mailto:matthieuvanhou...@gmail.com>
> >> <mailto:matthieuvanhou...@gmail.com
> >> <mailto:matthieuvanhou...@gmail.com>>>:
> >> >
> >> > Dear experts,
> >> >
> >> > I am in trouble with two ways of computing mean intensity with
> >> > mri_segstats.
> >> >
> >> > First I have used on .annot files with three different labels
> >> > inside (SegId 1 to 3) :
> >> >
> >> > /mri_segstats --annot fsaverage lh
> cache.th23.pos.sig.ocn.annot
> >> > --i lh.PET.fsaverage.sm10.mgh --sum lh.pet.su

Re: [Freesurfer] Mean intensity with mri_segstats : different results with .annot or .label

[Matthieu Vanhoutte]

Dear Douglas,

I come back to you concerning stats made from binary .mgh surface data file:

mri_segstats --i lh.fsaverage.sm10.mgh --seg lh.sign_clust.bin.mgh --excludeid 
0 --sum lh.bin.sum --avgwf lh.wav.bin.txt 

In the output file « lh.bin.sum » all is considered as volume input/output as 
you could see below:

# InVolFileTimeStamp  2016/04/28 09:46:19 
# InVolFrame 0 
# ExcludeSegId 0 
# Only reporting non-empty segmentations
# VoxelVolume_mm3 1 
# TableCol  1 ColHeader Index 
# TableCol  1 FieldName Index 
# TableCol  1 Units NA 
# TableCol  2 ColHeader SegId 
# TableCol  2 FieldName Segmentation Id
# TableCol  2 Units NA
# TableCol  3 ColHeader NVoxels 
# TableCol  3 FieldName Number of Voxels
# TableCol  3 Units unitless
# TableCol  4 ColHeader Volume_mm3
# TableCol  4 FieldName Volume
# TableCol  4 Units mm^3
# TableCol  5 ColHeader Mean 
# TableCol  5 FieldName Intensity Mean
# TableCol  5 Units unknown
# TableCol  6 ColHeader StdDev
# TableCol  6 FieldName Itensity StdDev
# TableCol  6 Units unknown
# TableCol  7 ColHeader Min
# TableCol  7 FieldName Intensity Min
# TableCol  7 Units unknown
# TableCol  8 ColHeader Max
# TableCol  8 FieldName Intensity Max
# TableCol  8 Units unknown
# TableCol  9 ColHeader Range
# TableCol  9 FieldName Intensity Range
# TableCol  9 Units unknown
# NRows 1 
# NTableCols 9 
# ColHeaders  Index SegId NVoxels Volume_mm3 StructName Mean StdDev Min Max 
Range  
  1   1 1151011510.0  Seg0001 7.6819 1.4396 4.4862
10.9042 6.4180 

As my inputs are all surface data could I consider that NVoxels is equal to 
NVertices and Volume_mm3 is equal to SurfaceArea_mm2 ?

Best regards,
Matthieu

> Le 10 nov. 2016 à 23:18, Matthieu Vanhoutte <matthieuvanhou...@gmail.com> a 
> écrit :
> 
> Thank you Douglas !
> 
> 
> Le 10 nov. 2016 7:21 PM, "Douglas N Greve" <gr...@nmr.mgh.harvard.edu 
> <mailto:gr...@nmr.mgh.harvard.edu>> a écrit :
> You need to weight by the number of vertices
> 
> n = [27805 2321 552];
>   m = [8.8194 10.3661 10.3365];
> sum(n.*m)/sum(n)
> 
> ans =
> 
>  8.9637
> 
> 
> On 11/10/2016 06:44 AM, Matthieu Vanhoutte wrote:
> > Dear Freesurfer's experts,
> >
> > Could anyone please explain me the difference I got with command line
> > in below mail ?
> >
> > Best regards,
> > Matthieu
> >
> > 2016-08-12 12:07 GMT+02:00 Matthieu Vanhoutte
> > <matthieuvanhou...@gmail.com <mailto:matthieuvanhou...@gmail.com> 
> > <mailto:matthieuvanhou...@gmail.com <mailto:matthieuvanhou...@gmail.com>>>:
> >
> > Dear experts,
> >
> > I am in trouble with two ways of computing mean intensity with
> > mri_segstats.
> >
> > First I have used on .annot files with three different labels
> > inside (SegId 1 to 3) :
> >
> > /mri_segstats --annot fsaverage lh cache.th23.pos.sig.ocn.annot
> > --i lh.PET.fsaverage.sm10.mgh --sum lh.pet.sum/
> > /
> > /
> > which give me those results:
> > # ColHeaders  Index SegId NVertices Area_mm2 StructName Mean
> > StdDev Min Max Range
> > 1   1 2780514182.6  cluster-001  8.8194 1.4351
> > 6.210514.2947 8.0842
> > 2   2  2321 1047.3  cluster-002 10.3661 1.0848
> > 8.837512.9317 4.0942
> > 3   3   552  313.1  cluster3  10.3365 0.4711
> > 9.371911.8694 2.4975
> >
> > Second I have created on .label files containing the three
> > segmented labels (SegId 1 to 3) and used this label with mri_segstats:
> >
> > /mri_segstats --slabel fsaverage lh
> > lh.th23.cluster.thresh1.3.label --i lh.PET.fsaverage.sm10.mgh
> > --excludeid 0 --sum lh.pet.label.sum /
> > /
> > /
> > which give me those results:/
> > /
> > /# ColHeaders  Index SegId NVertices Area_mm2 StructName Mean
> > StdDev Min Max Range /
> > /  1   1 30678  15542.9  Seg0001 8.9637 1.4701 6.2105
> >  14.2947 8.0842 /
> > /
> > /
> > I verified if I obtained the same results with the two ways
> > (.annot or .label) and everything is fine comparing NVertices,
> > Area_mm2 but Mean in first way gives me (8.8194+10.3661+10.3365)/3
> > = 9.84066 and with .label file Mean = 8.9637.
> >
> > Did I have miss anything and how is computed mean intensity ?
> >
> > Many thanks in advance.
> >
> > Best regards,
> > Matthieu
> >
> >
> >
> >
> > ___
> > Freesurfer

Re: [Freesurfer] Mean intensity with mri_segstats : different results with .annot or .label

[Matthieu Vanhoutte]

Thank you Douglas !

Le 10 nov. 2016 7:21 PM, "Douglas N Greve" <gr...@nmr.mgh.harvard.edu> a
écrit :

> You need to weight by the number of vertices
>
> n = [27805 2321 552];
>   m = [8.8194 10.3661 10.3365];
> sum(n.*m)/sum(n)
>
> ans =
>
>  8.9637
>
>
> On 11/10/2016 06:44 AM, Matthieu Vanhoutte wrote:
> > Dear Freesurfer's experts,
> >
> > Could anyone please explain me the difference I got with command line
> > in below mail ?
> >
> > Best regards,
> > Matthieu
> >
> > 2016-08-12 12:07 GMT+02:00 Matthieu Vanhoutte
> > <matthieuvanhou...@gmail.com <mailto:matthieuvanhou...@gmail.com>>:
> >
> > Dear experts,
> >
> > I am in trouble with two ways of computing mean intensity with
> > mri_segstats.
> >
> > First I have used on .annot files with three different labels
> > inside (SegId 1 to 3) :
> >
> > /mri_segstats --annot fsaverage lh cache.th23.pos.sig.ocn.annot
> > --i lh.PET.fsaverage.sm10.mgh --sum lh.pet.sum/
> > /
> > /
> > which give me those results:
> > # ColHeaders  Index SegId NVertices Area_mm2 StructName Mean
> > StdDev Min Max Range
> > 1   1 2780514182.6  cluster-001  8.8194 1.4351
> > 6.210514.2947 8.0842
> > 2   2  2321 1047.3  cluster-002 10.3661 1.0848
> > 8.837512.9317 4.0942
> > 3   3   552  313.1  cluster3  10.3365 0.4711
> > 9.371911.8694 2.4975
> >
> > Second I have created on .label files containing the three
> > segmented labels (SegId 1 to 3) and used this label with
> mri_segstats:
> >
> > /mri_segstats --slabel fsaverage lh
> > lh.th23.cluster.thresh1.3.label --i lh.PET.fsaverage.sm10.mgh
> > --excludeid 0 --sum lh.pet.label.sum /
> > /
> > /
> > which give me those results:/
> > /
> > /# ColHeaders  Index SegId NVertices Area_mm2 StructName Mean
> > StdDev Min Max Range /
> > /  1   1 30678  15542.9  Seg0001 8.9637 1.4701 6.2105
> >  14.2947 8.0842 /
> > /
> > /
> > I verified if I obtained the same results with the two ways
> > (.annot or .label) and everything is fine comparing NVertices,
> > Area_mm2 but Mean in first way gives me (8.8194+10.3661+10.3365)/3
> > = 9.84066 and with .label file Mean = 8.9637.
> >
> > Did I have miss anything and how is computed mean intensity ?
> >
> > Many thanks in advance.
> >
> > Best regards,
> > Matthieu
> >
> >
> >
> >
> > ___
> > Freesurfer mailing list
> > Freesurfer@nmr.mgh.harvard.edu
> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
> --
> Douglas N. Greve, Ph.D.
> MGH-NMR Center
> gr...@nmr.mgh.harvard.edu
> Phone Number: 617-724-2358
> Fax: 617-726-7422
>
> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
> www.nmr.mgh.harvard.edu/facility/filedrop/index.html
> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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] Mean intensity with mri_segstats : different results with .annot or .label

[Matthieu Vanhoutte]

Dear Freesurfer's experts,

Could anyone please explain me the difference I got with command line in
below mail ?

Best regards,
Matthieu

2016-08-12 12:07 GMT+02:00 Matthieu Vanhoutte <matthieuvanhou...@gmail.com>:

> Dear experts,
>
> I am in trouble with two ways of computing mean intensity with
> mri_segstats.
>
> First I have used on .annot files with three different labels inside
> (SegId 1 to 3) :
>
> *mri_segstats --annot fsaverage lh cache.th23.pos.sig.ocn.annot --i
> lh.PET.fsaverage.sm10.mgh --sum lh.pet.sum*
>
> which give me those results:
> # ColHeaders  Index SegId NVertices Area_mm2 StructName Mean StdDev Min
> Max Range
>   1   1 2780514182.6  cluster-0018.8194
>   1.4351 6.210514.2947 8.0842
>   2   2  2321 1047.3  cluster-002   10.3661
>   1.0848 8.837512.9317 4.0942
>   3   3   552  313.1  cluster3  10.3365
>   0.4711 9.371911.8694 2.4975
>
> Second I have created on .label files containing the three segmented
> labels (SegId 1 to 3) and used this label with mri_segstats:
>
> *mri_segstats --slabel fsaverage lh lh.th23.cluster.thresh1.3.label --i
> lh.PET.fsaverage.sm10.mgh --excludeid 0 --sum lh.pet.label.sum *
>
> which give me those results:
> *# ColHeaders  Index SegId NVertices Area_mm2 StructName Mean StdDev Min
> Max Range  *
> *  1   1 3067815542.9  Seg0001 8.9637 1.4701 6.2105
>  14.2947 8.0842 *
>
> I verified if I obtained the same results with the two ways (.annot or
> .label) and everything is fine comparing NVertices, Area_mm2 but Mean in
> first way gives me (8.8194+10.3661+10.3365)/3 = 9.84066 and with .label
> file Mean = 8.9637.
>
> Did I have miss anything and how is computed mean intensity ?
>
> Many thanks in advance.
>
> Best regards,
> Matthieu
>
___
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] PET/MRI registration failed with bbregister or mri_coreg

[Matthieu Vanhoutte]

Thank you for your diagnosis Douglas. How could I get the voxel sizes right
from input nifti pet and mri data ?

Best regards,
Matthieu

Le 12 oct. 2016 10:05 PM, "Douglas N Greve" <gr...@nmr.mgh.harvard.edu> a
écrit :

> The problem appears to be that the PET or the MRI (or both) have
> incorrect voxel sizes (about 15%). You need to fix the problem. You can
> get a decent registration using something like
>
> mri_coreg --mov BS7_PET.lps.nii.gz --s 207118_FS_Filedrop --reg
> dof9.wb.lta --dof 9 --no-ref-mask --ref mri/orig.mgz
>
> with 9 DOF instead of 6 to account for the scaling (voxel size error).
> But it is *much* better to get the voxel sizes right and use 6 dof
>
>
> On 10/06/2016 02:50 PM, Matthieu Vanhoutte wrote:
> >
> > Hi Douglas,
> >
> > Dis you have time to take a look at ?
> >
> > Best regards,
> > Matthieu
> >
> >
> > Le 3 oct. 2016 6:25 PM, "Matthieu Vanhoutte"
> > <matthieuvanhou...@gmail.com <mailto:matthieuvanhou...@gmail.com>> a
> > écrit :
> >
> > Hi Douglas,
> >
> > I have just sent it to you on Filedrop.
> >
> > Best regards,
> > Matthieu
> >
> > 2016-10-03 17:45 GMT+02:00 Douglas Greve
> > <gr...@nmr.mgh.harvard.edu <mailto:gr...@nmr.mgh.harvard.edu>>:
> >
> > Can you tar up the FS anat analysis and BS7_PET.lps.nii.gz and
> > send it to me on our filedrop?
> >
> >
> > On 10/3/16 6:55 AM, Matthieu Vanhoutte wrote:
> >> Hi Douglas,
> >>
> >> Please find below the mri_coreg terminal output :
> >> /
> >> /
> >> /$Id: mri_coreg.c,v 1.27 2016/04/30 15:11:49 greve Exp $/
> >> /cwd /NAS/tupac/matthieu/FS5.3/207118_M0_2014-01-29/pet/
> >> /cmdline mri_coreg --s 207118_M0_2014-01-29 --mov
> >> BS7_PET.lps.nii.gz --reg
> >> Pet2T1.BS7.register.dof6.mri_coreg.lta --regdat
> >> Pet2T1.BS7.register.dof6.mri_coreg.dat /
> >> /sysname  Linux/
> >> /hostname yakuza/
> >> /machine  x86_64/
> >> /user matthieu/
> >> /dof6/
> >> /nsep2/
> >> /cras01/
> >> /ftol0.00/
> >> /linmintol0.001000/
> >> /bf   1/
> >> /bflim30.00/
> >> /bfnsamp30/
> >> /SmoothRef 0/
> >> /SatPct99.99/
> >> /MovOOB 0/
> >> /optschema 1/
> >> /Reading in mov BS7_PET.lps.nii.gz/
> >> /Reading in ref
> >> /NAS/tupac/matthieu/FS5.3//207118_M0_2014-01-29/mri/
> brainmask.mgz/
> >> /Reading in and applying refmask
> >> /NAS/tupac/matthieu/FS5.3//207118_M0_2014-01-29/mri/
> aparc+aseg.mgz/
> >> /Setting cras translation parameters to align centers/
> >> /Creating random numbers for coordinate dithering/
> >> /Performing intensity dithering/
> >> /Initial parameters 20.9141 11.8161 149.1538  0.  0.
> >>  0.  1.  1.  1.  0.  0.  0. /
> >> /Separation list (2):  4  2   min = 2/
> >> /DoSmoothing 1/
> >> /DoCoordDither 1/
> >> /DoIntensityDither 1/
> >> /nitersmax 4/
> >> /ftol 1.000e-07/
> >> /linmintol 1.000e-03/
> >> /SatPct 99.99/
> >> /Hist FWHM 7.00 7.00/
> >> /nthreads 1/
> >> /movsat = 10897.7666/
> >> /mov gstd 0.8459 0.8459 0.8459/
> >> /Smoothing mov/
> >> /refsat = 119./
> >> /ref gstd 0.8459 0.8459 0.8459/
> >> /Smoothing ref/
> >> /COREGpreproc() done/
> >> /Testing if mov and target overlap/
> >> /Init cost   -1.0011578057/
> >> /nhits = 262144 out of 16777216, Percent Overlap: 100.0/
> >> /Initial  RefRAS-to-MovRAS/
> >> / 1.0   0.0   0.0 20.91408;/
> >> / 0.0   1.0   0.0 11.81612;/
> >> / 0.0   0.0   1.0 149.15384;/
> >> / 0.0   0.0   0.0 1.0;/
> >> /Initial  RefVox-to-MovVox/
> >> / 1.0   0.0   0.0 0.0;/
> >> / 0.0   0.0  -1.0 255.0;/

Re: [Freesurfer] PET/MRI registration failed with bbregister or mri_coreg

[Matthieu Vanhoutte]

Hi Douglas,

Dis you have time to take a look at ?

Best regards,
Matthieu

Le 3 oct. 2016 6:25 PM, "Matthieu Vanhoutte" <matthieuvanhou...@gmail.com>
a écrit :

> Hi Douglas,
>
> I have just sent it to you on Filedrop.
>
> Best regards,
> Matthieu
>
> 2016-10-03 17:45 GMT+02:00 Douglas Greve <gr...@nmr.mgh.harvard.edu>:
>
>> Can you tar up the FS anat analysis and BS7_PET.lps.nii.gz and send it to
>> me on our filedrop?
>>
>> On 10/3/16 6:55 AM, Matthieu Vanhoutte wrote:
>>
>> Hi Douglas,
>>
>> Please find below the mri_coreg terminal output :
>>
>> *$Id: mri_coreg.c,v 1.27 2016/04/30 15:11:49 greve Exp $*
>> *cwd /NAS/tupac/matthieu/FS5.3/207118_M0_2014-01-29/pet*
>> *cmdline mri_coreg --s 207118_M0_2014-01-29 --mov BS7_PET.lps.nii.gz
>> --reg Pet2T1.BS7.register.dof6.mri_coreg.lta --regdat
>> Pet2T1.BS7.register.dof6.mri_coreg.dat *
>> *sysname  Linux*
>> *hostname yakuza*
>> *machine  x86_64*
>> *user matthieu*
>> *dof6*
>> *nsep2*
>> *cras01*
>> *ftol0.00*
>> *linmintol0.001000*
>> *bf   1*
>> *bflim30.00*
>> *bfnsamp30*
>> *SmoothRef 0*
>> *SatPct99.99*
>> *MovOOB 0*
>> *optschema 1*
>> *Reading in mov BS7_PET.lps.nii.gz*
>> *Reading in ref
>> /NAS/tupac/matthieu/FS5.3//207118_M0_2014-01-29/mri/brainmask.mgz*
>> *Reading in and applying refmask
>> /NAS/tupac/matthieu/FS5.3//207118_M0_2014-01-29/mri/aparc+aseg.mgz*
>> *Setting cras translation parameters to align centers*
>> *Creating random numbers for coordinate dithering*
>> *Performing intensity dithering*
>> *Initial parameters 20.9141 11.8161 149.1538  0.  0.  0.
>>  1.  1.  1.  0.  0.  0. *
>> *Separation list (2):  4  2   min = 2*
>> *DoSmoothing 1*
>> *DoCoordDither 1*
>> *DoIntensityDither 1*
>> *nitersmax 4*
>> *ftol 1.000e-07*
>> *linmintol 1.000e-03*
>> *SatPct 99.99*
>> *Hist FWHM 7.00 7.00*
>> *nthreads 1*
>> *movsat = 10897.7666*
>> *mov gstd 0.8459 0.8459 0.8459*
>> *Smoothing mov*
>> *refsat = 119.*
>> *ref gstd 0.8459 0.8459 0.8459*
>> *Smoothing ref*
>> *COREGpreproc() done*
>> *Testing if mov and target overlap*
>> *Init cost   -1.0011578057*
>> *nhits = 262144 out of 16777216, Percent Overlap: 100.0*
>> *Initial  RefRAS-to-MovRAS*
>> * 1.0   0.0   0.0   20.91408;*
>> * 0.0   1.0   0.0   11.81612;*
>> * 0.0   0.0   1.0   149.15384;*
>> * 0.0   0.0   0.0   1.0;*
>> *Initial  RefVox-to-MovVox*
>> * 1.0   0.0   0.0   0.0;*
>> * 0.0   0.0  -1.0   255.0;*
>> * 0.0  -1.0   0.0   255.0;*
>> * 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   4.91408  21.81612 119.15384
>> 2.0   0.0   0.0   -1.0078773*
>> *Turning  MovOOB back off after brute force search*
>>
>>
>> *-*
>> *Init Powel Params dof = 6*
>> *Starting OpenPowel2(), sep = 4*
>> *InitialCost-1.0076701641 *
>> *#@#  4  188  4.91408 21.81612 119.15384 2.0 0.0 0.0
>> -1.0076702*
>> *fs_powell::minimize*
>> *  nparams 6*
>> *  maxfev 4*
>> *  ftol   0.00*
>> *  linmin_xtol_   0.001000*
>> *  powell nthiter 0: fret = -1.007670*
>> *#@#  4  197  4.93866 21.81612 119.15384 2.0 0.0 0.0
>> -1.0076704*
>> *#@#  4  198  4.96905 21.81612 119.15384 2.0 0.0 0.0
>> -1.0076705*
>> *#@#  4  209  4.97536 20.19808 119.15384 2.0 0.0 0.0
>> -1.0077189*
>> *#@#  4  210  4.97536 19.55424 119.15384 2.0 0.0 0.0
>> -1.0077529*
>> *#@#  4  211  4.97536 18.51247 119.15384 2.0 0.0 0.0
>> -1.0078081*
>> *#@#  4  212  4.97536 16.82685 119.15384 2.0 0.0 0.0
>> -1.0078434*
>> *#@#  4  213  4.97536 16.77889 119.15384 2.0 0.0 0.0
>> -1.0078460*
>> *#@#  4  214  4.97536 16.70129 119.15384 2.0 0.0 0.0
>> -1.0078515*
>> *#@#  4  215  4.97536 16.57572 119.15384 2.0 0.0 0.0
>> -1.0078617*
>> *#@#  4  216  4.97536 16.37254 119.15384 2.0 0.0 0.0
>> -1.0078768*
>> *#@#  4  217  4.97536 14.89926 119.15384 2.0 0.0 0.0
>> -1.0079292*
>> *#@#  4  21

Re: [Freesurfer] PET/MRI registration failed with bbregister or mri_coreg

[Matthieu Vanhoutte]

Hi Douglas,

I have just sent it to you on Filedrop.

Best regards,
Matthieu

2016-10-03 17:45 GMT+02:00 Douglas Greve <gr...@nmr.mgh.harvard.edu>:

> Can you tar up the FS anat analysis and BS7_PET.lps.nii.gz and send it to
> me on our filedrop?
>
> On 10/3/16 6:55 AM, Matthieu Vanhoutte wrote:
>
> Hi Douglas,
>
> Please find below the mri_coreg terminal output :
>
> *$Id: mri_coreg.c,v 1.27 2016/04/30 15:11:49 greve Exp $*
> *cwd /NAS/tupac/matthieu/FS5.3/207118_M0_2014-01-29/pet*
> *cmdline mri_coreg --s 207118_M0_2014-01-29 --mov BS7_PET.lps.nii.gz --reg
> Pet2T1.BS7.register.dof6.mri_coreg.lta --regdat
> Pet2T1.BS7.register.dof6.mri_coreg.dat *
> *sysname  Linux*
> *hostname yakuza*
> *machine  x86_64*
> *user matthieu*
> *dof6*
> *nsep2*
> *cras01*
> *ftol0.00*
> *linmintol0.001000*
> *bf   1*
> *bflim30.00*
> *bfnsamp30*
> *SmoothRef 0*
> *SatPct99.99*
> *MovOOB 0*
> *optschema 1*
> *Reading in mov BS7_PET.lps.nii.gz*
> *Reading in ref
> /NAS/tupac/matthieu/FS5.3//207118_M0_2014-01-29/mri/brainmask.mgz*
> *Reading in and applying refmask
> /NAS/tupac/matthieu/FS5.3//207118_M0_2014-01-29/mri/aparc+aseg.mgz*
> *Setting cras translation parameters to align centers*
> *Creating random numbers for coordinate dithering*
> *Performing intensity dithering*
> *Initial parameters 20.9141 11.8161 149.1538  0.  0.  0.
>  1.  1.  1.  0.  0.  0. *
> *Separation list (2):  4  2   min = 2*
> *DoSmoothing 1*
> *DoCoordDither 1*
> *DoIntensityDither 1*
> *nitersmax 4*
> *ftol 1.000e-07*
> *linmintol 1.000e-03*
> *SatPct 99.99*
> *Hist FWHM 7.00 7.00*
> *nthreads 1*
> *movsat = 10897.7666*
> *mov gstd 0.8459 0.8459 0.8459*
> *Smoothing mov*
> *refsat = 119.*
> *ref gstd 0.8459 0.8459 0.8459*
> *Smoothing ref*
> *COREGpreproc() done*
> *Testing if mov and target overlap*
> *Init cost   -1.0011578057*
> *nhits = 262144 out of 16777216, Percent Overlap: 100.0*
> *Initial  RefRAS-to-MovRAS*
> * 1.0   0.0   0.0   20.91408;*
> * 0.0   1.0   0.0   11.81612;*
> * 0.0   0.0   1.0   149.15384;*
> * 0.0   0.0   0.0   1.0;*
> *Initial  RefVox-to-MovVox*
> * 1.0   0.0   0.0   0.0;*
> * 0.0   0.0  -1.0   255.0;*
> * 0.0  -1.0   0.0   255.0;*
> * 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   4.91408  21.81612 119.15384
> 2.0   0.0   0.0   -1.0078773*
> *Turning  MovOOB back off after brute force search*
>
>
> *-*
> *Init Powel Params dof = 6*
> *Starting OpenPowel2(), sep = 4*
> *InitialCost-1.0076701641 *
> *#@#  4  188  4.91408 21.81612 119.15384 2.0 0.0 0.0
> -1.0076702*
> *fs_powell::minimize*
> *  nparams 6*
> *  maxfev 4*
> *  ftol   0.00*
> *  linmin_xtol_   0.001000*
> *  powell nthiter 0: fret = -1.007670*
> *#@#  4  197  4.93866 21.81612 119.15384 2.0 0.0 0.0
> -1.0076704*
> *#@#  4  198  4.96905 21.81612 119.15384 2.0 0.0 0.0
> -1.0076705*
> *#@#  4  209  4.97536 20.19808 119.15384 2.0 0.0 0.0
> -1.0077189*
> *#@#  4  210  4.97536 19.55424 119.15384 2.0 0.0 0.0
> -1.0077529*
> *#@#  4  211  4.97536 18.51247 119.15384 2.0 0.0 0.0
> -1.0078081*
> *#@#  4  212  4.97536 16.82685 119.15384 2.0 0.0 0.0
> -1.0078434*
> *#@#  4  213  4.97536 16.77889 119.15384 2.0 0.0 0.0
> -1.0078460*
> *#@#  4  214  4.97536 16.70129 119.15384 2.0 0.0 0.0
> -1.0078515*
> *#@#  4  215  4.97536 16.57572 119.15384 2.0 0.0 0.0
> -1.0078617*
> *#@#  4  216  4.97536 16.37254 119.15384 2.0 0.0 0.0
> -1.0078768*
> *#@#  4  217  4.97536 14.89926 119.15384 2.0 0.0 0.0
> -1.0079292*
> *#@#  4  218  4.97536 14.85724 119.15384 2.0 0.0 0.0
> -1.0079303*
> *#@#  4  219  4.97536 12.95773 119.15384 2.0 0.0 0.0
> -1.0079467*
> *#@#  4  220  4.97536 13.40911 119.15384 2.0 0.0 0.0
> -1.0079498*
> *#@#  4  223  4.97536 13.62039 119.15384 2.0 0.0 0.0
> -1.0079516*
> *#@#  4  229  4.97536 13.61634 117.53580 2.0 0.0 0.0
> -1.0086172*
> *#@#  4  230  4.97536 13.61634 80.23408 2.0 0.0 0.0
> -1.0266197*
> *#@#  4  235  4.97536 13.61634 69.09492 2.0 0.0 0.0
> -1.0285894*
> *#@#  4  236  4.97536 13.61634 69.00322 2.0 0.0 0.0
> -1.0285

Re: [Freesurfer] PET/MRI registration failed with bbregister or mri_coreg

[Matthieu Vanhoutte]

 -0.13577
-1.0287210*
*#@#  2  657  3.09369 15.04550 68.21119 7.08699 0.02114 0.86423
-1.0287254*
*  powell nthiter 1: fret = -1.028725*
*#@#  2  681  3.12473 15.04550 68.21119 7.08699 0.02114 0.95289
-1.0287255*
*#@#  2  695  3.12664 15.42746 68.21119 7.08699 0.02114 0.95289
-1.0287271*
*#@#  2  696  3.12664 15.34841 68.21119 7.08699 0.02114 0.95289
-1.0287273*
*#@#  2  720  3.12664 15.32519 68.20757 7.08297 0.02114 0.95289
-1.0287274*
*#@#  2  724  3.12664 15.32519 68.20757 7.07547 0.02114 0.95289
-1.0287275*
*#@#  2  745  3.12664 15.32519 68.20757 7.07447 0.01759 0.81959
-1.0287278*
*#@#  2  762  3.14700 15.49804 68.20535 7.06672 0.01540 0.72493
-1.0287280*
*  powell nthiter 2: fret = -1.028728*
*#@#  2  792  3.14765 15.49494 68.20538 7.06686 0.01544 0.59641
-1.0287281*
*#@#  2  803  3.14765 15.49494 68.11650 7.06686 0.01544 0.59810
-1.0287282*
*#@#  2  804  3.14765 15.49494 68.14099 7.06686 0.01544 0.59810
-1.0287284*
*#@#  2  805  3.14765 15.49494 68.15399 7.06686 0.01544 0.59810
-1.0287285*
*#@#  2  807  3.14765 15.49494 68.16380 7.06686 0.01544 0.59810
-1.0287286*
*  powell nthiter 3: fret = -1.028729*
*#@#  2  867  3.12259 15.49539 68.16066 7.07157 0.0 0.59788
-1.0287287*
*Powell done niters total = 4*
*OptTimeSec 161.2 sec*
*OptTimeMin  2.69 min*
*nEvals 938*
*Final parameters   3.12265301  15.49595165  68.16065216   7.06536150
0.01209922   0.59759676 *
*Final cost   -1.028728664232616*


*-*
*mri_coreg utimesec241.181825*
*mri_coreg stimesec0.360032*
*mri_coreg ru_maxrss   504732*
*mri_coreg ru_ixrss0*
*mri_coreg ru_idrss0*
*mri_coreg ru_isrss0*
*mri_coreg ru_minflt   381121*
*mri_coreg ru_majflt   0*
*mri_coreg ru_nswap0*
*mri_coreg ru_inblock  71512*
*mri_coreg ru_oublock  16*
*mri_coreg ru_msgsnd   0*
*mri_coreg ru_msgrcv   0*
*mri_coreg ru_nsignals 0*
*mri_coreg ru_nvcsw505*
*mri_coreg ru_nivcsw   28383*
*Final  RefRAS-to-MovRAS*
* 0.5   0.01043   0.00021   3.12265;*
*-0.01038   0.99235   0.12300   15.49595;*
* 0.00107  -0.12300   0.99241   68.16065;*
* 0.0   0.0   0.0   1.0;*
*Final  RefVox-to-MovVox*
* 0.5   0.00021  -0.01043   19.00880;*
*-0.01038   0.12300  -0.99235   243.54027;*
*-0.00107  -0.99241  -0.12300   188.07765;*
* 0.0   0.0   0.0   1.0;*
*Final parameters  3.1227 15.4960 68.1607  7.0654  0.0121  0.5976 *
*nhits = 1287172 out of 16777216, Percent Overlap:  61.4*
*mri_coreg RunTimeSec 241.7 sec*
*To check run:*
*   tkregisterfv --mov BS7_PET.lps.nii.gz --targ
/NAS/tupac/matthieu/FS5.3//207118_M0_2014-01-29/mri/brainmask.mgz --reg
Pet2T1.BS7.register.dof6.mri_coreg.lta --s 207118_M0_2014-01-29 --surfs *

*mri_coreg done*


Best regards,
Matthieu

2016-09-30 21:07 GMT+02:00 Douglas N Greve <gr...@nmr.mgh.harvard.edu>:

> Can you send the mri_coreg terminal output?
>
>
> On 09/29/2016 11:19 AM, Matthieu Vanhoutte wrote:
> > Dear Freesurfer's experts,
> >
> > I would like to register PET image onto T1 anatomical. I used
> > bbregister with the following command and it failed :
> > /bbregister  --s SUBJID --init-fsl --t2 --mov PET.nii.gz --reg
> > Pet2T1.register.dof6.dat --lta Pet2T1.register.dof6.lta --init-reg-out
> > Pet2T1.init.register.dof6.dat --o rPET.nii.gz /
> > /
> > /
> > Having heard about mri_coreg solving some bbregister fails, I tested
> > it with the following command :
> > /mri_coreg --s SUBJID  --mov PET.nii.gz --reg
> > Pet2T1.register.dof6.mri_coreg.lta --regdat
> > Pet2T1.register.dof6.mri_coreg.dat/
> > /
> > /
> > But it failed in the same way than bbregister. Do you have any advice
> > on this problem ?
> >
> > Best regards,
> > Matthieu
> >
> >
> > ___
> > Freesurfer mailing list
> > Freesurfer@nmr.mgh.harvard.edu
> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
> --
> Douglas N. Greve, Ph.D.
> MGH-NMR Center
> gr...@nmr.mgh.harvard.edu
> Phone Number: 617-724-2358
> Fax: 617-726-7422
>
> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
> www.nmr.mgh.harvard.edu/facility/filedrop/index.html
> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does no

Re: [Freesurfer] Longitudinal surface analysis of PET data

[Matthieu Vanhoutte]

Hi Douglas,

Does the surface of the closest MRI time point mean the surface of the
-long subject time point directory rather than cross-sectional subject time
point directory ?

Best regards,
Matthieu

Le 30 sept. 2016 9:14 PM, "Douglas N Greve" <gr...@nmr.mgh.harvard.edu> a
écrit :

> There is no such long process for PET. The idea is that you process the
> MRI in a longitudinal way, then sample the PET data onto the surface of
> the closest MRI time point. Then proceed in a way similar to the
> thickness analysis
>
>
> On 09/29/2016 11:08 AM, Matthieu Vanhoutte wrote:
> > Dear Freesurfer's experts,
> >
> > Could you answer me about my last question with no response in the
> > mail below ?
> >
> > When using cortical thickness in longitudinal analysis with LME, we
> > used lh.thickness or rh.thickness from -long subject directories.
> > These data followed particular processing steps including
> > registrations in order to use them with more precision in longitudinal
> > studies, didn't they ?
> >
> > My problem is that I would like to perform longitudinal study on PET
> > data images with LME. So I wonder if I just have to resample onto
> > -long cortical subject surface ? Do I need to follow the same steps
> > than cortical thickness from cross-sectional to -long subject
> > directories ? If this is the case, which commands should I use to
> > mimic cortical thickness longitudinal data ?
> >
> > Many thanks in advance for helping !
> >
> > Best regards,
> > Matthieu
> >
> > 2016-09-18 23:02 GMT+02:00 Matthieu Vanhoutte
> > <matthieuvanhou...@gmail.com <mailto:matthieuvanhou...@gmail.com>>:
> >
> > Hi Martin,
> >
> > Thanks for your answer. However, it seems to me that cortical
> > thickness follow a particular process with the recon-all -long
> > process, isn’t it ? Is there any resample onto average time
> > subject then other operation following ?
> >
> > Best regards,
> > Matthieu
> >
> > > Le 18 sept. 2016 à 16:26, Martin Reuter
> > <mreu...@nmr.mgh.harvard.edu <mailto:mreu...@nmr.mgh.harvard.edu>>
> > a écrit :
> > >
> > > Hi Matthieu,
> > >
> > > I never used PET data, but once you manage to resample you pet
> > data onto the surface, you will have a file similar to the
> > thickness file for each subjects. Instead of thickness it holds
> > you PET information. From that point on everything should be
> > identical to the thickness analysis.
> > >
> > > So this is really more a question how to get your PET data
> > sampled onto the surface. If no one else replies, write that into
> > the subject line and repost.
> > >
> > > Best, Martin
> > >
> > >
> > >> On Sep 17, 2016, at 7:37 AM, Matthieu Vanhoutte
> > <matthieuvanhou...@gmail.com <mailto:matthieuvanhou...@gmail.com>>
> > wrote:
> > >>
> > >> Dear Freesurfer’s experts,
> > >>
> > >> I would like to use the longitudinal mixed-effects model for
> > surface PET analysis. Although I could find all the process to
> > follow the longitudinal analysis of cortical thickness, I couldn’t
> > resolve the steps/commands to apply successively to coregistered
> > PET data on T1 MRI.
> > >>
> > >> Could you precise me the process and commands to use for PET
> > longitudinal analysis ?
> > >>
> > >> Many thanks in advance !
> > >>
> > >> Best regards,
> > >> Matthieu
> > >> ___
> > >> Freesurfer mailing list
> > >> Freesurfer@nmr.mgh.harvard.edu
> > <mailto:Freesurfer@nmr.mgh.harvard.edu>
> > >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> > <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
> > <https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer>
> > >
> > >
> 

[Freesurfer] PET/MRI registration failed with bbregister or mri_coreg

[Matthieu Vanhoutte]

Dear Freesurfer's experts,

I would like to register PET image onto T1 anatomical. I used bbregister
with the following command and it failed :
*bbregister  --s SUBJID --init-fsl --t2 --mov PET.nii.gz --reg
Pet2T1.register.dof6.dat --lta Pet2T1.register.dof6.lta --init-reg-out
Pet2T1.init.register.dof6.dat --o rPET.nii.gz *

Having heard about mri_coreg solving some bbregister fails, I tested it
with the following command :
*mri_coreg --s SUBJID  --mov PET.nii.gz --reg
Pet2T1.register.dof6.mri_coreg.lta --regdat
Pet2T1.register.dof6.mri_coreg.dat*

But it failed in the same way than bbregister. Do you have any advice on
this problem ?

Best regards,
Matthieu
___
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] Longitudinal surface analysis of PET data

[Matthieu Vanhoutte]

Dear Freesurfer's experts,

Could you answer me about my last question with no response in the mail
below ?

When using cortical thickness in longitudinal analysis with LME, we used
lh.thickness or rh.thickness from -long subject directories. These data
followed particular processing steps including registrations in order to
use them with more precision in longitudinal studies, didn't they ?

My problem is that I would like to perform longitudinal study on PET data
images with LME. So I wonder if I just have to resample onto -long cortical
subject surface ? Do I need to follow the same steps than cortical
thickness from cross-sectional to -long subject directories ? If this is
the case, which commands should I use to mimic cortical thickness
longitudinal data ?

Many thanks in advance for helping !

Best regards,
Matthieu

2016-09-18 23:02 GMT+02:00 Matthieu Vanhoutte <matthieuvanhou...@gmail.com>:

> Hi Martin,
>
> Thanks for your answer. However, it seems to me that cortical thickness
> follow a particular process with the recon-all -long process, isn’t it ? Is
> there any resample onto average time subject then other operation following
> ?
>
> Best regards,
> Matthieu
>
> > Le 18 sept. 2016 à 16:26, Martin Reuter <mreu...@nmr.mgh.harvard.edu> a
> écrit :
> >
> > Hi Matthieu,
> >
> > I never used PET data, but once you manage to resample you pet data onto
> the surface, you will have a file similar to the thickness file for each
> subjects. Instead of thickness it holds you PET information. From that
> point on everything should be identical to the thickness analysis.
> >
> > So this is really more a question how to get your PET data sampled onto
> the surface. If no one else replies, write that into the subject line and
> repost.
> >
> > Best, Martin
> >
> >
> >> On Sep 17, 2016, at 7:37 AM, Matthieu Vanhoutte <
> matthieuvanhou...@gmail.com> wrote:
> >>
> >> Dear Freesurfer’s experts,
> >>
> >> I would like to use the longitudinal mixed-effects model for surface
> PET analysis. Although I could find all the process to follow the
> longitudinal analysis of cortical thickness, I couldn’t resolve the
> steps/commands to apply successively to coregistered PET data on T1 MRI.
> >>
> >> Could you precise me the process and commands to use for PET
> longitudinal analysis ?
> >>
> >> Many thanks in advance !
> >>
> >> Best regards,
> >> Matthieu
> >> ___
> >> Freesurfer mailing list
> >> Freesurfer@nmr.mgh.harvard.edu
> >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> >>
> >>
> >
> >
> > ___
> > Freesurfer mailing list
> > Freesurfer@nmr.mgh.harvard.edu
> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> >
> >
> > The information in this e-mail is intended only for the person to whom
> it is
> > addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> > contains patient information, please contact the Partners Compliance
> HelpLine at
> > http://www.partners.org/complianceline . If the e-mail was sent to you
> in error
> > but does not contain patient information, please contact the sender and
> properly
> > dispose of the e-mail.
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


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] Longitudinal surface analysis of PET data

[Matthieu Vanhoutte]

Hi Martin,

Thanks for your answer. However, it seems to me that cortical thickness follow 
a particular process with the recon-all -long process, isn’t it ? Is there any 
resample onto average time subject then other operation following ?

Best regards,
Matthieu

> Le 18 sept. 2016 à 16:26, Martin Reuter <mreu...@nmr.mgh.harvard.edu> a écrit 
> :
> 
> Hi Matthieu,
> 
> I never used PET data, but once you manage to resample you pet data onto the 
> surface, you will have a file similar to the thickness file for each 
> subjects. Instead of thickness it holds you PET information. From that point 
> on everything should be identical to the thickness analysis.
> 
> So this is really more a question how to get your PET data sampled onto the 
> surface. If no one else replies, write that into the subject line and repost. 
> 
> Best, Martin
> 
> 
>> On Sep 17, 2016, at 7:37 AM, Matthieu Vanhoutte 
>> <matthieuvanhou...@gmail.com> wrote:
>> 
>> Dear Freesurfer’s experts,
>> 
>> I would like to use the longitudinal mixed-effects model for surface PET 
>> analysis. Although I could find all the process to follow the longitudinal 
>> analysis of cortical thickness, I couldn’t resolve the steps/commands to 
>> apply successively to coregistered PET data on T1 MRI.
>> 
>> Could you precise me the process and commands to use for PET longitudinal 
>> analysis ?
>> 
>> Many thanks in advance !
>> 
>> Best regards,
>> Matthieu
>> ___
>> Freesurfer mailing list
>> Freesurfer@nmr.mgh.harvard.edu
>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>> 
>> 
> 
> 
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> 
> 
> The information in this e-mail is intended only for the person to whom it is
> addressed. If you believe this e-mail was sent to you in error and the e-mail
> contains patient information, please contact the Partners Compliance HelpLine 
> at
> http://www.partners.org/complianceline . If the e-mail was sent to you in 
> error
> but does not contain patient information, please contact the sender and 
> properly
> dispose of the e-mail.


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

Re: [Freesurfer] Mean intensity with mri_segstats : different results with .annot or .label

[Matthieu Vanhoutte]

Hello FS's experts,

Would anyone have an advice for my problem ?

Best regards,
Matthieu

2016-08-12 12:07 GMT+02:00 Matthieu Vanhoutte <matthieuvanhou...@gmail.com>:

> Dear experts,
>
> I am in trouble with two ways of computing mean intensity with
> mri_segstats.
>
> First I have used on .annot files with three different labels inside
> (SegId 1 to 3) :
>
> *mri_segstats --annot fsaverage lh cache.th23.pos.sig.ocn.annot --i
> lh.PET.fsaverage.sm10.mgh --sum lh.pet.sum*
>
> which give me those results:
> # ColHeaders  Index SegId NVertices Area_mm2 StructName Mean StdDev Min
> Max Range
>   1   1 2780514182.6  cluster-0018.8194
>   1.4351 6.210514.2947 8.0842
>   2   2  2321 1047.3  cluster-002   10.3661
>   1.0848 8.837512.9317 4.0942
>   3   3   552  313.1  cluster3  10.3365
>   0.4711 9.371911.8694 2.4975
>
> Second I have created on .label files containing the three segmented
> labels (SegId 1 to 3) and used this label with mri_segstats:
>
> *mri_segstats --slabel fsaverage lh lh.th23.cluster.thresh1.3.label --i
> lh.PET.fsaverage.sm10.mgh --excludeid 0 --sum lh.pet.label.sum *
>
> which give me those results:
> *# ColHeaders  Index SegId NVertices Area_mm2 StructName Mean StdDev Min
> Max Range  *
> *  1   1 3067815542.9  Seg0001 8.9637 1.4701 6.2105
>  14.2947 8.0842 *
>
> I verified if I obtained the same results with the two ways (.annot or
> .label) and everything is fine comparing NVertices, Area_mm2 but Mean in
> first way gives me (8.8194+10.3661+10.3365)/3 = 9.84066 and with .label
> file Mean = 8.9637.
>
> Did I have miss anything and how is computed mean intensity ?
>
> Many thanks in advance.
>
> Best regards,
> Matthieu
>
___
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] Mean intensity with mri_segstats : different results with .annot or .label

[Matthieu Vanhoutte]

Dear experts,

I am in trouble with two ways of computing mean intensity with mri_segstats.

First I have used on .annot files with three different labels inside (SegId
1 to 3) :

*mri_segstats --annot fsaverage lh cache.th23.pos.sig.ocn.annot --i
lh.PET.fsaverage.sm10.mgh --sum lh.pet.sum*

which give me those results:
# ColHeaders  Index SegId NVertices Area_mm2 StructName Mean StdDev Min Max
Range
  1   1 2780514182.6  cluster-0018.8194
1.4351 6.210514.2947 8.0842
  2   2  2321 1047.3  cluster-002   10.3661
1.0848 8.837512.9317 4.0942
  3   3   552  313.1  cluster3  10.3365
0.4711 9.371911.8694 2.4975

Second I have created on .label files containing the three segmented labels
(SegId 1 to 3) and used this label with mri_segstats:

*mri_segstats --slabel fsaverage lh lh.th23.cluster.thresh1.3.label --i
lh.PET.fsaverage.sm10.mgh --excludeid 0 --sum lh.pet.label.sum *

which give me those results:
*# ColHeaders  Index SegId NVertices Area_mm2 StructName Mean StdDev Min
Max Range  *
*  1   1 3067815542.9  Seg0001 8.9637 1.4701 6.2105
 14.2947 8.0842 *

I verified if I obtained the same results with the two ways (.annot or
.label) and everything is fine comparing NVertices, Area_mm2 but Mean in
first way gives me (8.8194+10.3661+10.3365)/3 = 9.84066 and with .label
file Mean = 8.9637.

Did I have miss anything and how is computed mean intensity ?

Many thanks in advance.

Best regards,
Matthieu
___
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.