Change in behavior of spline prefiltering - expected?

It appears that, since scipy/scipy@81d5e7a, the behavior of spline interpolation has changed in a way that we (over at NIPY) found surprising.

In particular, as of that commit (I believe - see https://github.com/nipy/nipy/issues/468), we get a different result from direct use of scipy.ndimage.map_coordinates compared to precalculating the spline filter, and sending that to scipy.ndimage.map_coordinates. Here’s a script that demonstrates the change:

# Test 2D interpolation for Scipy
import numpy as np

import scipy.ndimage as spnd

arr = np.arange(6).reshape((2, 3))

coord = np.array([[0, 3]]).T

# Interpolation without calculating filter beforehand.
v1 = spnd.map_coordinates(arr,
                          coord,
                          order=3,
                          mode='nearest',
                         )
print('Calculate filter with interpolation', v1)

# Calculate and pass filter.
filtered = spnd.spline_filter(arr, order=3, mode='nearest')
v2 =  spnd.map_coordinates(filtered,
                           coord,
                           order=3,
                           mode='nearest',
                           prefilter=False)
print('Calculate filter followed by interpolation', v2)

On Scipy 1.5.4 this gives [2.] and [2.]. On Scipy 1.6.0 this gives [2.] and [2.20261874] (macOS 11.2.1).

I was expecting precalculation to give the same results as no precalculation - as it used to in Scipy <= 1.5.4. Is that expectation not correct?

[grlee77]

Hmm - testing now, I do not get the same with npad=12 and prefilter=False with non-integer voxel coordinates. Is the following surprising?

The difference here has to do with the dtype of the output. If unspecified, ndimage.interpolation functions use the dtype of the input array to determine the dtype of the output. In your example, when calculating v1, arr has an integer dtype, and so v1 is integer-valued as well. However, in the prefiltered case, filtered_and_padded.dtype is np.float64 so this gives a floating point result. This way of determining the output dtype has been present in ndimage for a long time and is not something new to the 1.6 release.

To get equivalent floating point results for both you would do:

When computing v1, specifyoutput=np.float64 in the map_coordinates call (or equivalently, cast arr to np.float64 before calling map_coordinates)

Or if the integer-valued output is the desired result

set output=np.int64 (or output=arr.dtype) in the computation of v2_padded

[matthew-brett]

Ouch - thank you! I’m so sorry to have accidentally made you do this debugging, rather than us - I’m afraid it was the classic problem of not enough tests on our side, then change of behavior (edges, ‘constant’) causing failures in the tests we did have, and then me writing more, new tests, without thinking to check what the results were previously.