I think "just current quiry behavior" is the right description. I don't know whether it's worth a bug fix, as it would require a deprecation cycle and so on. btw it's better to set one variable to 1 and another to 2, so you can disambiguate all the 1s. Specifically, the 1 in the top right corner *should* come from perimeter. If it came from polygon but not from `polygon_perimeter`, I might consider it a bug worthy of a fix. It might be a good idea to raise the issue on github.com/scikit-image/scikit-image/issues, so more people from the dev team can get their eyes on it. On Sun, 4 Aug 2019, at 5:56 PM, yahbai@gmail.com wrote:
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? _______________________________________________ scikit-image mailing list -- scikit-image@python.org To unsubscribe send an email to scikit-image-leave@python.org