[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