PERF: Use the faster TransformPhysicalPointToContinuousIndex overload

[N-Dekker]

Replaced image->TransformPhysicalPointToContinuousIndex(point, index)
calls by image->TransformPhysicalPointToContinuousIndex<T>(point),
which is slightly faster, as it does not figure out whether or not the
point is inside the image.

Declared variables that are initialized by
image->TransformPhysicalPointToContinuousIndex<T>(point) const, when
possible.

Follow-up to pull request #2873
commit eb6ac88
"PERF: Use the faster TransformPhysicalPointToIndex overload in filter"

[blowekamp]

The previous method returned a bool with the results of the point/index was inside the image. The places changed here ignored the results, so there is no risk of change in behavior or safety of lack of out-of-bounds checking?

[N-Dekker]

The previous method returned a bool with the results of the point/index was inside the image. The places changed here ignored the results, so there is no risk of change in behavior or safety of lack of out-of-bounds checking?

Thanks for asking, @blowekamp This pull request should not cause any change in behavior, because it only replaced calls to the old bool returning member function in those cases where the return value was ignored.

For example here (in ITK v5.3rc02):

ContinuousIndexType index;
m_Image->TransformPhysicalPointToContinuousIndex(point, index);
/* Call IsInsideBuffer to test against BufferedRegion bounds.
 * TransformPhysicalPointToContinuousIndex tests against
 * LargestPossibleRegion */
bool isInside = IsInsideBuffer(index);
return isInside;

https://github.com/InsightSoftwareConsortium/ITK/blob/v5.3rc02/Modules/Core/ImageFunction/include/itkImageFunction.h#L174-L180

Adjusted the TransformPhysicalPointToContinuousIndex call by this pull request to:

const ContinuousIndexType index = m_Image->template TransformPhysicalPointToContinuousIndex<TCoordRep>(point);

at https://github.com/InsightSoftwareConsortium/ITK/pull/2901/files#diff-15de01b61211603e7d6639a9825a5b9b95b38223b0d2eda58f7295bc82b1c976R174

Right?

[blowekamp]

@N-Dekker Yes. I think we are in agreement here. I just wanted to check. Perhaps a comment in the commit message indicated that the is inside check was not used would have short circuited the necessity of this discussion.

PR LGTM.