Guidance regarding downstream package naming and development

Summary

I have few questions for the CuPy team (and RAPIDS/NVIDIA folks) regarding package naming and future plans regarding GPU n-dimensional image processing support. Please let me know if there is a better forum to raise this and feel free to invite others who may be interested to the discussion.

cc’ing a few PFN/NVIDIA/etc. folks who seem to have been interested/involved in past image-processing discussions: @anaruse, @asi1024, @not522, @takagi, @mnicely, @jakirkham, @leofang

Also, @coderforlife for his great recent contributions to CuPy in this area!

I have briefly mentioned a cupyimg package that I have been developing in recent months a few times (most recently https://github.com/cupy/cupy/issues/3526#issuecomment-652604895). cupyimg covers some additional scipy.ndimage functions and a substantial subset of scikit-image. I am planning to continue helping to port some existing NumPy/SciPy functions from cupyimg over to this repository as time permits so that they can benefit from reviewer feedback and CI testing. The plan is to eventually remove those from cupyimg and mainly cover the scikit-image API.

A few questions I would like feedback on:

1.) Does PFN have a problem with the cupyimg name for the package? (I have not released it on PyPI yet and could change the name if needed). Specifically, is the term “cupy” trademarked by PFN and discouraged for use within the name of any downstream modules? I think it is clear from the organization where cupyimg is hosted and the README that this is not an official PFN project, but don’t want to cause issues if the team here feels there is potential for confusion.

2.) My understanding is that CuPy itself intends to only cover NumPy and SciPy functions, but not expand to other scientific packages such as scikit-image, scikit-learn, etc?

3.) If the package evolved to contain mainly scikit-image functionality, that would seem to fit the pattern of RAPIDS proving packages mirroring the API of other popular scientific packages: e.g. cusignal vs. scipy.signal, cuML vs. scikit-learn, etc. Are there already existing plans within the RAPIDS team to create a CUDA equivalent to scikit-image? I was thinking of potential ways to obtain official funding to do this and wondered if there is potential for future collaboration in that direction?

I think there is a lot of potential in the area of n-dimensional image processing on the GPU that is not currently well covered by other packages (e.g. ITK is nD, but has limited GPU capabilities while the Java+OpenCL-based CLIJ has good GPU support but is more limited in the dtypes supported and seems to be 2D/3D only).

[datametrician]

I love this idea. I know @jakirkham would also appreciate this. We’d also be willing to house this in the RAPIDS Github unless PFN wants to be the home of it.

I’m personally partial to cuImage, but that’s just because it follows the RAPIDS simply naming convention. RAPIDS also has no plans to do this, but like cuSignal, we had no plans until @awthomp just did it. This is to say, we have no plans, and would love for someone like you to just do it.

[kkraus14]

Will send an email to kickstart this in the near future. cc @mike-wendt for his visibility as well