Adding equivalent filters from scipy.ndimage.filters

Would be great to support some common filters from scipy.ndimage.filters. Having convolve, correlate and generic_filter would be great and allow users to build up many common convolutions with relatively little work using a familiar API. There are others that would be very nice as well.

[grlee77]

Hi @jakirkham. Do you have an immediate need for this or a particular use case in mind?

I recently implemented the equivalent of ndi.convolve (built using a GPU-based implementation of scipy.signal.upfirdn(..., up=1, down=1) under the hood) that supports float32, float64, complex64 and complex128. I haven’t tried to make a PR for it here or posted it publicly, but can share it if you are interested in collaborating on it.

I implemented scipy.signal.upfirdn using CuPy and added support for various signal extension modes at the boundary (not currently available in SciPy’s upfirdn). In my case, I started implementing a library expanding the functionality in PyWavelets. The version of upfirdn I have currently only supports downsampled convolution with up=1, down=M or upsampled convolution with up=M, down=1 as those were the only cases I needed for M-band wavelet filterbanks. With a bit more effort, it could be updated to allow the general setting of any positive integer up, down and become suitable for a PR here.

[grlee77]

I finally got around to cleaning things up and making a public repo for some of the things I mentioned about a year ago (better late than never!). A CPU + GPU implementation of upfirdn is in the fast_upfirdn package. It differs from the implementation in cusignal in that the GPU implementation uses cupy.RawKernel instead of Numba.

Building on top of this, cupyimg implements a ton of other functions, primarily from scipy.ndimage, scipy.signal and scikit-image.

I have been working on getting some scipy.ndimage and NumPy stuff that was needed implemented as PRs here so that they can benefit from better code review and CI testing. Currently cupyimg does not have CI and I have just been running tests locally on linux. There are quite a few tests copied from the corresponding CPU-based packages, but these do not typically conform to the CuPy style, so getting things ready for PR here would still require quite a bit of work. There is also a substantial amount of kernel code duplication that could be avoided by refactoring of the type done by @coderforlife in #3184.

I think scikit-image functions are out of scope for CuPy itself. I’m not too sure about the viability of maintaining a parallel fork long-term without obtaining any official funding/support to do so, but wanted to try out at least a subset of the library that is built on top of scipy.ndimage functions.