InsightSoftwareConsortium / InsightSoftwareConsortium/ITK
Allowing generic output type in `VectorLinearInterpolateImageFunction::EvaluateAtContinuousIndex`
- Dominant language
- C++
- Stars
- 1.7k
- Forks
- 748
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 64
Description
### Description
The current design restricts the output type of the interpolation to `double`. As shown [here](https://github.com/InsightSoftwareConsortium/ITK/blob/318139a0415e34e702f7ace4fff6b20f3ac65a10/Modules/Core/ImageFunction/include/itkVectorInterpolateImageFunction.h#L48) `NumericTraits::RealType` evaluates to `double` regardless of the input type.
We found this was an issue while profiling ANTs registrationSyN. Using ITK templating, the pipeline offers the option for computation to be done in either float or double. Unexpectedly, the execution time of the pipeline is significantly longer when using `float` compared to `double` (See figure below). Our observation shows that the time difference is due to the cast from float to double, and possible back to float in ANTs.

> Caption: Mean time per iteration for the interpolation stages and levels in ANTs registrationSyN.
Looking at gdb output we see that the input data is an 3D image of type `float`
```gdb
Thread 1 "antsRegistratio" hit Breakpoint 21, itk::VectorLinearInterpolateImageFunction, 3u>, float>::EvaluateAtContinuousIndex (this=0x55be27bacc00, index=...)
at /tmp/ants/build/staging/include/ITK-5.3/itkVectorLinearInterpolateImageFunction.hxx:48
48 VectorLinearInterpolateImageFunction::EvaluateAtContinuousIndex(
```
but the output is of type `double`.
```gdb
itk::FixedArray::Fill (value=, this=) at /tmp/ants/build/staging/include/ITK-5.3/itkVectorLinearInterpolateImageFunction.hxx:70
70 output.Fill(0.0);
```
### Impact analysis
Currently, the downside is that only `double` is accepted as an output type for the interpolation.
One the one hand, allowing generic type for the output would prevent confusion and potential slowdowns, as with the ANTs case above. Alternatively, the same type as the input data could be use, with similar benefits.
On the other hand, using different output type could affect the precision of the calculation if lower-precision data type are used, or increase the runtime if higher-precision data type are used. i.e. trade-off between performance and precision.
Due to the potential change in precision incurred by this change, this may affected substantially some tools depending on this function.
### Expected behavior
```none
```
### Actual behavior
```none
```
### Versions
### Additional Information
Contributor guide
Assessment
This issue has not been assessed yet.