Mailman 3 August 2017 - scikit-image

Re: [scikit-image] Numba on pypi
by Nelle Varoquaux 14 Aug '17

14 Aug '17

On 14 August 2017 at 16:34, Matthew Brett <matthew.brett(a)gmail.com> wrote: > Hi, > > On Fri, Jul 14, 2017 at 1:29 AM, Ralf Gommers <ralf.gommers(a)gmail.com> wrote: >> >> >> On Fri, Jul 14, 2017 at 8:15 PM, Matthew Brett <matthew.brett(a)gmail.com> >> wrote: >>> >>> Hi, >>> >>> On Thu, Jul 13, 2017 at 9:10 AM, Matthew Brett <matthew.brett(a)gmail.com> >>> wrote: >>> > Hi, >>> > >>> > On Thu, Jul 13, 2017 at 8:50 AM, Ralf Gommers <ralf.gommers(a)gmail.com> >>> > wrote: >>> >> >>> >> >>> >> On Thu, Jul 13, 2017 at 6:16 PM, Stefan van der Walt >>> >> <stefanv(a)berkeley.edu> >>> >> wrote: >>> >>> >>> >>> Hi everyone, >>> >>> >>> >>> As many of you know, speed has been a point of contention in >>> >>> scikit-image for a long time. We've made a very deliberate decision >>> >>> to >>> >>> focus on writing high-level, understandable code (via Python and >>> >>> Cython): both to lower the barrier to entry for newcomers, and to >>> >>> lessen >>> >>> the burden on maintainers. But execution time comparisons, vs OpenCV >>> >>> e.g., left much to be desired. >>> >>> >>> >>> I think we have hit a turning point in the road. Binary wheels for >>> >>> Numba (actually, llvmlite) were recently uploaded to PyPi, making this >>> >>> technology available to users on both pip and conda installations. >>> >>> The >>> >>> importance of this release on pypi should not be dismissed, and I am >>> >>> grateful to the numba team and Continuum for making that decision. >>> >> >>> >> >>> >> Agreed. Note that there are no Windows wheels up on PyPI (yet, or not >>> >> coming?). Given that there are no SciPy wheels for Windows either I >>> >> don't >>> >> think that that changes your argument much - people should just use a >>> >> binary >>> >> distribution on Windows - but I thought I'd point it out anway. >>> > >>> > We might be close to a working scipy wheel - discussion evolving over >>> > at https://github.com/scipy/scipy/issues/7551#issuecomment-314922271 >>> >>> Following up on my own post - updates on progress for a scipy wheel here: >>> >>> https://github.com/scipy/scipy/issues/759 >>> >>> > If we do succeed, that would make the lack of a numba wheel for >>> > Windows much more significant. >>> > >>> > Does anyone know Continuum's plans in this matter? Is the numba >>> > wheel recipe open-source? >>> >>> Can anyone comment here? >>> >>> The basic question is - what would happen if Continuum stopped >>> supplying a pypi wheel? If the answer is the standard open source >>> answer - someone else would take over pretty quickly - that's fine. >>> Otherwise, it's a problem. >> >> >> Can't read their mind, but did look at the build instructions. Doesn't look >> that hard to build and package, if the need arises (which is unlikely). And >> the current wheels will not disappear. So I don't really see an issue. > > Just FYI - after a lot of hard work over at > https://github.com/scipy/scipy/pull/7616 - mostly by Github user > Xoviat - we can now build Scipy wheels for Windows. I guess they'll > come out at the next Scipy release if not before. This is amazing! Thanks for keeping us posted on that. Cheers, N > > Cheers, > > Matthew > _______________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image

1 0

Re: [scikit-image] Numba on pypi
by Matthew Brett 14 Aug '17

14 Aug '17

