We have encountered some problems with the polygon scan iterator when it is used in the mode that includes points on the boundary of the polygon.
In this case, and for the first and last scan lines, the method for getting the horizontal pixel spans is not valid and only works by chance. I wish to fix this problem, but there is an issue of the “correct” behavior for a polygon pixel scan. There seem to be a number of different interpretations of “inside” and “on” for pixels:
1) Pixels are treated as infinitesimal points on an integer grid where “inside” means a discrete pixel point is strictly inside the polygon border. The case of “on” the polygon boarder means that a pixel point is not “in” but is within one horizontal pixel distance and/or within one vertical pixel distance from the polygon border.
2) Pixels are treated as square tiles with unit area. In this case the entire tile must be inside the polygon border to be in. An inside tile edge or corner can just touch the boundary and still be considered inside. The case of a tile “on” the boundary means that the polygon boundary intersects the tile in some finite interval. Intersections that intersect a tile corner or lie on the edge of a tile are considered outside.
3) Beyond these two cases there is also the notion of a “partition” where a set of adjacent polygons with a common border should not claim the same pixel twice. This situation can arise, for example, for a triangular mesh and the need to extract pixels for mapping texture onto the triangles. Neither of the definitions in 1) and 2) respect the partition constraint.
I am writing to seek the vxl community consensus on which set inclusion definitions should be observed by the polygon and triangle scan iterators. Currently, there is neither consistency nor correctness.
Professor of Engineering(Research)
Barus and Holley
184 Hope Street