I agree with wrappers, ideally with minimal changes to SciPy's API. Of course this means that if SciPy changes their API or re-implements something (like the change of `scipy.ndimage.label` coming in 0.13), we encounter problems... but in general this saves us from needing to reinvent and maintain the wheel. 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<javascript:>
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.
Abid K. opencvpython.blogspot.com
On Wed, Apr 24, 2013 at 3:49 AM, Stéfan van der Walt <ste...@sun.ac.za<javascript:>
wrote:
On Tue, Apr 23, 2013 at 11:49 PM, Emmanuelle Gouillart <emmanuelle...@nsup.org <javascript:>> 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
-- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image...@googlegroups.com <javascript:>. For more options, visit https://groups.google.com/groups/opt_out.
-- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image...@googlegroups.com <javascript:>. For more options, visit https://groups.google.com/groups/opt_out.
On Wed, Apr 24, 2013 at 4:16 PM, Josh Warner <silvertrumpet999@gmail.com>wrote:
(like the change of `scipy.ndimage.label` coming in 0.13)
Huh? For the less-informed among us, could you elaborate? A quick Googling was not informative... And I have (approximately) 5 bajillion functions that depend on `nd.label`. =) 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?
I hadn't considered this but it makes a lot of sense, as it potentially slowly decouples scikit-image from its scipy dependency.
participants (2)
-
Josh Warner -
Juan Nunez-Iglesias