Option to perform simple integer pixel shifts (rather than rebinning) in shiftadd

[vikdhillon]

I believe shiftadd currently rebins the data when correcting for shifts, which inevitably involves doing some kind of interpolation and hence some changing of the data (fluxes) that fall in each pixel. Hence it would be desirable to offer an integer-pixel-shift only option to shiftadd, which would ensure that no interpolation is performed and flux is perfectly conserved. (I had one instance of a user who used shiftadd without really knowing what he was doing, and resulted in smoothing the data and washing out a faint source that he was searching for - an integer-pixel-shift option (perhaps also making this the default?), would have avoided this.)

[StuartLittlefair]

Actually having looked into this, we do already support integer pixel shifts.

There are three interpolation methods, interp, adaptive and exact.

The default is adaptive, which is flux conserving, but can (and often does) smooth the data.

If you choose interp as the method, the order of interpolation is set by a hidden parameter, reprorder.
Setting reprorder = 0 means using nearest-neighbour interpolation (e.g integer pixel shifts).

I guess it's an open question as to if this should be the default or not? It might be worth experimenting with some comparisons to see