Thanks for the explanation, Travis. It now looks like there are 2 distinct issues getting mixed up here, however. First, there is the issue of the mirror symmetry of the spline algorithm affecting the data towards the edges, as described by Peter and Travis (this is probably also what Anne is referring to). It is certainly useful to know about this, but I think this effect *within* the data boundaries must be relatively subtle compared with what I'm noticing. Second, there is a reflection 1 pixel *outside* the bounds of the original data, instead of the blank value I would expect. I think the code is just calculating one too many rows. I talked to Peter about this a bit more and he now agrees that it might be a real bug. I'll attach the most relevant part of his email below, along with my question (quoted). This doesn't solve the problem of fixing the code, of course, but I think it's useful to agree what the behaviour should be. Cheers, James. -----
Actually, just going back to your last email, it looks like the mirrored values in the output are *outside* the bounds of the input data (by 1 pixel), not just close enough for the interpolation window to overlap the edge. In the example from my last email, the value of 1.899 in the 5th column corresponds to a data point beyond the final 1.0 of the input data.
You are right, that values is actually interpolating from a point just outside the boundary of the input. Probably that should have been -1, so that you could call a bug. Why it calculates that value (and 2 for order=0) I am not sure...