[Freesurfer] What exactly are the BA_exvivo.thresh label and annotation files?

2021-02-18 Thread julienbesle
External Email - Use Caution

Hello,

The ex-vivo BA label and annotation files named 
?h.BA??_exvivo.thresh.label and BA_exvivo.thresh.annot seem to be 
thresholded versions of the corresponding probabilistic BA labels. Was a 
simple threshold on the probability used and if yes, what was the value?

In addition the annotation files, whether thresholded or not, only have 
one label per vertex. Are the labels based on the maximum probability 
across all BA labels?

Thanks

Julien

-- 
--
Julien Besle
Assistant Professor
Department of Psychology
Faculty of Arts and Sciences
American University of Beirut
Riad El-Solh / Beirut 1107 2020
Lebanon

Jesup Hall, Room 103E
Tel: +961 1 350 000 ext. 4927
-


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


[Freesurfer] convert BA probability labels to volume

2021-02-17 Thread julienbesle
External Email - Use Caution

Hello,

I'm trying to convert label files containing probability values for 
Brodmann areas (e.g. rh.BA1_exvivo.label) to volume files using 
mri_label2vol.

I'd like to keep the probability value that's in the 5th column of the 
label file into the volume, but mri_label2vol sets all voxels in the 
label to 1 (i.e. creates a mask). Is there a way to do this?

Thanks

Julien

-- 
--
Julien Besle
Assistant Professor
Department of Psychology
Faculty of Arts and Sciences
American University of Beirut
Riad El-Solh / Beirut 1107 2020
Lebanon

Jesup Hall, Room 103E
Tel: +961 1 350 000 ext. 4927
-


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


Re: [Freesurfer] MGN and LGN in ThalamicNuclei segmentation

2020-06-16 Thread julienbesle
External Email - Use Caution

Thanks Juan.

Nevermind. It turns out that I was comparing a discrete segmentation 
done with v10 (Freesurfer v6 or older) with posterior probability maps 
obtained using v12 (Freesurfer 7.0) in the same subject.

The locations of the MGN and LGN segmentations have moved inferiorly in 
v12 compared to v10, but they match between the segmentation and the 
posterior probability maps in when using the same version, as they 
should. Other nuclei don't seem to have changed too much between v10 and 
v12.

Thanks again!

Julien



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


[Freesurfer] MGN and LGN in ThalamicNuclei segmentation

2020-06-16 Thread julienbesle
External Email - Use Caution

Hello,

I'm interested in locating the MGN and LGN using 
segmentationThalamicNuclei, but there is a mismatch between their 
location in the discrete segmentation (ThalamicNuclei.v10.T1.mgz) and 
the underlying  probability maps obtained by setting environment 
variable WRITE_POSTERIORS to 1. While the LGN in the segmentation has 
many voxels within the corresponding area of maximum probability, many 
high-probability voxels are missing from it. For the MGN, the 
segmentation volume is restricted to a small number of voxels in the 
most lateral/posterior/superior part of the area of max probability, but 
most high-probability voxels are absent from the segmentation. Any 
reason why this could be happening? Is there anything I can do 
(parameters I can change in the script) to fix this?

The defaut Freesurfer segmentation ("thalamus proper") is generally 
larger than the segmentation output by segmentThalamicNuclei, except in 
the area of the LGN, where the thalamic segmentation extends more 
laterally/inferiorly, as if it had been extended in order to include the 
LGN (although imperfectly). Unfortunately, this does not seem to be the 
case for the MGN (which is my primary area of interest).

To solve the issue, I'm thresholding the posterior probability maps at 
p>0.2 for both LGN and MGN and adding these voxels to the discrete 
segmentation, but that's not very satisfactory. Actually, it wasn't very 
clear to me from the published paper how the discrete segmentation is 
obtained from the posterior probability maps and if any cut-off value is 
used to decide whether to include any voxel in the final discrete 
segmentation?

(Note that I'm using T1-weighted MPRAGE data at a resolution of 0.7 mm 
isotropic)

Thanks

Julien


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

Re: [Freesurfer] flirt.fsl error (NEWMAT::SingularException) when running bbregister in Freesurfer 7.0.0

2020-06-06 Thread julienbesle
External Email - Use Caution

Hi Andrew,

I was just wondering whether this issue has been fixed in version 7.1.0?

Thanks

Julien


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


