>They are also all doable pretty easily with GalSim before passing the image into InterpolatedImage.

You can say the same thing about any of the options currently active for this kwarg.  I still think it's more useful and intuitive to have an directly passable to the `SBInterpolatedImage` via `pad_image`, and there's a consistency argument too: images passed in will that way adopt the `SBInterpolatedImage` internal conventions for centring the `image` within the `pad_image`.  It makes sense to me to have a clear way for the user to get easy access to the same conventions regarding centring as used when auto-generating an image for `pad_image`.

Perhaps `noise_pad` is not in fact the correct place for this, I'm not sure about that.  But I do think there should be a place somewhere for this functionality.  

Now, I sense reluctance to make this change: so be it, I don't have much more to say and have to accept being outvoted. I still believe that this is a small change that adds generality in a consistent way (i.e. it's not just cosmetic), that mirrors the C++ layer functionality (which is clearly useful as we're using it now), and is therefore better than providing a duplicate interface to the `ImageCorrFunc` (one that may actually encourage inefficient reinitialization of the `ImageCorrFunc` from the same image multiple times).

>Presumably if you were doing this, you would use pad_factor=1, since you've already padded it with the pad_image.

I'd go so far as to suggest shooting a warning if `pad_factor` was *not* 1, saying that we ignore any non-unity value for `pad_factor` when taking an image for direct padding.