(Not ready) Simpler TransformPhysicalPointToContinuousIndex(point) overloads

[N-Dekker]

Added non-template overloads, which allow the user to write:

index = image->TransformPhysicalPointToContinuousIndex(point);

Instead of calling one of the overload that was added with ITK 5.0, for example:

index = image->template TransformPhysicalPointToContinuousIndex<typename ContinuousIndexType::ValueType>(point);

I assume that usually (or at least in most common use cases), the user just wants TransformPhysicalPointToContinuousIndex to just yield a ContinuousIndex<SpacePrecisionType, N> (with SpacePrecisionType = double, by default). So in most use cases, the ValueType of ContinuousIndex does not need to be a template argument of this function. Is that OK?

[dzenanz]

I love it!

[N-Dekker]

Would it be useful to have two of such (simple, non-templated) overloads? One of float and one of double? Specifically:

ContinuousIndex<float, VImageDimension>
TransformPhysicalPointToContinuousIndex(const Point<float, VImageDimension> &) const;

ContinuousIndex<double, VImageDimension>
TransformPhysicalPointToContinuousIndex(const Point<double, VImageDimension> &) const;

So one from Point<float, N> to ContinuousIndex<float, N>, and one from Point<double, N> to ContinuousIndex<double, N>? Overload resolution would then automatically choose the right one, no need for the user to specify template arguments. Right?

[dzenanz]

The float one is rarely used, I believe. If someone wants an unusual thing, they can spell out the template parameters.

[N-Dekker]

I'm wondering, could all those image->template TransformPhysicalPointToContinuousIndex<ContinuousValueType>(point) calls inside ITK itself then replaced by simple non-templated image->TransformPhysicalPointToContinuousIndex(point) calls?

[dzenanz]

Is this ready for merging? It would fix a lot of compile errors on the dashboard.

[N-Dekker]

Is this ready for merging?

@dzenanz No it's still a draft, sorry! PR #4005 is ready, though!

[N-Dekker]

Is ITK_USE_FLOAT_SPACE_PRECISION still supported? As in:

ITK/Modules/Core/Common/include/itkFloatTypes.h

Lines 26 to 31 in 1f8c0f8

	// Allow using single precision by default
	#if defined(ITK_USE_FLOAT_SPACE_PRECISION)
	using SpacePrecisionType = float;
	#else
	using SpacePrecisionType = double;
	#endif

Maybe it's just me, but I got a lot of compile errors when I try to compile the current master with ITK_USE_FLOAT_SPACE_PRECISION = ON. Is it still tested elsewhere?

I'm asking here because ITK_USE_FLOAT_SPACE_PRECISION = ON would make it harder to use the simpler TransformPhysicalPointToContinuousIndex overload (proposed by this PR) inside ITK itself.

[dzenanz]

ITK_USE_FLOAT_SPACE_PRECISION is still exposed in CMake, but I don't think it has been tested for a very long time. I think some components assume it is double. Maybe it is time to remove that setting and deprecate that header? What do @blowekamp and @hjmjohnson think about this?

[N-Dekker]

If we can't have a simple, easy to use alternative to the old "IsInside estimating" TransformPhysicalPointToContinuousIndex(point, index), maybe just remove the [[nodiscard]] from that particular member function. I'm sorry, I had not expected so much trouble from [[nodiscard]]. I still think users should be aware of the fact that TransformPhysicalPointToContinuousIndex(point, index) is estimating IsInside. And I still think they should only use it when they really want to know whether the point is inside. But I just don't know how to make it easier. 🤷

[N-Dekker]

ITK_USE_FLOAT_SPACE_PRECISION is still exposed in CMake, but I don't think it has been tested for a very long time. I think some components assume it is double. Maybe it is time to remove that setting and deprecate that header? What do @blowekamp and @hjmjohnson think about this?

I think that as long as ITK supports ITK_USE_FLOAT_SPACE_PRECISION (allowing the user to choose between SpacePrecisionType = float and SpacePrecisionType = double) and as long as ContinuousIndex supports float, double, and SpacePrecisionType as value type, a simple TransformPhysicalPointToContinuousIndex(point) overload that just returns ContinuousIndex<SpacePrecisionType, N> (proposed by this PR) is of very limited use.

[hjmjohnson]

I think that as long as ITK supports ITK_USE_FLOAT_SPACE_PRECISION (allowing the user to choose between SpacePrecisionType = float

I think we should test the ITK_USE_FLOAT_SPACE_PRECISION, I could think of a customer who may use FLOAT_SPACE_PRECISION for the purpose of improving computational speed for their algorithm. Removing this option MAY cause that customer great pain.

The above scenario is purely hypothetical .... just pointing out that removal may have unintended consequences for customers.