I have learned a bit more. As I mentioned earlier, all of my first polygons had within() true for the entire rectangle less the right and bottom rows. I have now been able to make some right triangles that do not have this problem. However, if I make the lineSize greater than 18 (for mine) the problem comes back. It goes a way when I make the lineSize less than 18. The legs on these right triangles are 100.
The area as seen by within() is definitely greater than half for 0 lineSize. It does go up with lineSize. On mine. Mapping out within() shows the diagonal being about 6 pixels wider but limited to the box one pixel smaller than the rectangle. Maybe 5, as you saw, I don't count well. It seems within() is not reliable and doesn't count well. If the rectangle for small graphics is not what you want because of the minimum rectangle, then you might need to look for the min and max of the points to get what you want. I looked at some tiny squares with smoothing on. It looks as thought the shape is drawn with the corners in the middle of pixels. As squares get bigger, something goes wrong, and I haven't looked what it is. (I suspect that if the width is greater than 8 the right and bottom smooth edge is cut off.) You might be able to track down within() issues by creating a translucent overlay image that shows what pixels are within. I had a problem with LiveCode closing polygons I left open, so I was not able to test that. I think that you might be able to test whether a polygon is singly connected. (I just learned that phrase.) But, maybe there is a better way to do a math calculation of the area. Dar On Jun 8, 2013, at 5:45 AM, David Epstein wrote: > Thanks to Dar Scott, Craig Newman, and Jim Hurley for thinking about this. I > don't know why the coverage function would yield 1.0 (except for a very small > graphic; see glitch described below). The Dar Scott amendment to my > function--subtracting 1 from the right and bottom of the rect that I > survey--is, I learned, equivalent to testing whether "pt is within the rect > of grcLID"; in other words the pixels on the bottom and right edge of a > graphic's rect are not counted as "within" the graphic's rect. > I tested Dar's suggestions about lineSize and borderWidth. Perhaps because I > have showBorder set to false borderwidth had no effect. LineSize did affect > the results of my "coverage" function, with results that are peculiar but do > not solve my original puzzle (that reported "coverage" should not, but does, > vary as I scale a shape). > I resorted to careful study of a very simple polygon, an isosceles right > triangle with its hypotenuse toward the bottom left. This is a case where I > would want my "coverage" function to return 0.5, since half of the rectangle > is covered by the visible graphic. Rather amazingly, the > "within(graphicLID,point)" function returned true not only for the points I > expected, but for 5 additional diagonal "lines" of pixels forming a kind of > border extending left and down from my visible hypotenuse. This was true > both for a 10 x 10 rectangle and for a 50 x 50 rectangle. > This makes it easy to see why "coverage" seems to decline as a graphic gets > bigger, since these false positive pixels are a much larger share of a small > rectangle. But why is "within" returning all these false positives? I > tested the "margins" property to no avail. > One further source of difficulty: > If I define a grapic’s “points”, LC seems to impose a lower limit of 8 x 8 on > its width and height. Thus while a triangle with points 0,0 <cr> 10,0 <cr> > 10,10 <cr> 0,0 has 100 pixels within its rect, defining a triangle with > points 0,0 <cr> 5,0 <cr> etc. results in an object with 64 -- not the > expected 25 -- pixels within its rect. And almost all of those extra pixels > also register as "within" the filled graphic itself, so that "coverage" gets > close to 1.0. > > Jim Hurley’s function is very useful, but I was hoping to use “within()” so > that I could handle graphics that are not singly connected and closed. Is > there some way to script a test for those cases? > David Epstein > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
