[SciPy-Dev] Evolution of the generic_filter function

Zachary Pincus zachary.pincus@yale....
Wed Mar 31 09:09:16 CDT 2010

> Now, my question. It seems that the function  
> "scipy.ndimage.generic_filter" can only operate onto scalar objets  
> like float or int. Moreover, it returns only float objects. Do you  
> think that, in the near future, this function will be able to treat  
> generic objects like tuples or user classes ? In that case, we will  
> be able to treat directly, for example, vector fields or color  
> images. We will also be able to apply a function onto multiple  
> arrays at the same time, with the same windowing. Then, to my mind,  
> this method will become very powerful for image processing tools.

This change doesn't appear to be on anyone's radar yet... though I'm  
sure patches might be accepted! (But beware: ndimage is a pretty  
tangled codebase on the C side of things, which is why lots of  
improvements like this haven't been made.)

However, note that the generic_filter function is a performance  
disaster: it applies a *python* function to every element in an  
array... very slow. (As would be a vectorized replacement which took a  
"vector_axis" keyword, or one which worked on structured arrays.)

You might want to think about implementing in cython a replacement  
"generic_filter" (with vector arguments, of course), that could apply  
cdef'd functions (all within cython), if performance matters. There's  
some new mechanisms in the numpy C api for neighborhood iterators that  
would be useful for filtering like this, too. (But with limited  
options for boundary conditions.)

Alternately, here's a sketch of a technique I have used for "in- 
parallel" filtering in pure python. Note that there are no boundary  
conditions handled here, but you could deal with that:

a = numpy.random((100, 100, 2))
center = a[1:-1, 1:-1]
left = a[:-2, 1:-1]
right = a[2:, 1:-1]
up = a[1:-1, :-2]
down = a[1:-1, 2:]
boxfiltered_a = (center + left + right + up + down) / 5.

(obviously you could do this more elegantly / generically, but this is  
the idea...)

Or, perhaps you could figure out how to decompose the vectorized  
filtering operations you need into filtering on the individual  
components, then combining the components in parallel?


More information about the SciPy-Dev mailing list