Dear all, a while ago, a PR from Riaan van den Dool proposed to have a Gaussian filter in scikit-image. At this time, I remember that I felt that it was not necessary to have a Gaussian filter in the scikit-image, since there is already one in scipy.ndimage. Many people shared this opinion, and the PR was turned down. However, I have gradually changed my opinion on this matter, and I would like to know what the other developers and users think. I've recently given a tutorial / practical session on scikit-image to an audience of Python beginners (undergraduate teachers who will have to teach Python next year, since Python is now part of the French syllabus for undergraduate scientific studies). And it was very puzzling to them that some functions, such as the Gaussian filter, were not to be found in skimage, but in scipy.ndimage. They had no problem understanding that generic low-level arrays routines were in numpy, and specialized image processing functions in skimage, but they felt like scipy.ndimage was an unnecessary complication! Of course, these users are not representative of all skimage's users, but since Python is getting more and more popular in science, we'll have more and more users who'll prefer finding all high-level image processing functions under skimage's umbrella. I can see only a small number of scipy.ndimage functions that are concerned, like gaussian_filter, distance_transform_edt, binary_fill_holes, but I now think that it'd be worth having a wrapper for these functions in skimage, for the sake of users not well aware of scipy.ndimage. We already depend on scipy anyway. What do you think? Cheers, Emmanuelle
On Tue, Apr 23, 2013 at 11:49 PM, Emmanuelle Gouillart <emmanuelle.gouillart@nsup.org> wrote:
I can see only a small number of scipy.ndimage functions that are concerned, like gaussian_filter, distance_transform_edt, binary_fill_holes, but I now think that it'd be worth having a wrapper for these functions in skimage, for the sake of users not well aware of scipy.ndimage. We already depend on scipy anyway.
I'd be happy to put wrappers to those functions in skimage, as long as we do a thorough review of the API of each. That turns out to be one of skimage's strongest benefits, and we shouldn't rely on ndimage to have considered it very carefully. I think it would help if we had some practical use cases of each of these, to guide us in the right direction. But yes, I can see how this would confuse beginners... Stéfan
participants (2)
-
Emmanuelle Gouillart
-
Stéfan van der Walt