Re: [Freesurfer] flirt.fsl error (NEWMAT::SingularException) when running bbregister in Freesurfer 7.0.0

2020-05-08 Thread julienbesle
External Email - Use Caution

Hi Andrew,

Thanks for looking into this. Yes, copying the binary from the v6 to the 
v7 installation does solve the issue.

Julien



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


[Freesurfer] flirt.fsl error (NEWMAT::SingularException) when running bbregister in Freesurfer 7.0.0

2020-05-07 Thread julienbesle
External Email - Use Caution

Hi,

I just installed freesurfer v7 and I'm getting an error in a script that 
calls bbregister with the --fslmat and --init-fsl options. This error 
does not occur in freesurfer v6 even when using exactly the same data, 
but it does also occur with a development version of freesurfer I 
downloaded in Sept 2019 (exact same error).

The call is:

DEBUG    : 2020-05-06 12:07:12,816 : runCmd : Running: bbregister 
--s HLOSS_p5 --mov 
/home/julien/data/HLOSS/pilot05_B/DWI/B0_corrected_mean_resampled_MPRAGE.nii 
--reg 
/home/julien/data/HLOSS/pilot05_B/DWI/easy_lausanne_test/b0-TO-orig.dat 
--fslmat 
/home/julien/data/HLOSS/pilot05_B/DWI/easy_lausanne_test/b0-TO-orig.mat 
--init-fsl --dti

The error occurs when bbregister calls fsl.flirt:

INFO : 2020-05-06 12:08:24,560 : main   : flirt.fsl -ref 
/home/julien/data/HLOSS/pilot05_B/DWI/easy_lausanne_test/tmp.bbregister.8331/fslregister/refvol.fslregister.nii
 
-in 
/home/julien/data/HLOSS/pilot05_B/DWI/easy_lausanne_test/tmp.bbregister.8331/fslregister/movvol.fslregister.nii
 
-bins 256 -cost corratio -dof 6 -searchrx -90 90 -searchry -90 90 
-searchrz -90 90 -verbose 0 -omat 
/home/julien/data/HLOSS/pilot05_B/DWI/easy_lausanne_test/tmp.bbregister.8331/fslregister/fslmat0.trans.mat
 
-schedule /usr/local/freesurfer/bin/fsl.5.0.2.xyztrans.sch -init 
/home/julien/data/HLOSS/pilot05_B/DWI/easy_lausanne_test/tmp.bbregister.8331/reg.init.dat.fsl.mat0
INFO : 2020-05-06 12:08:55,102 : main   : Wed May  6 12:08:54 
EEST 2020
INFO : 2020-05-06 12:08:55,603 : main   : /mnt/f/data/HLOSS
INFO : 2020-05-06 12:08:56,105 : main   : flirt.fsl -ref 
/home/julien/data/HLOSS/pilot05_B/DWI/easy_lausanne_test/tmp.bbregister.8331/fslregister/refvol.fslregister.nii
 
-in 
/home/julien/data/HLOSS/pilot05_B/DWI/easy_lausanne_test/tmp.bbregister.8331/fslregister/movvol.fslregister.nii
 
-bins 256 -cost corratio -dof 6 -searchrx -90 90 -searchry -90 90 
-searchrz -90 90 -verbose 0 -omat 
/home/julien/data/HLOSS/pilot05_B/DWI/easy_lausanne_test/tmp.bbregister.8331/reg.init.dat.fsl.mat
 
-init 
/home/julien/data/HLOSS/pilot05_B/DWI/easy_lausanne_test/tmp.bbregister.8331/fslregister/fslmat0.trans.mat
 
-schedule /usr/local/freesurfer/bin/flirt.newdefault.20080811.sch
INFO : 2020-05-06 12:09:15,632 : main   : terminate called after 
throwing an instance of 'NEWMAT::SingularException'
INFO : 2020-05-06 12:09:15,633 : main   : Abort (core dumped)
INFO : 2020-05-06 12:09:15,634 : main   : ERROR: flirt
CRITICAL : 2020-05-06 12:09:15,634 : runCmd : Return Value: 1

It looks like the first time flirt.fsl is called everything goes fine, 
but the second time, the error occurs. Unfortunately this is not a 
script I wrote myself, so I'm not sure what this particular call to 
bbregister is supposed to achieve. I'm not sure the call to fsl.flirt 
depends on which version of FSL I have installed, but just in case, I 
used the FSL v6 and didn't change anything to the FSL installation 
between trying Freesurfer v6, dev or v7. I run everything on Ubuntu 
16.04 running on WSL on Windows 10.

