Total gray matter estimation from aseg+DKT.stats without surface reconstruction

[julii-a]

General Support Request

Description

Hello, I have a question about estimating total gray matter volume when using only the FastSurfer segmentation module.

As I understand, aseg+DKT.stats is generated from the segmentation module, while aseg.stats (including total gray matter) is produced after the surface module. Therefore, the total gray matter value in aseg.stats may be influenced by surface reconstruction (e.g., pial refinement).

If I want to use only segmentation-based volumetric outputs (e.g., aseg+DKT.stats), what is the recommended approach to obtain total gray matter volume?

Specifically:

1. Is it acceptable to derive total gray matter by summing relevant cortical and subcortical regions from aseg+DKT.stats?

In the FreeSurfer documentation, TotalGray is described as the sum of lhCortex + rhCortex + SubCortGray + CerebellumGM, which includes both surface-based volume calculations and voxel counts. Based on this, I am considering computing total gray matter by summing the corresponding cortical, subcortical, and cerebellar gray matter volumes from aseg+DKT.stats to keep the analysis fully volumetric.

2. Is there a recommended or standard list of regions to include for this purpose when using FastSurfer segmentation outputs?
3. Alternatively, is it still recommended to use the total gray matter value from aseg.stats, even when focusing on segmentation-based volumetric analysis?

I could not find clear guidance in the FreeSurfer documentation, and since outputs like aseg+DKT.stats seem to be specific to FastSurfer, I wanted to ask about the recommended practice.

Thank you for your guidance.

Environment

FastSurfer Verions: 2.4.2
Installation type: Docker
OS: Windows (WSL2, Ubuntu 22.04)

[dkuegler]

Hello @julii-a,

Let me answer your questions real quick:

1. That would be acceptable, and should also be good and reliable. In fact, we have a way to calculate this number for you in FastSurfer, we just do not enable it by default, because it might lead to confusion about why there are two numbers for the same thing (Total Gray Matter).
   The easiest (and consistent way) would be to from stats/aseg.VINN.stats find/read the following lines and add the volumes:

   ...
   # Measure SubCortGray, SubCortGrayVol, Subcortical gray matter volume, 59860.993064, mm^3
   ...
   2   3    734784 245592.265  Left-Cerebral-Cortex              77.6681     7.3268    50.0000   110.0000    60.0000
   ...
   6   8    156191  52993.611  Left-Cerebellum-Cortex            79.0481    10.0782    25.0000   116.0000    91.0000
   ...
   21  42    736897 245768.961  Right-Cerebral-Cortex             77.7890     7.3054    51.0000   117.0000    66.0000
   ...
   25  47    156201  53067.086  Right-Cerebellum-Cortex           79.3619    10.1307    26.0000   113.0000    87.0000
   

   From the table (last 4 lines) you would take the partial volume corrected volume, i.e. the 4th column.
   If you are coding this with python, you could FastSurfer's read_statsfile to read the table and read_measurefile to read the SubCortGray (the latter seems to be missing from the documentation, it is in FastSurferCNN/utils/brainvolstats.py).
