Mailman 3 August 2019 - scikit-image

PyConDE 2019
by Lars Grueter 20 Sep '19

20 Sep '19

Hello, I'm thinking about attending PyConDE in Berlin [1] this October and am interested if scikit-image will have a presence/talks there or if there will be a chance to meet anyone from our community. :) Best regards, Lars [1] https://de.pycon.org/

2 2

NumPyDoc validation
by Juan Nunez-Iglesias 13 Sep '19

13 Sep '19

Hi all! There is a thread on the NumPy mailing list discussing a linter that pandas uses for numpydoc docstrings. It sounds super useful and I think we should adopt it. =) https://mail.python.org/pipermail/numpy-discussion/2019-July/079843.html <https://mail.python.org/pipermail/numpy-discussion/2019-July/079843.html> Gaël additionally proposes that this should be pushed to napoleon, a Sphinx now-built-in extension that supports the numpydoc standard. Perhaps we should move to napoleon also. Waiting to hear your thoughts, will propose a PR if people are on board. Juan.

3 3

Euler number and perimeter in measure.regionprops
by Yann GAVET 29 Aug '19

29 Aug '19

Hello all, I found an error (not a bug) in Euler characteristic (denoted euler_number) given by regionprops. It probably comes from a wrong use of the filled_image. Moreover, there is no specification of the connectivity (neighbourhood 4 or 8), and this characteristic strongly depends on it. Matlab (bweuler function) gives different values for SAMPLE test (given in test_regionprops). To summarize, if your object is 4 connected, then the background is 8 connected. But before doing this, I would propose a new perimeter estimation. As you may know, a discrete perimeter is only an estimation. The Crofton perimeter, based on Crofton formula), may be better than the classical way of evaluating the perimeter. Interestingly, Crofton perimeter (in 2 or 4 directions) as well as (another) perimeter can be computed at the same time as the Euler characteristic, in conjonction with the area. The algorithm is based on a convolution (to compute pixels configurations) and a histogram. I have a proposition to submit, based on minkowski functionals and working on 2D (binary) images, I will soon create a pull request, with the following modifications/additions: - correction in Euler number. It will not use the filled image anymore. As a consequence, it will be working on 2D images only. I do not have a working function for 3D images yet. - new crofton perimeter evaluation What do you think of this? What is your suggestion about the common code shared by these two functions, how should I handle it ? I did not find any directory for the measure submodule in doc/examples/. Should/could I create one to illustrate the perimeters evaluation ? thank you best regards yann -- Yann GAVET - Assistant Professor LGF CNRS 5307 - Ecole Nationale Supérieure des Mines de Saint-Etienne 158 Cours Fauriel, CS 62362, 42023 SAINT-ETIENNE cedex 2 Tel: (33) - 4 7742 0170

2 2

New sliding window approach in NumPy
by Stefan van der Walt 27 Aug '19

27 Aug '19

NumPy is discussing a PR on a new sliding window implementation, in case you're interested: https://github.com/numpy/numpy/pull/10771 Stéfan

1 0

ND requirements on new contributions
by Mark Harfouche 09 Aug '19

09 Aug '19

There has been some discussion about having requirements on new contributions being compatible with ND images. This has been discussed in a few PRs on several occasions and I think it warrants a discussion on the mailing list (though I'm the first to admit, I get too many emails and seldom check mailing lists). Feel free to copy paste this as an issue on GitHub. Personally, I think that the ND requirement is too big to impose on contributions and on reviewers. Often, people just need 2D operations. I think what is important is to keep the API forward looking for ND. We can do things like accept tuples for parameters, instead of "x_center", "y_center", or "r_center", "c_center". We can also just throw errors when people pass in higher dimensions images saying that it isn't implemented and contributions are welcome. The second aspect is that ND is actually very computationally expensive. In many cases, people might have an information dense "2D image" and slight variations on other dimensions. This means that using a full blown 2D algorithm is just in efficient on higher dimensions (3D or Time, or color). Optimizing for the different use cases is just tricky, and won't be done correctly if contributors are asked to include something they have no immediate need for. Finally, ND is just weird. Have a listen to this crazy video: https://youtu.be/mceaM2_zQd8

7 11

Skimage draw - perimeter vs area call behavior
by yahbai＠gmail.com 05 Aug '19

05 Aug '19

Hi all, I was just checking the various pairs of calls in draw for drawing either the perimeter or the filled in area (eg draw.polygon() vs polygon_perimeter() ). I noticed that there typically a small set of pixels that are common between the perimeter and the area calls (ie they look like they are meant to be exclusive sets of pixels, but there is usually some overlap). For an example see below. This behavior is seen in at least polygon and ellipse. I couldn't find in the draw docs anywhere where the relationship between pixels in , or whether the design was that there should/shouldn't be any pixels in common between the two. Here is an example: import numpy as np import skimage.draw as draw img = np.zeros((20, 20), dtype=np.uint8) r = np.array([1, 13, 13, 1 ]) c = np.array([1, 1, 14, 13]) rr, cc = draw.polygon(r, c) img[rr, cc] = 1 img2 = np.zeros((20, 20), dtype=np.uint8) rr, cc = draw.polygon_perimeter(r, c) img2[rr, cc] = 1 print(img2+img) [[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] [0 2 2 2 2 2 2 2 2 2 2 2 2 1 0 0 0 0 0 0] [0 2 1 1 1 1 1 1 1 1 1 1 1 2 0 0 0 0 0 0] [0 2 1 1 1 1 1 1 1 1 1 1 1 2 0 0 0 0 0 0] [0 2 1 1 1 1 1 1 1 1 1 1 1 2 0 0 0 0 0 0] [0 2 1 1 1 1 1 1 1 1 1 1 1 2 0 0 0 0 0 0] [0 2 1 1 1 1 1 1 1 1 1 1 1 2 0 0 0 0 0 0] [0 2 1 1 1 1 1 1 1 1 1 1 1 2 0 0 0 0 0 0] [0 2 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0] [0 2 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0] [0 2 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0] [0 2 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0] [0 2 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0] [0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0] [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]] So I was wondering if this was by design, a bug or just current quirky behavior?

2 1