Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add scanline algorithm for drawing polygons #931

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

stefanv
Copy link
Member

@stefanv stefanv commented Mar 14, 2014

Implementation of a scanline algorithm for rendering polygons in response to #928

@stefanv
Copy link
Member Author

stefanv commented Mar 14, 2014

Suggestions for API and placement within skimage welcome. Code may have to be turned to Cython code to compete with existing polygon drawing, even though the algorithm should be much faster for large polygons.

@@ -154,3 +224,24 @@ def set_color(img, coords, color):
rr, cc = coords
rr, cc = _coords_inside_image(rr, cc, img.shape)
img[rr, cc] = color


if __name__ == "__main__":
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this was for testing purposes.

@ahojnnes
Copy link
Member

Is there a reason why we not replace the existing function altogether? Does it produce the same result?

@JDWarner
Copy link
Contributor

@ahojnnes 👍 agreed, if possible the ideal change would be a drop-in replacement. That function gets used directly or indirectly quite a bit, so existing test coverage should be very good.

@stefanv
Copy link
Member Author

stefanv commented Mar 14, 2014

It depends on which one you want to replace, I guess. It gives identical results to the existing draw.polygon, but differs from morphology._pnpoly.grid_points_inside_poly. Also, it edits the image directly, so it returns a mask, not coordinates.

@JDWarner
Copy link
Contributor

Hmm, perhaps both should be replaced? I haven't delved into this deeply to see if a single backend is reasonable/possible; if not (or if the overhead would be undesirable) perhaps grid_points_inside_poly should be dealt with separately.

@stefanv
Copy link
Member Author

stefanv commented Mar 14, 2014

I just realised that it may very well be that the difference in these
algorithms is simply due to a (.5,.5) offset. I will investigate further.
On 14 Mar 2014 23:12, "Josh Warner" notifications@github.com wrote:

Hmm, perhaps both should be replaced? I haven't delved into this deeply to
see if a single backend is reasonable/possible; if not (or if the overhead
would be undesirable) perhaps grid_points_inside_poly should be dealt
with separately.

Reply to this email directly or view it on GitHubhttps://github.com//pull/931#issuecomment-37697017
.

@soupault soupault changed the title WIP: Add scanline algorithm for drawing polygons Add scanline algorithm for drawing polygons Oct 25, 2016
@jni
Copy link
Member

jni commented May 1, 2018

@stefanv thanks for resurrecting this! Looks great! Care to change it to rows/cols and Cythonize the loop? ;) I would also think that using lists is unnecessary. Pairs is simple enough to implement with looping, and you can pre-allocate an array of the same size as the number of segments for intersections.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants