On Feb 6, 2013, at 5:31 AM, Barnaby Rowe <notifications@github.com> wrote:

> In galsim/base.py:
> 
> > @@ -1384,15 +1391,45 @@ class InterpolatedImage(GSObject):
> >      choose interpolants and pad factors, and no warnings are raised when the code is modified to
> >      choose some combination that is known to give significant error.
> >  
> > +    The user can choose to have the image padding use zero (default), Gaussian random noise of some
> > +    variance, or a Gaussian but correlated noise field that is specified either as an ImageCorrFunc,
> > +    an Image (from which a noise correlation function is derived), or a string (interpreted as a
> > +    filename containing an image to use for deriving the noise correlation function).  The user can
> > +    also pass in a random number generator to be used for noise generation.
> 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.
> 
I hear you on this.
> 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 don't know about Mike, but my argument was largely on the basis of not seeing the need.  You've made some good points and I wouldn't object to doing some variant of what you said.
> 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).
> 
Okay… we put that interface to enable config to use this functionality in some way, but would it perhaps change things for you at all if we were to document emphatically that for python users, it's far better to make their own ImageCorrFunc to be passed in for multiple calls (rather than using the Image for multiple calls)?
> 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.
> 
Right.