Any idea what could be going wrong?

Thanks

Julien

-- 
-
Julien Besle
Lagos Center, Apt 9A
Sadat Street
Beirut
Lebanon

tel: +961 78 980 317
-


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

Re: [Freesurfer] Non-matching ROI areal measures using mri_segstats and mris_anatomical_stats (2nd post)

2015-09-24 Thread julienbesle
Hi Doug

Indeed, you had answered my post previously, but so promptly that I 
missed it! My bad..

I have now re-run the analysis with the --jac option, and I do indeed 
now obtain the same results with both methods.

Thanks a lot!

Julien

> Message: 17
> Date: Tue, 22 Sep 2015 10:03:56 -0400
> From: Douglas Greve<gr...@nmr.mgh.harvard.edu>
> Subject: Re: [Freesurfer] Non-matching ROI areal measures using
>   mri_segstats and mris_anatomical_stats (2nd post)
> To:freesurfer@nmr.mgh.harvard.edu
> Message-ID:<56015fcc.8070...@nmr.mgh.harvard.edu>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Sorry, I thought I had answered this (or something like it) recently.
> When transforming area (or volume) with mri_surf2surf you have to turn
> on jacobian correction with --jac. Try that and see if the results are
> similar
> doug
>
>
> On 9/22/15 8:58 AM, julienbesle wrote:
>> >I am reposting this message, as I didn't get any answer so far:
>> >-
>> >
>> >Dear Freesurfer experts
>> >
>> >I have run a group ROI analysis comparing cortical thickness and area
>> >between two groups of subject. I did this in two different ways: (1)
>> >using mri_segstats after transforming each subject's data to fsaverage
>> >space, AND (2) using mris_anatomical_stats after transforming the ROI
>> >from fsaverage space to the space of each subjects. I get very similar
>> >results for cortical thickness, but completely different results for
>> >area. Does anyone have any idea why that could be happening ?
>> >
>> >Details:
>> >
>> >I have an ROI that I obtained from an atlas in MNI space and projected
>> >to the fsaverage surface (into say ROI_lh.mgh file). The aim of the ROI
>> >analysis was to find whether there are differences in cortical thickness
>> >and area between two groups of subjects in this ROI.
>> >
>> >I tested this in two ways:
>> >
>> >Method 1:
>> >a) I transformed the cortical thickness and area data of each subject
>> >into fsaverage space
>> >
>> >mri_surf2surf --s subj --trgsubject fsaverage --hemi lh --sval area
>> >--tval subj_area_fsaverage.mgh
>> >
>> >mri_surf2surf --s subj --trgsubject fsaverage --hemi lh --sval thickness
>> >--tval subj_thickness_fsaverage.mgh
>> >
>> >b) I averaged the thickness or area data within the ROI in fsaverage
>> >space for each subject using mri _segstats
>> >
>> >mri_segstats --seg ROI_lh.mgh --in subj_area_fsaverage.mgh --sum
>> >output_area_subj.stats
>> >
>> >mri_segstats --seg ROI_lh.mgh --in subj_area_fsaverage.mgh --sum
>> >output_thickness_subj.stats
>> >
>> >c) I used a 2-sample T test to compare the area or thickness output
>> >between my two groups of subjects.
>> >
>> >
>> >Method 2:
>> >a) I transformed ROI.mgh into a label file ROI.label
>> >
>> >mri_cor2label --i ROI_lh.mgh --id 1 --l ROI_lh.label --surf fsaverage lh
>> >
>> >b) I transformed the label file from fsaverage space to each subject's space
>> >
>> >mri_label2label --srcsubject fsaverage --srclabel ROI_lh.label
>> >--trgsubject subj --trglabel ROI_lh_subj.label --hemi lh --regmethod surface
>> >
>> >c) I averaged the thickness and area data within the ROI in each
>> >subject's space using mris_anatomicalstats
>> >
>> >mris_anatomical_stats -l ROI_lh_subj.label -f output_subj.stats subj lh
>> >
>> >d) I used a 2 sample T test to compare the area or thickness data (from
>> >the output_subj.stats files) between my two groups of subjects.
>> >
>> >
>> >For cortical thickness, i obtain very similar results (not identical,
>> >but similar to a hundredth of a mm), but for area, I get completely
>> >different results, sometimes opposite direction of effect between the
>> >two groups. I have 10 ROIs, and across ROIs, group differences are much
>> >more significant in the first than the second method. The areal results
>> >are in different units, which is expected (in the first method, they are
>> >in mm2/vertex and in the second they are in mm2 because they express the
>> >total area of the ROI). But despite that, shouldn't I get similar
>> >patterns of results ? I would have assumed that the vertexwise areal
>> >values averaged in the first method should somehow reflect differences
>&

