[Scipy-tickets] [SciPy] #1641: Unexpected behavior in ni_filters.c/NI_Correlate

SciPy Trac scipy-tickets@scipy....
Mon Apr 16 03:51:46 CDT 2012

#1641: Unexpected behavior in ni_filters.c/NI_Correlate
 Reporter:  eschlafly      |       Owner:  somebody   
     Type:  defect         |      Status:  new        
 Priority:  normal         |   Milestone:  Unscheduled
Component:  scipy.ndimage  |     Version:  0.9.0      
 Keywords:                 |  

Comment(by thouis):

 The behavior is being caused by this code in NI_Correlate(), which
 calculates the footprint of the filter before copying the filter into a
 contiguous block:

 for(jj = 0; jj < fsize; jj++) {
         if (fabs(pw[jj]) > DBL_EPSILON) {
             pf[jj] = 1;
         } else {
             pf[jj] = 0;

 As a workaround, one can normalize the filter first (divide by the
 smallest nonzero element, for instance), and correct the result afterward.

 I think the most straightforward way to address this behavior is to change
 the comparison above to use 0.0 instead of DBL_EPSILON.  One might also
 compare to the largest filter entry (i.e., normalize by the maximum
 absolute value of the filter), but this could still lead to unexpected
 behavior with wide filters being applied to images with single bright

 The drawbacks to this change are:
 1- change in results from the correlate2d function.
 2- potentially slower performance when using filters with nonzero-but-
 small values.

 I don't think the values should change that much, except in corner cases
 (and in those cases, it's already doing something that might be considered
 incorrect), so #1 is probably not a great concern.

 I don't think the performance change should be too drastic, either.  The
 footprint calculation above is primarily a heuristic optimization.  In
 eschlafly's case, the heuristic is failing.  The performance might drop
 noticeably in the case that someone is using:
 - a large filter,
 - with many nonzero entries,
 - only a few of which are above DBL_EPSILON.
 I think this is probably a very limited risk.  Worst case, the performance
 of correlation might drop to its expected performance (i.e., without any
 heuristic based on nonzero footprint).  Someone actually using such a
 filter should probably be using FFT methods, anyway.

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

More information about the Scipy-tickets mailing list