On Tue, Apr 19, 2011 at 3:54 PM, Chris Colbert <sccolbert@gmail.com> wrote:

Hmmm, I'm not too sure of the need for this, given that ndimage already has a Sobel and Prewitt filter which are implemented via separable 1D convolutions (and will thus be faster than a 2D convolution).

I think there was a concern about the directionality of the scipy.ndimage implementation. Maybe we can modify the version in the scikit to make use of the scipy.ndimage one, but to compute the horizontal, vertical and averaged sobels?

I can see this being useful if we want to remove the dependency on ndimage at some point, once we have our own fast convolution routine (or just have a convolution that is faster that the one in ndimage). However in that case, I think these two filters should still be implemented as separable 1D filters.

I have someone looking at GPU-based convolution; let's hope that pans out. Regards Stéfan

what type of post-processing are you doing? It looks to me like you are getting wrap-around error. The sobel output is signed and will have negative values. 2011/4/19 Stéfan van der Walt <stefan@sun.ac.za>

2011/4/19 Stéfan van der Walt <stefan@sun.ac.za>:

...

I think there was a concern about the directionality of the scipy.ndimage implementation. Maybe we can modify the version in the scikit to make use of the scipy.ndimage one, but to compute the horizontal, vertical and averaged sobels?

Looking at this further, I am not happy with the result of either scikits.image or scipy.ndimage:

http://mentat.za.net/refer/sobel.jpg

Compare this, e.g., to the wikipedia page here:

http://en.wikipedia.org/wiki/Sobel_operator

Stéfan

2011/4/19 Stéfan van der Walt <stefan@sun.ac.za>:

Looking at this further, I am not happy with the result of either scikits.image or scipy.ndimage:

http://mentat.za.net/refer/sobel.jpg

Compare this, e.g., to the wikipedia page here:

http://en.wikipedia.org/wiki/Sobel_operator

Apparently, neither of these routines like integer images as inputs (should be mentioned in the docs). Here's the output for float images: http://mentat.za.net/refer/sobel2.jpg Looking at that wikipedia page, it might be easy to add some of the other methods that are less sensitive to direction--we only need to update the masks. Regards Stéfan

On Tue, Apr 19, 2011 at 5:33 PM, Chris Colbert <sccolbert@gmail.com> wrote:

supporting integer images is a must IMO.

For now, I just cast the inputs to float--but that's a bad solution. Sobel can be done using integer arithmetic, which should make it even faster.

Goodluck making something faster than ndimage without considerable effort (I've already tried in Cython and was 10x slower). I read the ndimage source and it goes to great lengths to make optimum use of the cpu cache by allocating line buffers etc... What we need is to find a fast open source routine, wrap it with Cython, and package it with the scikit. I wouldn't suggest using the one from OpenCV unless we are desperate because it's implemented as a c++ filtering engine. However, they are using sse2 intrinsics and it's fast! Like 10x+ faster than ndimage. 2011/4/19 Stéfan van der Walt <stefan@sun.ac.za>

2011/4/19 Stéfan van der Walt <stefan@sun.ac.za>:

...

Apparently, neither of these routines like integer images as inputs (should be mentioned in the docs). Here's the output for float images:

To be more specific, scipy.ndimage.convolve does not upcast appropriately when convolving integer arrays with floating point arrays. This alone seems like a good enough reason to have our own version, although I agree that we should use the 1D separated filters.

It doesn't look as if there is an easy way to coerce numpy.convolve to do the job, so I guess I should write something in Cython?

Regards Stéfan

I would like to see the scikit become an ndimage replacement, however that would require us evolving to support nd-images rather than 2D images. Not something I'd be opposed to necessary. In truth, there isn't a whole lot of functionality in ndimage, and ignoring the nd part, we could implement all of it ourselves quite easily; a fast convolution being the barrier to entry. On Tue, Apr 19, 2011 at 1:16 PM, James Turner <jturner@gemini.edu> wrote:

Hi Stefan & Chris,

I hope this isn't too OT, but it's interesting that people would rather re-implement bits of ndimage than try to improve it. Maybe it's just too much work for a small part of the functionality. Can/should the scikit be viewed as a possible ndimage replacement in the longer run? Ndimage is a bit of a worry for me, since we need the type of functionality it provides but I'm not optimistic about having resources to help maintain its code in the near future.

Just curious.

Thanks!

James.

On 19/04/11 12:45, Chris Colbert wrote:

...

Goodluck making something faster than ndimage without considerable effort (I've already tried in Cython and was 10x slower). I read the ndimage source and it goes to great lengths to make optimum use of the cpu cache by allocating line buffers etc...

What we need is to find a fast open source routine, wrap it with Cython, and package it with the scikit. I wouldn't suggest using the one from OpenCV unless we are desperate because it's implemented as a c++ filtering engine. However, they are using sse2 intrinsics and it's fast! Like 10x+ faster than ndimage.

2011/4/19 Stéfan van der Walt <stefan@sun.ac.za <mailto:stefan@sun.ac.za

...

...

2011/4/19 Stéfan van der Walt <stefan@sun.ac.za <mailto: stefan@sun.ac.za>>:

> Apparently, neither of these routines like integer images as inputs > (should be mentioned in the docs). Here's the output for float > images:

To be more specific, scipy.ndimage.convolve does not upcast appropriately when convolving integer arrays with floating point arrays. This alone seems like a good enough reason to have our own version, although I agree that we should use the 1D separated filters.

It doesn't look as if there is an easy way to coerce numpy.convolve to do the job, so I guess I should write something in Cython?

Regards Stéfan

On Tue, Apr 19, 2011 at 8:03 PM, James Turner <jturner@gemini.edu> wrote:

I do rely on the ND part myself, but only for the "interpolation" routines in 3D (I also use "filters" in 2D). Generalizing understandable 2D interpolation code to work for 3D/ND might be a more realistic thing for me to help with in future, though, than contributing to ndimage (it's always tough to find time, but it seems more of a bite-sized problem). I suppose the question is just whether you and Stefan want to support >2D at all...

I wouldn't be opposed to adding 3D support for some routines; I just don't want to have it as a requirement, otherwise we may never reach 1.0 :) Cheers Stéfan