[Freesurfer] Non-matching ROI areal measures using mri_segstats and mris_anatomical_stats (2nd post)

2015-09-22 Thread julienbesle
I am reposting this message, as I didn't get any answer so far:
-

Dear Freesurfer experts

I have run a group ROI analysis comparing cortical thickness and area 
between two groups of subject. I did this in two different ways: (1) 
using mri_segstats after transforming each subject's data to fsaverage 
space, AND (2) using mris_anatomical_stats after transforming the ROI 
from fsaverage space to the space of each subjects. I get very similar 
results for cortical thickness, but completely different results for 
area. Does anyone have any idea why that could be happening ?

Details:

I have an ROI that I obtained from an atlas in MNI space and projected 
to the fsaverage surface (into say ROI_lh.mgh file). The aim of the ROI 
analysis was to find whether there are differences in cortical thickness 
and area between two groups of subjects in this ROI.

I tested this in two ways:

Method 1:
a) I transformed the cortical thickness and area data of each subject 
into fsaverage space

mri_surf2surf --s subj --trgsubject fsaverage --hemi lh --sval area 
--tval subj_area_fsaverage.mgh

mri_surf2surf --s subj --trgsubject fsaverage --hemi lh --sval thickness 
--tval subj_thickness_fsaverage.mgh

b) I averaged the thickness or area data within the ROI in fsaverage 
space for each subject using mri _segstats

mri_segstats --seg ROI_lh.mgh --in subj_area_fsaverage.mgh --sum 
output_area_subj.stats

mri_segstats --seg ROI_lh.mgh --in subj_area_fsaverage.mgh --sum 
output_thickness_subj.stats

c) I used a 2-sample T test to compare the area or thickness output 
between my two groups of subjects.


Method 2:
a) I transformed ROI.mgh into a label file ROI.label

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

b) I transformed the label file from fsaverage space to each subject's space

mri_label2label --srcsubject fsaverage --srclabel ROI_lh.label 
--trgsubject subj --trglabel ROI_lh_subj.label --hemi lh --regmethod surface

c) I averaged the thickness and area data within the ROI in each 
subject's space using mris_anatomicalstats

mris_anatomical_stats -l ROI_lh_subj.label -f output_subj.stats subj lh

d) I used a 2 sample T test to compare the area or thickness data (from 
the output_subj.stats files) between my two groups of subjects.


For cortical thickness, i obtain very similar results (not identical, 
but similar to a hundredth of a mm), but for area, I get completely 
different results, sometimes opposite direction of effect between the 
two groups. I have 10 ROIs, and across ROIs, group differences are much 
more significant in the first than the second method. The areal results 
are in different units, which is expected (in the first method, they are 
in mm2/vertex and in the second they are in mm2 because they express the 
total area of the ROI). But despite that, shouldn't I get similar 
patterns of results ? I would have assumed that the vertexwise areal 
values averaged in the first method should somehow reflect differences 
in area betwen subjects and therefore should give similar result to the 
total area approach (2nd method). Or is it that, in the first method, 
mri_surf2surf interpolates the vertexwise areal values without taking 
into account the stretching/deformation from the subject's space to 
fsaverage space (in contrast with a vertexwise analysis using 
mris_preproc) ?

This is suggested by the fact that when I divide the total ROI area data 
obtained in the second method by the number of vertices in the ROI (in 
each subject's space), I end up with results that are very similar to 
the first method. The absolute values are different (around 0.7 
mm2/vertex in the first method and around 0.6 mm2/vertex for the second 
method), but the group effects are in the same direction (across the 10 
ROIs, all the effect sizes and p-values are similar so it can't be a 
coincidence). This suggests that the vertexwise areal values obtained in 
both methods simply reflect the ROI-average vertexwise areal values of 
each subject's mesh (and therefore do not include potential areal 
differences between subjects, assuming similar vertex spacing betwen 
subjects, and so shouldn't be used to compare areas between groups). 
However, if this is correct, isn't it strange that I should find 
significant differences in these vertexwise areal values between groups?


So I guess I have three main questions:

1) Why is there a difference between the 2 methods for area but not 
thickness ?