Hi, On Fri, Jul 14, 2017 at 1:29 AM, Ralf Gommers <ralf.gommers(a)gmail.com> wrote: > > > On Fri, Jul 14, 2017 at 8:15 PM, Matthew Brett <matthew.brett(a)gmail.com> > wrote: >> >> Hi, >> >> On Thu, Jul 13, 2017 at 9:10 AM, Matthew Brett <matthew.brett(a)gmail.com> >> wrote: >> > Hi, >> > >> > On Thu, Jul 13, 2017 at 8:50 AM, Ralf Gommers <ralf.gommers(a)gmail.com> >> > wrote: >> >> >> >> >> >> On Thu, Jul 13, 2017 at 6:16 PM, Stefan van der Walt >> >> <stefanv(a)berkeley.edu> >> >> wrote: >> >>> >> >>> Hi everyone, >> >>> >> >>> As many of you know, speed has been a point of contention in >> >>> scikit-image for a long time. We've made a very deliberate decision >> >>> to >> >>> focus on writing high-level, understandable code (via Python and >> >>> Cython): both to lower the barrier to entry for newcomers, and to >> >>> lessen >> >>> the burden on maintainers. But execution time comparisons, vs OpenCV >> >>> e.g., left much to be desired. >> >>> >> >>> I think we have hit a turning point in the road. Binary wheels for >> >>> Numba (actually, llvmlite) were recently uploaded to PyPi, making this >> >>> technology available to users on both pip and conda installations. >> >>> The >> >>> importance of this release on pypi should not be dismissed, and I am >> >>> grateful to the numba team and Continuum for making that decision. >> >> >> >> >> >> Agreed. Note that there are no Windows wheels up on PyPI (yet, or not >> >> coming?). Given that there are no SciPy wheels for Windows either I >> >> don't >> >> think that that changes your argument much - people should just use a >> >> binary >> >> distribution on Windows - but I thought I'd point it out anway. >> > >> > We might be close to a working scipy wheel - discussion evolving over >> > at https://github.com/scipy/scipy/issues/7551#issuecomment-314922271 >> >> Following up on my own post - updates on progress for a scipy wheel here: >> >> https://github.com/scipy/scipy/issues/759 >> >> > If we do succeed, that would make the lack of a numba wheel for >> > Windows much more significant. >> > >> > Does anyone know Continuum's plans in this matter? Is the numba >> > wheel recipe open-source? >> >> Can anyone comment here? >> >> The basic question is - what would happen if Continuum stopped >> supplying a pypi wheel? If the answer is the standard open source >> answer - someone else would take over pretty quickly - that's fine. >> Otherwise, it's a problem. > > > Can't read their mind, but did look at the build instructions. Doesn't look > that hard to build and package, if the need arises (which is unlikely). And > the current wheels will not disappear. So I don't really see an issue. Just FYI - after a lot of hard work over at https://github.com/scipy/scipy/pull/7616 - mostly by Github user Xoviat - we can now build Scipy wheels for Windows. I guess they'll come out at the next Scipy release if not before. Cheers, Matthew

1 0

Re: [scikit-image] ValueError: too many values to unpack for measure.marching_cubes
by Egor Panfilov 07 Aug '17

07 Aug '17

