Throw errors at 80% of inputs.

[BurguerJohn]

Depending on the input, I seen in throw three types of error. Not sure what cause those errors.

\polyfit\source\polyvec\polygon-tracer\iterative-global.cpp: 314 - Failed expression: E_keep_attempts[0].find(e_id) == E_keep_attempts[0].end()

\polygon-tracer\multi_polygon.cpp: 957 - Failed expression: e_id_B_twin != 0

\polyvec\polygon-tracer\multi_polygon.cpp: 898 - Failed expression: v_bounds0.first != -1 && v_bounds0.second != -1

There is also some inputs that the app simple stops without throwing a single error. This is a image that the app simple don't generate the output without showing any error:

[dedoardo]

Thank you for pointing out the issues and providing an example. I ran your input on a previous commit (local to my lab machine) and it worked fine (see attachment). You should be able to obtain the same output by running the current commit in Debug mode.

I found the cause to be in some changes made after submission which went untested. I am now trying to integrate them more carefully, will try to commit a more robust version later today.

This should definitively help to reduce the failure rate drastically. Nonetheless, if you wouldn't mind sharing some of the failure examples I would be happy to use them for testing. They wouldn't be uploaded anywhere.

curves_closed.zip

[BurguerJohn]

Very nice to see that it was a small detail! I plan to make a video on top of your project. There is a lot of potential on it. Here some problematic files. \multi_polygon.cpp: 1257 - Failed expression: n_vertices_src == n_vertices_dst

\multi_polygon.cpp: 957 - Failed expression: e_id_B_twin != 0

\polygon-tracer\iterative-global.cpp: 314 - Failed expression: E_keep_attempts[0].find(e_id) == E_keep_attempts[0].end()

[dedoardo]

I managed to accomplish part of the tasks: the first example runs fine with the current commit as well as the results in the paper are reproducible, I have added the multicolor raster images in the data folder.

Regarding the other inputs that you shared, it's a little bit more complicated. As you can see in the paper our algorithm is designed with clip-art in mind rather than pixel-art, where the difference lies in the size of the regions, their usual topology and resulting complexity of the segmentation (see data/multicolor for differences). I did not have the chance to test the code on pixel-art during development.

There is no theoretic reason why it shouldn't work, but it requires more debugging. The assumptions which fails are often the same (compared to the total amount of asserts we have in the code) which suggests that the fixes to be made are not many but need to be made very carefully. There are a lot of sequential steps in MultiPolygon::_trace().

This is something worth addressing to make the code robust and thus I am creating a related issue specifically for pixel-art. I will do my best to address them in the near future, though it's not going to be a matter of days :(

[BurguerJohn]

Hey, no problem, thanks for giving a shot on it, I understand those are all edge cases, it was pretty much random tries to see what the code would produce. It still a very impressive code. Thanks for the fixed for the simpler images, I will give it another shot later today!