# [Scipy-tickets] [SciPy] #515: ndimage.zoom introduces artefacts at right and bottom edges

SciPy scipy-tickets@scipy....
Wed Oct 17 19:32:56 CDT 2007

```#515: ndimage.zoom introduces artefacts at right and bottom edges
---------------------------------------------------+------------------------
Reporter:  0ion9                                  |        Owner:  stefan
Type:  defect                                 |       Status:  assigned
Priority:  normal                                 |    Milestone:  0.7
Component:  scipy.ndimage                          |      Version:  devel
Severity:  normal                                 |   Resolution:
Keywords:  ndimage, data, representation, spline  |
---------------------------------------------------+------------------------
Changes (by stefan):

* status:  new => assigned
* owner:  somebody => stefan
* keywords:  => ndimage, data, representation, spline

Comment:

Thanks for reporting this problem.  It is a result of a more complicated
issue: the way we represent images.  Given values

{{{
[[0,1]
[2,3]]
}}},

does the '0' represent a little block/pixel of size 1x1, or does it just
represent a data-point at (0,0).  The code in ndimage confuses the issue
somewhat: it represents the data internally as data-points, but clearly
algorithms like zoom see the data as pixels.

Let me explain further.  Zoom currently functions like this: if the input
size is (m,n) then the output size is (2m,2n).  Therefore, at each
coordinate in the output, the corresponding coordinate in the input is
expected to be (x/2,y/2).  This isn't quite right.  Say that we start with
a (5,5) array, and map it to a (10,10).  Now we are saying that position
(9,9) should map to (4.5,4.5).  But (4.5,4.5) is *outside* the input
array, and that is why you see the zeroes.  If the image were represented
as pixel blocks, (4.5,4.5) would have been valid.

Then, it would seem like a simple matter to change the image
representation to be pixels, instead of data-points.  Unfortunately, that
would require hacking the spline engine.  I'm not sure it would achieve
much, either.  Say you extend your data using a constant value and
interpolate, then zoom would still end up producing a black border around
the bottom edges.

I would therefore propose the following:

1) Input data represent data points.  The borders for

{{{
[[0,1,2],
[3,4,5],
[6,7,8]]
}}}

therefore lie at row 0, column 0, row 2 and column 2 (on top of the
values, not to the left, right, top or bottom of them).  Coordinates like
(2.5,2.5) fall *outside* the image, and must be extended according to the
given mode.

2) All ndimage functions should respect this data-layout.  For example,
zooming by a factor of two should be internally translated to zooming by a
factor of (output_dim - 1)/(input_dim - 1).  This ensures that the input
boundary maps onto the output boundary.

3) Make 'mirror' and 'reflect' extension modes behave the same.  Due to
the data-point representation, only 'reflect' makes any sense (I got this
the wrong way around in the current version):

{{{
Length: 3
Index:         0, 1, 2, 3, 4, 5
Reflect Index: 0, 1, 2, 1, 0, 1
}}}

--
Ticket URL: <http://scipy.org/scipy/scipy/ticket/515#comment:1>
SciPy <http://www.scipy.org/>
SciPy is open-source software for mathematics, science, and engineering.
```