[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;
++filter_size;
} 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
pixels.
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