Hi, Functions in Python return objects packed in a tuple. When you write `verts, faces = marching_cubes(...)`, Python computes `marching_cubes(...)`, takes the output, and tries to unpack it (i.e. to assign to the names on the left-hand side of `=`) to 2 objects. The error tells you that the number of objects in a returned tuple is too high (>2). Here is an example to better understand the issue: In [1]: a, b = (1, 2) In [2]: a, b, c = (1, 2) --------------------------------------------------------------------------- ValueError Traceback (most recent call last) <ipython-input-5-26c544669ffc> in <module>() ----> 1 a, b, c = (1, 2) ValueError: not enough values to unpack (expected 3, got 2) In [3]: a, b = (1, 2, 3) --------------------------------------------------------------------------- ValueError Traceback (most recent call last) <ipython-input-6-2ecd6d570722> in <module>() ----> 1 a, b = (1, 2, 3) ValueError: too many values to unpack (expected 2) In skimage 0.13, as far as I remember, `marching_cubes` is actually an alias to `marching_cubes_lewiner` ( http://scikit-image.org/docs/dev/api/skimage.measure.html#skimage.measure.m…) which returns 4 objects, not 2. In skimage 0.14dev we've already removed this alias. You should either use `marching_cubes_classic` (not recommended), or update your code to use `marching_cubes_lewiner` and unpack the output to 4 variables. Regards, Egor 2017-08-07 17:16 GMT+03:00 wine lover <winecoding(a)gmail.com>: > Hello, > > I have been trying to follow the tutorial here https://www.kaggle.com/ > gzuidhof/full-preprocessing-tutorial > > However, verts, faces, , = measure.marching_cubes(p, threshold) in the > function of plot_3d gives the following error message > > File "guidozuidhof_fullprocessing.py", line 90, in plot_3d > verts, faces = measure.marching_cubes(p, threshold) > ValueError: too many values to unpack > > > What does that mean, and how to solve it, thanks a lot! > > _______________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image > >

1 0

ValueError: too many values to unpack for measure.marching_cubes
by wine lover 07 Aug '17

07 Aug '17

Hello, I have been trying to follow the tutorial here https://www.kaggle.com/gzuidhof/full-preprocessing-tutorial However, verts, faces, , = measure.marching_cubes(p, threshold) in the function of plot_3d gives the following error message File "guidozuidhof_fullprocessing.py", line 90, in plot_3d verts, faces = measure.marching_cubes(p, threshold) ValueError: too many values to unpack What does that mean, and how to solve it, thanks a lot!

1 0

Re: [scikit-image] plot_matches() error?
by Stefan van der Walt 04 Aug '17

04 Aug '17

Hi Riley On Thu, Aug 3, 2017, at 14:31, Riley Myers wrote: > I'm currently using matplotlib 2.0.2, which seems to be the most > recent that I can get with `conda install` or `conda> update`. Should I take this up with their development team instead? > > As before: > >>> import matplotlib print(matplotlib.__version__) > 2..2 The error does seem to result in a change between skimage 0.13 and 0.14dev0. Here is the relevant patch: commit dcec9cdfd630f555216eb4105652fceb0f943dac Author: Gregory R. Lee <grlee77(a)gmail.com> Date: Fri May 5 08:53:30 2017 -0400 BUG: make the color array in plot_matches 1D Using a 2D array is unecessary and causes a crash for Matplotlib 2.0.1 diff --git a/skimage/feature/util.py b/skimage/feature/util.py index b0c66986..fdb1b67e 100644 --- a/skimage/feature/util.py +++ b/skimage/feature/util.py @@ -114,7 +114,7 @@ def plot_matches(ax, image1, image2, keypoints1, keypoints2, matches, idx2 = matches[i, 1] if matches_color is None: - color = np.random.rand(3, 1) + color = np.random.rand(3) else: color = matches_color Your options are: 1. Use the attached version of plot_matches or 2. to upgrade to the source version of scikit-image Best regards Stéfan

1 0

Re: [scikit-image] plot_matches() error?
by Stefan van der Walt 03 Aug '17

03 Aug '17

Hi Riley I should have checked your stacktrace earlier. It looks like Matplotlib is responsible. What version of that package are you running, and can you try and upgrade to the latest version? Stéfan On Thu, Aug 3, 2017, at 07:39, Riley Myers wrote: > Sure - here it is. > > Python 3.5.3 |Continuum Analytics, Inc.| (default, Mar 6 2017, > 11:58:13) [GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux Type "help", > "copyright", "credits" or "license" for more information. > >>> import skimage print(skimage.__version__) > .13.0 > >>> > >>> import numpy print(numpy.__version__) > 1.13.1 > >>> > >>> import scipy print(scipy.__version__) > .19.1 > >>> >> Thanks again. > Riley > > On Wed, Aug 2, 2017 at 5:15 PM, Stefan van der Walt > <stefanv(a)berkeley.edu> wrote:>> __ >> Thanks! This works perfectly on my system. Can you share the >> output of:>> >> import skimage >> print(skimage.__version__) >> >> import numpy >> print(numpy.__version__) >> >> import scipy >> print(scipy.__version__) >> >> Thanks! >> Stéfan >> >> On Wed, Aug 2, 2017, at 15:20, Riley Myers wrote: >>> Ok - I've attached the code, and the images necessary to run it, in >>> a tarball. The images (and the code) are taken from the skimage- >>> tutorials available on github at >>> https://github.com/scikit-image/skimage-tutorials - specifically lectures/adv3_panorama- >>> stitching.ipynb.>>> Thanks! >>> Riley >>

1 0

Re: [scikit-image] plot_matches() error?
by Riley Myers 03 Aug '17

03 Aug '17

Sure - here it is. Python 3.5.3 |Continuum Analytics, Inc.| (default, Mar 6 2017, 11:58:13) [GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import skimage >>> print(skimage.__version__) 0.13.0 >>> >>> import numpy >>> print(numpy.__version__) 1.13.1 >>> >>> import scipy >>> print(scipy.__version__) 0.19.1 >>> Thanks again. Riley On Wed, Aug 2, 2017 at 5:15 PM, Stefan van der Walt <stefanv(a)berkeley.edu> wrote: > Thanks! This works perfectly on my system. Can you share the output of: > > import skimage > print(skimage.__version__) > > import numpy > print(numpy.__version__) > > import scipy > print(scipy.__version__) > > Thanks! > Stéfan > > On Wed, Aug 2, 2017, at 15:20, Riley Myers wrote: > > Ok - I've attached the code, and the images necessary to run it, in a > tarball. The images (and the code) are taken from the skimage-tutorials > available on github at https://github.com/scikit-image/skimage-tutorials > - specifically lectures/adv3_panorama-stitching.ipynb. > Thanks! > Riley > > >

1 0

Re: [scikit-image] plot_matches() error?
by Stefan van der Walt 02 Aug '17

02 Aug '17

Thanks! This works perfectly on my system. Can you share the output of: import skimage print(skimage.__version__) import numpy print(numpy.__version__) import scipy print(scipy.__version__) Thanks! Stéfan On Wed, Aug 2, 2017, at 15:20, Riley Myers wrote: > Ok - I've attached the code, and the images necessary to run it, in a > tarball. The images (and the code) are taken from the skimage- > tutorials available on github at > https://github.com/scikit-image/skimage-tutorials - specifically lectures/adv3_panorama- > stitching.ipynb.> Thanks! > Riley

1 0

Re: [scikit-image] plot_matches() error?
by Riley Myers 02 Aug '17

02 Aug '17

Ok - I've attached the code, and the images necessary to run it, in a tarball. The images (and the code) are taken from the skimage-tutorials available on github at https://github.com/scikit-image/skimage-tutorials - specifically lectures/adv3_panorama-stitching.ipynb. Thanks! Riley On Wed, Aug 2, 2017 at 2:06 PM, Stefan van der Walt <stefanv(a)berkeley.edu> wrote: > Hi Riley > > On Wed, Jul 26, 2017, at 11:35, Riley Myers wrote: > > I am currently having a bit of trouble with using scikit-image to align > two images using ORB. At the moment, if I try to plot the images, keypoints > and matches using plot_matches, I get a plot with only the images and the > keypoints and then a large stack trace, attached below. I thought that my > code might be the problem, but the same thing occurs if I run one of the > ipython notebooks from the skimage-tutorials, specifically > /lectures/adv3_panorama-stitching.ipynb, using all of their images, etc. > This seems to imply that something is off with my setup. According to > `conda list`, I'm using version 0.13.0 of scikit-image. Do any of you have > any ideas? > > > Please provide a minimal example that produces this error, then we will > investigate further. > > Stéfan > >

1 0

Re: [scikit-image] plot_matches() error?
by Stefan van der Walt 02 Aug '17

02 Aug '17

Hi Riley On Wed, Jul 26, 2017, at 11:35, Riley Myers wrote: > I am currently having a bit of trouble with using scikit-image to > align two images using ORB. At the moment, if I try to plot the > images, keypoints and matches using plot_matches, I get a plot with > only the images and the keypoints and then a large stack trace, > attached below. I thought that my code might be the problem, but the > same thing occurs if I run one of the ipython notebooks from the skimage- > tutorials, specifically /lectures/adv3_panorama-stitching.ipynb, using > all of their images, etc. This seems to imply that something is off > with my setup. According to `conda list`, I'm using version 0.13.0 of > scikit-image. Do any of you have any ideas? Please provide a minimal example that produces this error, then we will investigate further. Stéfan

1 0