5ttgen hsvs: Fix erroneous behaviour #2365
Description
Erroneous results observed in 5ttgen hsvs outputs, but problem stems from a combination of voxel2mesh / meshfilter smooth / mesh2voxel. As reported on forum.
The mesh2image algorithm relies on a sequence of steps. Initially, it identifies the set of voxels intersected by the surface. It then attempts to classify the voxels adjacent to these intersected voxels as either presiding inside the surface or lying outside of it, based on the surface normals. It then looks for connected-component voxel clusters for which there is a consensus regarding this inside / outside classification (for robustness against having been provided with erroneous normal vectors, which can happen with certain relevant data sources). If this process doesn't work correctly, and all voxels outside the surface get erroneously classified as instead residing within the surface, everything downstream breaks.
One circumstance in which this can occur is if the Marching Cubes algorithm (i.e. voxel2mesh) is executed on a mask containing single voxel, followed by surface-based smoothing. 7b2b215 attempted to mitigate this within #1386 by skipping the smoothing step for single-voxel mask images. However if a mask image contains multiple isolated voxels, that skip is not triggered, and so the same problem manifests.
So there are multiple possible avenues for rectification:
-
The check introduced in 7b2b215 should ideally first be running a connected-component analysis on the surface data (requested in Additional mesh-handling functionalities #773), checking the sizes of the individual components, and then smoothing them individually (the current smoothing algorithm will not allow disconnected components to influence one another, the only difference is whether or not individual connected components would be excluded from smoothing);
-
Further improvement to the
mesh2voxelalgorithm to make it more robust against structures that are sub-voxel in size (potentially with erroneous surface normals).
I think what's specifically needed is to take an existing solution to another problem, being counting how many of the eight corners of the image are in the connected component, and override the surface-normal-consensus-based "internal" classification of the connected component if all eight corners of the image are in the connected component. This would technically break the unlikely case where all eight corners of the image are in fact inside of the surface but some voxels in the image are outside of the surface, but I'm not sure if it's worth trying to devise a solution that preserves that case.