Managing polygon with holes

[co-ord]

Hi @Botffy ,

I have difficulties outputting the skeleton of a polygon with a hole using the skeletonize method.
I have tried with your holey example:

import polyskel

contour = [(30,100), (50, 200), (220,240), (440,240), (430,40), (230,30), (85,40)]
hole = [(175,85), (245,140), (315,90), (385,160), (330,200), (165,180)]

skeleton = polyskel.skeletonize(contour,  [hole])) # !!something must be missing here

for a in skeleton:
    for s in a.sinks:
        line(a.source.x, a.source.y, s.x, s.y)

However the output looks like it is missing the hole information:

Would you mind helping me figuring out what could be missing in the snippet above ?

[Botffy]

Hi!

That's weird, I just tried it like this:

import polyskel
from PIL import Image, ImageDraw

contour = [(30,100), (50, 200), (220,240), (440,240), (430,40), (230,30), (85,40)]
hole = [(175,85), (245,140), (315,90), (385,160), (330,200), (165,180)]

skeleton = polyskel.skeletonize(contour,  [hole]) # !!


bbox_end_x = 600
bbox_end_y = 600
im = Image.new("RGB", (bbox_end_x, bbox_end_y), "white")

draw = ImageDraw.Draw(im)
for a in skeleton:
    for s in a.sinks:
        draw.line((a.source.x, a.source.y, s.x, s.y), fill=0)

im.show()

And it produces this:

which is the expected skeleton. This with a Python 3.8.4. But what's your euclid version? This may be related to #17

Other than that, I don't know! (In the posted code you have an unmatched ), but I wouldn't think that would be it.)

[co-ord]

Hey, thanks for trying out !

This is a mystery indeed, I just tried with the latest version of euclid and got the same weird output. This probably has to do with the environment I am using (Processing) which relies on Jython 2.7 and not real Python. I ended-up using another software to compute the skeletons of polygons with holes but for "normal" shapes your library is still very useful (not 100% accurate but still super handy).

(sample polygons, some skeletons are not accurate / flawed)

Thank you !

[Botffy]

Wow, those are really weird errors. I'd expect some localized weirdness, but not something huge like these. I don't know, weird. Could you perhaps send me any of those polygons?

(Also, incidentally, may I ask what are you using this for? :) I get a kick out seeing this thing in action.)

[co-ord]

Sure, here are the first 5 polygons circled in red in the previous picture. I found that sometimes the glitch disappears when inverting the coordinates along the Y-axis so I included both versions.

Oddly enough, your library handles the following polygons without any errors when run inside Processing (Jython). However when computing their straight skeletons inside Rhino/Grasshopper (IronPython), things get weird (picture above).

I truly don't understand why the results of the library changes depending on the environment...

### 567

(332.155835, 286.642116),
(307.208914, 283.679822),
(282.621626, 295.434114),
(256.61141, 298.648095),
(234.002583, 301.455813),
(237.286663, 322.767023),
(259.04409, 321.609804),
(289.199133, 318.012761),
(308.288599, 302.214365),
(324.85719, 312.153222),
(343.169966, 319.429292),
(349.133086, 290.936484),
(351.837579, 267.052049),
(327.657786, 266.134745)


### 567 (reversed Y-axis)

(327.657786, 333.865255),
(351.837579, 332.947951),
(349.133086, 309.063516),
(343.169966, 280.570708),
(324.85719, 287.846778),
(308.288599, 297.785635),
(289.199133, 281.987239),
(259.04409, 278.390196),
(237.286663, 277.232977),
(234.002583, 298.544187),
(256.61141, 301.351905),
(282.621626, 304.565886),
(307.208914, 316.320178),
(332.155835, 313.357884)


### 569

(277.304336, 297.209683),
(255.546909, 298.366902),
(237.941446, 317.602724),
(275.851686, 319.771413),
(299.593617, 315.907299),
(313.359746, 330.746428),
(329.845574, 309.369367),
(343.117436, 287.753101),
(326.548845, 277.814244),
(325.46916, 259.279701),
(300.881872, 271.033993),
(307.45938, 293.612639)


### 569 (reversed Y-axis)

(307.45938, 306.387361),
(300.881872, 328.966007),
(325.46916, 340.720299),
(326.548845, 322.185756),
(343.117436, 312.246899),
(329.845574, 290.630633),
(313.359746, 269.253572),
(299.593617, 284.092701),
(275.851686, 280.228587),
(237.941446, 282.397276),
(255.546909, 301.633098),
(277.304336, 302.790317)


### 571

(355.215397, 280.648467),
(330.268476, 277.686173),
(305.681188, 289.440465),
(279.670972, 292.654446),
(257.062145, 295.462164),
(234.249222, 278.318493),
(242.740762, 336.009196),
(260.346225, 316.773374),
(282.103652, 315.616155),
(312.258696, 312.019111),
(331.348161, 296.220716),
(347.916752, 306.159573),
(366.229528, 313.435643),
(372.192648, 284.942835)


### 571 (reversed Y-axis)

(372.192648, 315.057165),
(366.229528, 286.564357),
(347.916752, 293.840427),
(331.348161, 303.779284),
(312.258696, 287.980889),
(282.103652, 284.383845),
(260.346225, 283.226626),
(242.740762, 263.990804),
(234.249222, 321.681507),
(257.062145, 304.537836),
(279.670972, 307.345554),
(305.681188, 310.559535),
(330.268476, 322.313827),
(355.215397, 319.351533)
 

### 600

(332.495901, 311.16159),
(334.817137, 281.764429),
(316.669963, 276.374212),
(299.692712, 272.079844),
(292.394067, 297.59095),
(275.825475, 287.652092),
(256.73601, 303.450488),
(279.122204, 319.207216),
(298.41713, 332.412726),
(310.706843, 304.867019)


### 600 (reversed Y-axis)

(310.706843, 295.132981),
(298.41713, 267.587274),
(279.122204, 280.792784),
(256.73601, 296.549512),
(275.825475, 312.347908),
(292.394067, 302.40905),
(299.692712, 327.920156),
(316.669963, 323.625788),
(334.817137, 318.235571),
(332.495901, 288.83841)


### 602

(326.855946, 314.644187),
(334.154591, 289.133081),
(329.656541, 268.62571),
(304.437656, 277.184506),
(309.20767, 286.170787),
(284.620381, 297.925079),
(258.610165, 301.13906),
(261.042846, 324.100769),
(291.197889, 320.503725),
(310.287354, 304.70533)


### 602 (reversed Y-axis)

(310.287354, 295.29467),
(291.197889, 279.496275),
(261.042846, 275.899231),
(258.610165, 298.86094),
(284.620381, 302.074921),
(309.20767, 313.829213),
(304.437656, 322.815494),
(329.656541, 331.37429),
(334.154591, 310.866919),
(326.855946, 285.355813)

I am working on permutations and try to analyze how polygons inside a set are related to each other (correlation, similarity), partly based on their Straight Skeleton.

Ideally, I would have also used your library to compute separation lines between polygons (or sub-trees like below) but ended-up using another technique because I couldn't manage to make Polyskel handle polygons with holes inside Processing.

All in all, Polyskel has been handy for various projects so far: coloring polygons, terrain generation, fake 3D effect,... unfortunately I don't have access to my main computer right now so all I can share is this image :)

[co-ord]

Upon further investigations I have come to think that it has to do with the way Jython and IronPython handle floats and treat them as doubles instead. I am not still sure about this but I have found that converting the floating coordinates to integers somehow makes possible to overcome the issue.

I apologise for the inconvenience.