> 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.
> Are you just balking at the possibility of passing in an Image that is already in memory, but isn't yet converted to an ImageCorrFunc? I guess that just seemed like a logical intermediate option without a specific application in mind.
> 
> Yes. I would rather see the user free to specify any image, not to be interpreted as input for an ImageCorrFunc (which is already covered) but to be used for the padding as is. Sent directly to pad_image, in other words. This seems potentially more valuable as it's general and doesn't duplicate what can already be done by either passing a string or passing an ImageCorrFunc.
> 
As Mike said, the functionality for passing in an image (or rather a string containing an image to be made into an ImageCorrFunc) was largely meant to enable using this noise-padding functionality via config.  I agree that from the perspective of the python interface alone it's kind of silly to save the user that one line of making an ImageCorrFunc, and at the same time it is also more restrictive since they don't have control over the ImageCorrFunc keywords.

Sorry to be stupid, but can you give me an example of how this functionality of specifying an image to be used directly (i.e., deterministically) for noise-padding would be used?  If we're writing a script in python, then I envision the most-used routes would be to pass in either a float for a Gaussian noise variance, or an ImageCorrFunc that we've constructed using whatever set of keywords we want.  If we're using config, then passing in a file seems like the only way to do noise padding, but it seems unlikely that we will have saved sets of noise fields to use - it seems a lot more likely that we'll want to make an ImageCorrFunc corresponding to some noise covariance matrix in an image of blank sky.

Having said all that, one option would be to add another keyword called something like 'pad_deterministic' that does the following:
If 'noise_pad' is a string for a filename or is an Image, then 'pad_deterministic=True' means to use that image itself for the noise padding (if it's big enough, making some reasonable but necessarily arbitrary choice for which bits are used for the padding) whereas 'pad_deterministic=False' means to make an ImageCorrFunc and generate the noise field from it using an RNG.  I think this would still work with config, as long as config is told about the new keyword.

Would this change solve the problem, in your opinion?  I am willing to do this, but to be honest I don't see myself using this much, so would like some feedback on whether this option makes sense.  (Or, perhaps I'm being ridiculous and there's an obvious use case that I'm missing?)