If this were to be implemented, would our policy then be to use relative imports for the wrapped versions of these functions internally, rather than importing from SciPy?
On Tuesday, April 23, 2013 11:29:01 PM UTC-5, Juan Nunez-Iglesias wrote:
I'm in the middle on this: I would suggest importing the relevant ndimage functions into the skimage namespace, but not touching the API, except perhaps in extremely egregious cases. Just as the lack of a Gaussian filter might confuse beginners, two divergent APIs will confuse advanced users.
On Wed, Apr 24, 2013 at 11:41 AM, abid rahman
<abidr...@gmail.com> wrote:
Hi,
Isn't it a bad idea that for some functions we should go for scipy, for some other functions we go for skimage. Actually what I felt from user-point-of-view is to decrease maximum dependency in the project. So it is always better to bring all image processing stuffs in python under one library. Installation of one library should serve all our purpose.
On Wed, Apr 24, 2013 at 3:49 AM, Stéfan van der Walt
<ste...@sun.ac.za> wrote:
On Tue, Apr 23, 2013 at 11:49 PM, Emmanuelle Gouillart
<
emmanuelle...@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.
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