[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.
More information about the Scipy-tickets
mailing list