Skimage.draw module - perimeter vs area call behavior

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.

So I was wondering if this was by design, a bug or just current quirky behavior?

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]]

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.

1 Like

Thanks! …I’ll raise an issue as well like you suggested

One more Q: is it true that the perimeter is always the set of points that include the corner points defining the region? I’m interested in defining regions and then measuring values over them - so I can easily use a union of perimeter and interior to get all the points …I just want to check the perimeter should be correct

I think this is true up to some floating point approximation, but you should definitely test things in your use case.