5ttgen hsvs fails with FreeSurfer v. 7.1.0

1

Hi!

I’ve tried to run the “5ttgen hsvs” algorithm based on the recon-all output directory from FreeSurfer v. 7.1.0. However, brain stem segmenting / cropping failed; I received the following error message:

###############
[…]

5ttgen: [100%] Combining and smoothing corpus callosum segmentation

5ttgen: [ 80%] Segmenting and cropping brain stem…

5ttgen: [ERROR] Unhandled Python exception:

5ttgen: [ERROR] ValueError: min() arg is an empty sequence

5ttgen: [ERROR] Traceback:

5ttgen: [ERROR] /usr/local/bin/5ttgen:58 (in execute())

5ttgen: [ERROR] alg.execute()

5ttgen: [ERROR] /usr/local/mrtrix3/lib/mrtrix3/_5ttgen/hsvs.py:437 (in execute())

5ttgen: [ERROR] fourthventricle_zmin = min([ int(line.split()[2]) for line in run.command(‘maskdump 4th-Ventricle.mif’)[0].splitlines() ])

###############

I hypothesized that there might have been some label changes associated with the fourth ventricle in FS v. 7.1.0 as compared to v. 6, so next, I tried running the same command with the recon-all output from FS v. 6. Indeed, that worked fine. Did anyone encounter similar problems and has found a solution for the issue?

Thanks,
Marlene.

1 Like
2

Hi Marlene,

It looks to me like the 4th ventricle is still index 15 in FreeSurferColorLUT.txt in FreeSurfer 7. Admittedly it would be preferable for 5ttgen hsvs to actually be reading the FreeSurfer lookup table file and determining the indices from there, as this would make it more robust against FreeSurfer changes, but it’s not obvious based on the information here exactly what it is that has changed.

Are you able to interactively look at those voxels where FreeSurfer 6 has labelled the 4th ventricle, and see what indices FreeSurfer 7 has produced? It could be anything from a failure of FreeSurfer 7 to segment it successfully, it could be utilising some other index, it could be masking more aggressively to the point where the whole 4th ventricle is simply masked out. The 5ttgen hsvs code will need to be revised regardless in order to not crash out in this way, but I’d prefer to know exactly what the data look like in order to determine how the underlying logic should be changed.

Cheers
Rob