2. See above, for documentation purposes, I specifically recoded the baseline code and our implementation in python is also very fast (compared to FreeeSurfer's). TotalGray is the sum of SubCortGray, Cortex, CerebellarGM, but since since Cortex is surface based, you would be replacing this with Left-Cerebral-Cortex and Right-Cerebral-Cortex from the table. (CerebellarGM is from the table in any case).
3. Whether you use TotalGray from post-surface or just segmentation-based statistics probably does not make a huge difference. In fact, it is entirely unclear to me, if the surface processing has any positive effect in the TotalGray estimate. I would expect it to make no difference.

[m-reuter]

The surface update on the segmentation is the standard in FreeSurfer, which is why we do the same in FastSurfer inside the surface module. The effect of this is rather limited.

• positive: it can lead to a better and more accurate boundary due to the surface placement, compared to FreeSurfers standard atlas based (aseg) segmentation. It is unclear how much that helps in FastSurfer, where the GM segmentation is already very good.
• negative: I think we had an issue where the fastsurfer GM segmentation looked already very good, but the surfaces then did not go out far enough and cropped some GM, so actually there the surface-based fine tuning was hurting more than it helped. It can also happen that the surface moves into dura (out too far). And third, there are GM regions close to the hippocampus that get ignored when using the surface-edited approach. The reason is that the cortex label stops at where the WM surface touches sub-cortical structures (here the hippocampus) and the pial swings around and does not yet touch the hippocampus for a while. That wedge is not labeled GM after surface editing, but usually it is labeled correctly in the segmentation.

So from all this I think probably using the segmentation based volumes is actually better. But this is not thoroughly tested and only based on individual cases that I looked at.

[julii-a]

Thank you for your helpful reply.

I have a few follow-up questions.

1. It seems that I do not have the file aseg.VINN.stats in my FastSurfer output. Could you please clarify how this file is generated?

2. If aseg.VINN.stats is not available, is it acceptable to instead use aseg+DKT.stats and compute total gray matter volume by summing the following regions?

• SubCortGray
• Left-Cerebral-Cortex
• Right-Cerebral-Cortex
• Left-Cerebellum-Cortex
• Right-Cerebellum-Cortex

In aseg+DKT.stats, I do not see a single “Cortex” entry, but rather separate cortical labels. Should I sum the corresponding cortical regions directly (i.e., the prefix “ctx”.), or are there additional cortical components that should be included?

3. In your previous comment, you mentioned:

“From the table (last 4 lines) you would take the partial volume corrected volume, i.e. the 4th column.”

Is the volume reported in aseg+DKT.stats already the partial volume–corrected volume, or does this apply only to aseg.VINN.stats?
For example, from the table below in aseg+DKT.stats, the 4th column should be used. In the case of Left-Cerebellum-Cortex, this would be 53142.184.

#aseg+DKT.stats
# ColHeaders  Index SegId NVoxels Volume_mm3 StructName normMean normStdDev normMin normMax normRange
  1   2    221873 223426.623  Left-Cerebral-White-Matter       104.1800     9.5562    27.0000   178.0000   151.0000
  2   4      8181   8630.266  Left-Lateral-Ventricle            33.1683    12.0396     6.0000    79.0000    73.0000
  3   5       508    564.701  Left-Inf-Lat-Vent                 48.4508    15.5010    10.0000    82.0000    72.0000
  4   7     16402  16719.280  Left-Cerebellum-White-Matter     107.7396     8.6547    62.0000   135.0000    73.0000
  5   8     54486  53142.184  Left-Cerebellum-Cortex            77.1379    11.7701    13.0000   123.0000   110.0000
  6  10      6966   6664.454  Left-Thalamus                     91.3605     9.6636    49.0000   118.0000    69.0000

4. Is brainvolstats part of the surface module? I had assumed that it summarizes surface-based outputs (such as TotalGray from the surface pipeline), but from your explanation it seems that it can also be used for segmentation-based volumetric outputs. Could you please clarify its role and which pipeline it corresponds to?

Additionally, I have a few related questions regarding differences between FreeSurfer and FastSurfer.

5. When using the --fsaparc flag:

   • Does this simply add FreeSurfer-based atlas statistics to the existing FastSurfer surface outputs?
   • Or does this flag overwrite or modify any surface output files compared to the standard surface pipeline without this flag?

6. Regarding the outputs of --fsaparc, I could not find detailed documentation:

   • Are additional .mgz files generated?
   • Are values in aseg.stats affected by enabling --fsaparc, or do they remain unchanged?

7. Are lh.aparc.DKTatlas.mapped.stats and lh.aparc.DKTatlas.stats conceptually different?
   My understanding is that the “mapped” version corresponds to the FastSurfer DKT atlas mapped onto the surface, whereas the other reflects the original FreeSurfer atlas. Is this correct?
   Also, is lh/rh.aparc.a2009s.stats(Destrieux atlas) generated only when using the FreeSurfer-based pipeline?

8. In practice, when using FastSurfer outputs for both cortical thickness and volumetric analysis:

   • Is it recommended to combine segmentation-based volumetric measures (e.g., from aseg+DKT.stats) with FastSurfer cortical measures (e.g., lh.aparc.DKTatlas.mapped.stats)?
   • Would it be acceptable to mix these measures with lh/rh.aparc.a2009s.stats (Destrieux atlas) outputs as well?

Thank you again for your time and effort.

[dkuegler]

1. Maybe that file only gets computer in the upcoming 2.5 release (and dev). I only checked the outputs for that.
   There it gets generated from the aseg.auto.no_CC.mgz segmentation file, which is like aseg.mgz, but without the corpus callosum.
2. Yes, that should work and you would have to sum up all the values that start with "ctx-"... Or wait for the 2.5 update...
3. The fourth column of all our volume stats files are partial-volume corrected.
4. Brainvolstats for both freesurfer an fastsurfer refers to the the section of the file where each line starts with "# Measure". Some of these entries are surface-based and require surface reconstruction, others are already available after segmentation. aseg+DKT.stats only includes the volume-based measures, plus etiv, if fastsurfer is run with --tal_reg. Etiv is based on the talairach registration.
5. --fsaparc replaces and changes the way fastsurfer creates the critical parcellation in the surface reconstruction. Instead of mapping the neural network segmentation results from the segmentation to the surface, the freesurfer way of generating the parcellations is used : registration of the surface to the atlas.
6. This should only effect surface parcellations. So all files that have DKTatlas in the file name.
7. That is correct. We generate links between these files in the surface pipeline, i.e. without --fsaparc, the non-mapped files are soft links to the mapped files for compatibility purposes. So the line cannot always be drawn very clearly.
8. Yes, that would be fine. I would recommend to think about the used values and only choose where an effect is expected, but at a minimum try to reduce redundancy. Both would be to reduce overfitting, maybe also to improve statistical significance due to required Benjamin Hochberg corrections (depending on your statistical model and hypothesis).

[julii-a]

Thank you for the clear and helpful explanation. I would like to clarify my understanding of the --fsaparc flag.

1. When comparing the default FastSurfer surface pipeline and the --fsaparc version, is it correct that the reconstructed surfaces (e.g., white and pial) remain identical, and that only the atlas-based parcellation results (such as lh/rh.aparc.a2009s.stats (Destrieux atlas) and lh.aparc.DKTatlas.stats) differ? In other words, are the differences limited to atlas parcellation and the corresponding statistics and MRI label files, while the underlying surfaces and thickness computation remain unchanged?

2. Is it difficult or not supported to generate the Destrieux (lh/rh.aparc.a2009s.stats) atlas using the default FastSurfer mapping approach? My main reason for using the --fsaparc flag was not necessarily to follow the FreeSurfer parcellation strategy, but rather to obtain the a2009s (Destrieux ) atlas outputs. Is there an alternative way to generate these atlas results within the standard FastSurfer pipeline?

Thank you again for your time.

[m-reuter]

With --fsaparc FastSurfer follows much more closely what FreeSurfer does:

• all standard FreeSurfer cortical parcellations are computed the FreeSurfer way (no symbolic links from mapped)
• aparc is used to guide the surface placement rather than the mapped FastSurfer version, so surfaces can deviate slightly
• this can slightly affect thickness estimates, also other surface measures, like curvature, area, ...
• aseg is fine-tuned based on these different surfaces
• also the cortical labels in aparc+aseg images and stats etc are from the FreeSurfer cortical segmentations, not the mapped

So you see that this flag affects basically everything as the pipeline changes from using FastSurfers deep learning based cortical segmentations to FreeSurfer surface atlases for people who want to stay as close as possible to FreeSurfer. So answer 6 above is not correct.

And for your questions 1: No, surfaces can also change slightly, etc. and 2. not supported via a flag, but not difficult either, just run the corresponding cortical atlas based segmentation. This is fast since the spherical registration to the fsaverage atlas space is available by default. See

FastSurfer/recon_surf/recon-surf.sh

Lines 1119 to 1122 in 9544db6

	CPAtlas="$FREESURFER_HOME/average/${hemi}.CDaparc.atlas.acfb40.noaparc.i12.2016-08-02.gcs"
	annot="$ldir/${hemi}.aparc.a2009s.annot"
	cmd="mris_ca_label -l $ldir/${hemi}.cortex.label -aseg $mdir/aseg.presurf.mgz -seed 1234 $longflag $subject $hemi $sdir/${hemi}.sphere.reg $CPAtlas $annot"
	RunIt "$cmd" "$LF"

where $ldir is the label directory etc. Ignore $longflag unless you run the longitudinal pipeline.