Should SignedMaurerDistanceMapImageFilter accept non-floating outputs? Docs says so?

[emmenlau]

From the documentation of SignedMaurerDistanceMapImageFilter, I was understanding that its perfectly valid to use output images of integral type. Quoting from the docs (emphasis mine):

To maintain integer arithmetic within the filter, the default output is the signed squared distance. This implies that the input image should be of type "unsigned int" or "int" whereas the output image is of type "int". Obviously, if the user wishes to utilize the image spacing or to have a filter with the Euclidean distance (as opposed to the squared distance), output image types of float or double should be used.

However I fail to compile when the output image type is not a floating point type. I think this is due to the following concept check:

ITK/Modules/Filtering/DistanceMap/include/itkSignedMaurerDistanceMapImageFilter.h

Line 160 in 047fa69

itkConceptMacro(OutputImagePixelTypeIsFloatingPointCheck, (Concept::IsFloatingPoint<OutputPixelType>));

Am I doing something wrong? Is this supposed to work?

[dzenanz]

Following #1975 and #1997, maybe docs should be updated?

While it would probably work to just remove the concept check, I advise against it as I have been burned by it - spent hours tracking down where some wrong results come from.

[emmenlau]

I have not checked the code in detail. But looking at the results, I think that if GetSquaredDistance() and GetUseImageSpacing() are both false, the results should always be integral.

But I can see that this may be a special case that is not so worthwhile to support?

[dzenanz]

ITK/Modules/Filtering/DistanceMap/include/itkSignedMaurerDistanceMapImageFilter.h

Lines 197 to 198 in 047fa69

	bool m_UseImageSpacing{ true };
	bool m_SquaredDistance{ false };

The defaults are the opposite of that case. If we allowed integer outputs, the problematic case would appear frequently.
If you compile ITK with ITK_USE_CONCEPT_CHECKING=OFF, you should still be able to use integer outputs. I suggest updating the docs with this workaround, if someone really wants to avoid float distances.

[emmenlau]

Well, some other libraries that I know of use rounding for the case of integral outputs. It depends on the use case if this approximation is good enough. But I can see that this would require a number of changes in the filter to better support integral outputs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.