Fmriprep: volumes from *aseg_dseg.nii.gz mismatch with freesurfer stats

arovai · November 22, 2022, 10:01am

Hello!
I am willing to compute the volume of a given structure, say the right caudate. This structure has the index number 50 (as per desc-aseg_dseg.tsv, and consistently with freesurfer stats file).
From freesurfer stats for my subject, I get a volume (in mm3) of 3410.8 (for a NVoxels of 3438).
So my guess is that this volume should match the one of the voxels with value == 50 in sub-01_desc-aseg_dseg.nii.gz. When I count the number of voxels, I get 3726. This is not the same as in freesurfer, but this is also not (yet) a contradiction because voxel size might differ.
To get the volume, I extract the voxel size (using nibabel header.pixdim[1:4] and multiplying the entries).
This yields a voxel size of 0.99208842. The volume, from fmriprep outputs, is then
3274.8046875 mm3.

So there is a mismatch in volumes: from freesurfer output (generated by fmriprep, saved in fmriprep/sourcedata/freesurfer) I get 3410.8mm3 while from directly computing from the aseg.dseg.nii.gz image I get 3274.8046875 mm3.
This difference is not small, so there is something to understand…
Any guess?
Thanks!

jsein · November 22, 2022, 1:49pm

Hello!
Which FMRIPREP version are you using? What is your fmriprep command?

It is possible that the Freesurfer statististics is based on the probabilistic value of the segmentation, which gives a finer volume determination that just the number of voxels multiplied by the volume of one voxel.
I checked on one subject from dataset processed at our center with FMRIPREP v 21.0.2, I get exactly the same number of voxels and same volume, for structure 50 of sub-01_desc-aseg_dseg.nii.gz (fmriprep output) or aseg.mgz (freesurfer output), using the fslmaths et fslstats commands:

fslmaths sub-01_desc-aseg_dseg.nii.gz -thr 50 -uthr 50 sub-01_desc-50_roi.nii.gz
fslstats sub-01_desc-50_roi.nii.gz -V
3878 3878.000000

mri_convert -i aseg.mgz -o aseg.nii.gz
fslmaths aseg.nii.gz -thr 50 -uthr 50 sub-01_desc-50_roi_freesurfer.nii.gz
`fslstats sub-01_desc-50_roi_freesurfer.nii.gz -V
3878 3878.000000

And in aseg.stats, I can read:

# ColHeaders  Index SegId NVoxels Volume_mm3 StructName normMean normStdDev normMin normMax normRange 
24  50      3878     3896.9  Right-Caudate                     76.8463     7.0468    40.0000    98.0000    58.0000

also I got:
fslinfo sub-01_desc-50_roi.nii.gz

data_type	FLOAT32
dim1		192
dim2		240
dim3		256
dim4		1
datatype	16
pixdim1		1.000000
pixdim2		1.000000
pixdim3		1.000000
pixdim4		2.300000
cal_max		0.000000
cal_min		0.000000
file_type	NIFTI-1+

and:
fslinfo sub-01_desc-50_roi_freesurfer.nii.gz

data_type	FLOAT32
dim1		256
dim2		256
dim3		256
dim4		1
datatype	16
pixdim1		1.000000
pixdim2		1.000000
pixdim3		1.000000
pixdim4		2.300000
cal_max		0.000000
cal_min		0.000000
file_type	NIFTI-1+

arovai · November 22, 2022, 9:09pm

Thanks for this quick response!
I am using fmriprep v21.0.4. The command line, removing long paths and container-related matters, is

fmriprep /data/rawdata /data/derivatives/fmriprep participant --fs-license-file /fslicense/.license --use-aroma --output-spaces T1w MNI152NLin6Asym MNI152NLin2009cAsym --participant_label 01

Moreover, I did exactly as you did to double-check my result, and unfortunately I got the same discrepancy:

fslmaths sub-01_desc-aseg_dseg.nii.gz -thr 50 -uthr 50 sub-01_desc-50_roi.nii.gz
fslstats sub-01_desc-50_roi.nii.gz -V

output:

3726 3274.804688

Those are exactly the values I got when computing “myself” the volume from sub-01_desc-aseg_dseg.nii.gz (which I implemented in python using nibabel).

mri_convert -i aseg.mgz -o aseg.nii.gz
fslmaths aseg.nii.gz -thr 50 -uthr 50 sub-01_desc-50_roi_freesurfer.nii.gz
fslstats sub-01_desc-50_roi_freesurfer.nii.gz -V

output:

3438 3438.000000

Note that those are not quite the values reported in the stats/aseg.stats file!

# ColHeaders  Index SegId NVoxels Volume_mm3 StructName
24  50      3438     3410.8  Right-Caudate

So here another problem arises: the number of voxels matches but not the volume, and this in purely-from-freesurfer outputs…

So the mystery remains, and is even bigger.

Here are some info:

fslinfo sub-01_desc-50_roi.nii.gz

yields

data_type	FLOAT32
dim1		256
dim2		256
dim3		164
dim4		1
datatype	16
pixdim1		0.937500
pixdim2		0.937500
pixdim3		1.000000
pixdim4		0.008208
cal_max		0.000000
cal_min		0.000000
file_type	NIFTI-1+

while

fslinfo sub-01_desc-50_roi_freesurfer.nii.gz

gives

data_type	FLOAT32
dim1		256
dim2		256
dim3		256
dim4		1
datatype	16
pixdim1		1.000000
pixdim2		1.000000
pixdim3		1.000000
pixdim4		0.008208
cal_max		0.000000
cal_min		0.000000
file_type	NIFTI-1+

The discrepancies in the voxel dimensions cannot explain the differences in volumes, of course.

jsein · November 22, 2022, 9:53pm

Thank you for your feedback!

Interesting. In your case your original T1w image seems to have submillimetric resolution but the FreeSurfer output has a resolution of 1mm isotropic. Could it be the origin of the overestimation of the size of the Right-Caudate by FreeSurfer?

It would be interesting to run FreeSurfer with the -highres option enabled on your data to see if you would get a volume closer to the one obtained in the FMRIPREP output.

arovai · November 23, 2022, 12:15pm

I’ll give it a try and keep you posted, thanks a lot for the tips.