[SciPy-User] magnifying image patches, ndimage.zoom() shouldn't use boundary conditions

Kay F. Jahnke _kfj at yahoo.com
Wed Dec 7 05:56:29 EST 2011


Hi group!

I want to use ndimage.zoom to magnify small patches of a larger image. This
works just fine, except for the patch boundaries. Here is what happens: if I
have an image img (let's assume its 1000X1000) and I want to magnify the patch
img[500:600, 500:600], zoom applies boundary conditions on the margin of the
patch, i.e. assumes surrounding pixels are same, mirror-imaged etc.

In this special use scenario, though, the surrounding pixels aren't unknown and
the application of the boundary condition leads to false results. I can work
around the problem by zooming a larger patch and taking only the central section
of the zoom's result, but this is wasteful.

A way to avoid the problem would be to set up the spline underlying the zoom
operation on a larger patch, but only evaluate it for the desired output patch
area. I can do this using routines from other packages, but there I am missing a
routine to evaluate the spline over a regularly spaced grid, which I suppose is
most efficient - instead I have to calculate x and y vectors and feed them into
the spline evaluation routine. (I may have overlooked something here, if so,
please let me know)

I'd wish for a variant of the zoom routine which lets me specify a source image
and a rectangular patch on it to be zoomed. This way, an appropriately enlarged
spline could be used and boundary conditions would only be applied when the
actual image border is hit. This would be the prototype:

scipy.ndimage.interpolation.zoom(input, zoom, patch=None, ...)

with patch being a tuple of (min,max) pairs to define the slice of the input to
operate on (the default being None to signify that the whole image should be
zoomed and to keep the call signature compatible), so for my example 2D image I
could call it like

zoom ( img , ((500,600), (500,600)) , ... )

Since I suppose that zooming patches of images if a fairly common application, I
feel this addition would be sensible.

Kay
 




More information about the SciPy-User mailing list