Incorrect eTIV estimates

[dkuegler]

Description

We have found and confirmed too-slow eTIV estimates, for example as found in //stats/aseg.stats. eTIV estimates are in some cases too small (volumes significantly below 1.5L).

This happens, because the talairach registration "fails" (it does not "fail-safe", but produces unreasonable registration matrices). Since the eTIV estimation is based on the talairach registration, eTIV values are affected.

Both talairach registration and eTIV computation is performed by FreeSurfer binaries.

Note, that limitations to FreeSurfers eTIV estimation are well-known and documented, but we did not previously (and do not at this moment) specifically know how often this issue arises for FastSurfer.

Steps to Reproduce

Run FastSurfer (full pipeline) on affected subjects.

Expected Behavior

reasonable/correct eTIV estimates

Environment

any.

QC-Recommendations

Currently, etiv estimates of fastsurfer cannot be trusted.

At a minimum, check all eTIV values. Specifically, the Measure BrainSegVol-to-eTIV in the aseg.stats file should be smaller than 0.9

Solutions

We will:

1. Gather and clarify statistics about the reported eTIV values.
2. Introduce a fix ASAP, likely based on a reasonable initialization of the talairach-registration.

[robbwh]

You probably already know about this option, but the flag "-samseg-reg" in recon-all for talairach registration is superior in my experience.

[dkuegler]

My initial analysis shows, that etiv estimation error is relatively prevalent.

A BrainSegVol-to-eTIV < 0.9 is very indicative of a failed talairach registration.

Before this issue is fixed, eTIV estimates of FastSurfer should not be trusted.

[dkuegler]

@robbwh Thanks!

We are aware of the option, but this cannot easily be added to FastSurfer at the moment. It does point out an alternative approach to etiv calculation (that we were also aware of :-) ) as well ... through the samseg segmentation.

[m-reuter]

A consistent shift in eTIV is possible and no reason for concern (since we register a different image to the talairach average). Did you check the registration visually? We also need to make sure that for this check you use the correct talairach average as FreeSurfer has several. Further, how many cases did you find where the registration failed? Does this happen for a specific dataset or resolution?

[m-reuter]

Documentation on eTIV in FreeSurfer and FastSurfer. Currently both extract the eTIV from the determinant of the talairach.xfm file which get's created very early. See also https://surfer.nmr.mgh.harvard.edu/fswiki/eTIV .

FreeSurfer Steps:

• defacing (optional)
• one pass of bias field correct (default currently ANTS N4) https://github.com/freesurfer/freesurfer/blob/3517a66811af2a7b86a032e35219c9e2417a4488/scripts/recon-all#L1701 mri_nu_correct.mni --no-rescale --i orig.mgz --o nu_orig.mgz --ants-n4 --n 1 --proto-iters 1000 --distance 50 note that no mask is used (as it does not yet exist). Furthermore, the flags after ants-n4 are irrelevant as the command internally is https://github.com/freesurfer/freesurfer/blob/3517a66811af2a7b86a032e35219c9e2417a4488/scripts/mri_nu_correct.mni#L126C16-L129C61 AntsN4BiasFieldCorrectionFs -i orig_mgz -o $tmpdir/nu0.mgz --dtype uchar
• It then re-scales the output to the same mean intensity of input image orig.mgz (which does not make much sense, given that we re-scale later to prescribe WM intensity when converting to UCHAR). It finally copies header from input and
• robustly converts to UCHAR https://github.com/freesurfer/freesurfer/blob/dev/mri_convert/mri_make_uchar.cpp which internally uses a ball around the talairach center (which does not yet exist the first time this is called, not sure if it centers around RAS origin instead?) and tries to determine WM in this ball (which includes non-brain, e.g. optical tracts or background), to rescale the image so that WM is "around 110" using percentiles, see https://github.com/freesurfer/freesurfer/blob/3517a66811af2a7b86a032e35219c9e2417a4488/mri_convert/mri_make_uchar.cpp#L237 and following lines.
• Then register nu_orig to default atlas using Avi Snyders (a little aged) registration scripts: talairach_avi --I nu_orig.mgz --xfm talairach.xfm.auto
• That's basically all to get talairach.xfm (some sanity check and maybe some alternative way to compute it if it failed)
• This is followed by a second round of bias correction (this time with known talairach.xfm , which - I think - has no effect on Ants N4 but will have an effect on the UCHAR re-scaling, which then creates nu.mgz.
• partial volume computations in mri_segstats are performed on norm.mgz with is far further downstream and had many more intensity scaling and massaging applied to it, even on a structure by structure basis, if I remember correctly.

FastSurfer

• nu processing is changed here compared to recon-all: we use the brainmask from the segmentation to improve the nu correction (and speedup) : orig_nu N3 in FS6 took 44 sec, FS 7.3.2 uses --ants-n4 (takes 3 min and does not accept the mask due to a bug in AntsN4BiasFieldCorrectionFs wrapper).
• This re-implementation https://github.com/Deep-MI/FastSurfer/blob/dev/recon_surf/N4_bias_correct.py uses N4 from simpleITK with our brainmask, we also directly
• scale WM to 110 using a ball at the center of the mask with radius 50 (similar to FS, which uses origin of talairach.xfm and grabs quite a few non brain region in the frontal head, we don't). Also this avoids a second call to nu correct.

A problem is that the global re-scaling in our code differs from what FreeSurfer does, which affects the nu_orig.mgz in some cases and makes talairach_avi fail. One reason is probably that we crop the ball around the brain center with brain mask (which removes non-brain tissue, basically a good thing, but affects the scaling parameters a lot).

One easy quick-fix could be to continue to use the brain mask for N4 correct (which should actually help) but then not for cropping the ball and determining the UCHAR re-scaling, to make it more similar to FreeSurfer.

Another option is to better understand how the intercept and slope for the scaling are determined in FreeSurfer and do a better rescaling, e.g. since we already have a WM segmentation anyway. It however looks like FreeSurfer does not actually adjust WM mean to 110 but slightly off (we need to test if the mean is always consistently shifted or just noisy). Furthermore it is currently unclear where the 1st percentile should be (for lower cut-off).

All this affects talairach.xfm and therefore eTIV computation. Currently it is unclear how much it affects surfaces, thickness and other structures (e.g. when computing volumes with partial volume correction in mri_segstats). Since that uses norm.mgz we may need to do even more structure based scaling as in FreeSurfer to make that more similar. But we also provide segmentations from our VINN, so if volume estimates differ, how much of that is due to that prediction and how much due to different partial volume estimation.

Finally, even if we have consistently shifted volumes estimates compared to FreeSurfer, given that there is no reliable ground truth available, this does not really matter as long as downstream tasks such as test-retest and group separation task in FastSurfer continue to outperform the same in FreeSurfer.

[dkuegler]

I pushed a fix to this issue in #387 .

Next step is to run our validation Pipeline so we can verify and document that the issue has been resolved.

[dkuegler]

387 is merged into dev, pending validation