2) What is the 'correct' method for area (if any) ? Or is there a better 
method for an ROI analysis of area?

3) Why are there even significant differences between vertexwise area 
values in the first and second method ?


I am using Freesurfer v 5.3.0 (although the first analysis was 
potentially run using 5.0.0, not sure!)

Thanks in advance

Julien



-- 
-
Julien Besle
Senior 

[Freesurfer] Non-matching results for area ROI group analysis using two different approaches

2015-08-28 Thread julienbesle
Dear Freesurfer experts


I have run an ROI analysis in Freesurfer using two different strategies 
and I would have expected the results to be the same (or similar), but 
they are not and I don't really understand why.

I have an ROI that I obtained from an atlas in MNI space and projected 
to the fsaverage surface (into say ROI_lh.mgh file). The aim of the ROI 
analysis was to find whether there are differences in cortical thickness 
and area between two groups of subjects in this ROI.


I tested this in two ways:

1. a) I transformed the cortical thickness and area data of each subject 
into fsaverage space

mri_surf2surf --s subj --trgsubject fsaverage --hemi lh --sval area 
--tval subj_area_fsaverage.mgh

mri_surf2surf --s subj --trgsubject fsaverage --hemi lh --sval thickness 
--tval subj_thickness_fsaverage.mgh

 b) I averaged the thickness or area data within the ROI for each 
subject using mri _segstats

mri_segstats --seg ROI_lh.mgh --in subj_area_fsaverage.mgh --sum 
output_area_subj.stats

mri_segstats --seg ROI_lh.mgh --in subj_area_fsaverage.mgh --sum 
output_thickness_subj.stats

 c) I used a 2-sample T test to compare the area or thickness output 
between my two groups of subjects.

2. a) I transformed ROI.mgh into a label file ROI.label

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

 b) I transformed the label file from fsaverage space to each 
subject's space

mri_label2label --srcsubject fsaverage --srclabel ROI_lh.label 
--trgsubject subj --trglabel ROI_lh_subj.label --hemi lh --regmethod surface

 c) I averaged the thickness and area data within the ROI using 
mris_anatomicalstats

mris_anatomical_stats -l ROI_lh_subj.label -f output_subj.stats subj lh

 d) I used a 2 sample T test to compare the area or thickness data 
(from the output_subj.stats files) between my two groups of subjects.

For cortical thickness, i obtained very similar results (not identical, 
but similar to a hundredth of a mm), but for area, i get completely 
different results, sometimes opposite direction of effect between the 
two groups. I have 10 ROIs, and across ROIs, group differences are much 
more significant in the first than the second method. The areal results 
are in different units, which is expected (in the first method, they are 
in mm2/vertex and in second they are in mm2 because they express the 
total area of the ROI). But despite that, shouldn't I get similar 
patterns of results ? I would have assumed that the vertexwise areal 
values averaged in the first method should somehow reflect differences 
in area betwen subjects and therefore should give similar result to the 
total area approach (2nd method).


Now for the weird part: When I divide the total ROI area data obtained 
in the second method by the number of vertices in the ROI (in each 
subject's space), I end up with results that are very similar to first 
method! The absolute values are different (around 0.7 mm2/vertex in the 
first method and around 0.6 mm2/vertex for the second method), but the 
group effects are in the same direction (across the 10 ROIs, all the 
effect sizes and p-value are similar so it can't be a coincidence). I 
can't get my head around this: assuming that the spacing between 
vertices of the mesh is similar between different subjects, why are 
there even significant differences between groups? Or is that not an 
assumption that can be made ? (I should add that these are relatively 
large groups: 73 vs 55)


So I guess I have three main questions:

1) Why is there a difference between the 2 methods for area but not 
thickness ?

2) What is the 'correct' method for area (if any) ? Or is there a better 
method for an ROI analysis of area?

3) Why are there even significant differences between vertexwise area 
values in the second method ?


I am using Freesurfer v 5.3.0 (although the first analysis was 
potentially run using 5.0.0, not sure!)


Thanks in advance


Julien






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