I ran your test code and it died after the following output: Testing the triangle
[ [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] [0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0] [0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0] [0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0] [0 0 0 0 0 0 1 1 1 1 1 1 0 0 0 0 0 0 0 0] [0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0] [0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0] [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] ] [0 0 0 12 10 8 6 4 2 0 0] Can't modify non-lvalue subroutine call at polyfill-test.pl line 31. It appears that polyfillv is not marked as an lvalue sub. If not, I would consider that a bug. The differences between the two results appear to be whether or not the edge pixels are included and the pnpoly does appear to be "fully" correct in generating the set of interior points to the polygon. --Chris On Thu, Jun 14, 2012 at 8:08 AM, Chris Marshall <[email protected]> wrote: > Putting polyfill and polyfillv on the path to > deprecate the old implementation and move > to the pnpoly one could be done as well. > > --Chris > > On Wed, Jun 13, 2012 at 5:50 PM, Chris Marshall <[email protected]> > wrote: >> Hi Tim- >> >> I note that polyfill and polyfillv have been part of PDL >> since 2000 while pnpoly was only added Dec 2011. >> >> I'm a bit leery of changing something that has been >> part of the PDL distribution for such a long time without >> a clear need to do so. I suggest changing the docs >> for polyfill and polyfillv to note that the algorithm is >> faster/less memory intensive (is it?) than pnpoly but >> slightly less accurate. >> >> Any other opinions on this? BTW, I assume that the >> difference in on the edges of the regions and no a >> big difference between the pnpoly result. >> >> --Chris >> >> On Wed, Jun 13, 2012 at 3:45 PM, Tim Haines <[email protected]> >> wrote: >>> Greetings, all. >>> >>> I was playing around with Image2D::pnpoly and Image2D::polyfill (and >>> polyfillv), and I noticed that the latter two do not have the same behavior >>> as pnpoly. I have some tests below. >>> >>> use strict; >>> use warnings; >>> use PDL; >>> use PDL::Image2D; >>> >>> # A triangle >>> my $px = pdl(3,15,9); >>> my $py = pdl(3,3,9); >>> print "Testing the triangle\n"; >>> &testPoly($px,$py); >>> >>> # A square (be careful to draw it convexly!) >>> $px = pdl(4,4,8,8); >>> $py = pdl(4,8,8,4); >>> print "Testing the square\n"; >>> &testPoly($px,$py); >>> >>> sub testPoly >>> { >>> my $px = shift; >>> my $py = shift; >>> my $points = $px->cat($py)->xchg(0,1); >>> >>> my $img1 = zeroes(20, 11); >>> my $img2 = zeroes(20, 11); >>> my $img3 = zeroes(20, 11); >>> my $img4 = zeroes(20, 11); >>> >>> my $img5 = pnpoly($img1->xvals,$img1->yvals,$px,$py); >>> print $img5, $img5->sumover, "\n"; >>> $img2->polyfillv($points) .= 1; >>> print $img2, $img2->sumover, "\n"; >>> $img3->polyfill($points, 1); >>> print $img3, $img3->sumover, "\n"; >>> } >>> >>> >>> From the output, I believe that pnpoly produces the correct answer insofar >>> as it produces the correct area for the square. Moreover, the documentation >>> for polyfill and polyfillv states that "fill the area inside the given >>> polygon with a given colour" and "return the (dataflown) area of an image >>> within a polygon," respectively. However, the area selected for color >>> filling in polyfill contains more than the points interior to the polygon, >>> and similarly for polyfillv. >>> >>> After some investigation into PDL/Lib/Image2D, I found that polyfillv uses >>> polyfill, so their identical behavior is expected. >>> >>> My proposed fix is to use pnpoly to determine the interior points. Then >>> polyfill becomes simply >>> >>> sub PDL::polyfill >>> { >>> my ($im, $ps, $col) = @_; >>> barf("ps must contain pairwise points.\n") unless $ps->getdim(0) == 2; >>> barf("color not specified.\n") unless $col; >>> $im->where($im->pnpoly($im->xvals, $im->yvals, $ps->slice('0,:'), >>> $ps->slice('1,:'))) .= $col; >>> } >>> >>> and polyfillv becomes >>> >>> sub PDL::polyfillv >>> { >>> my ($im, $ps) = @_; >>> barf("ps must contain pairwise points.\n") unless $ps->getdim(0) == 2; >>> return $im->where($im->pnpoly($im->xvals, $im->yvals, $ps->slice('0,:'), >>> $ps->slice('1,:'))); >>> } >>> >>> This will remove the need for the PP version of polyfill. Assuredly, these >>> fixes are not optimal. If $im is large, then two large intermediates >>> ($im->xvals and $im->yvals) are created. >>> >>> I did not file this as a bug report, I wanted to run it by everyone to see >>> if I was missing something. Additionally, I am not closely familiar with the >>> coding standards, so I would appreciate any tips on that, as well. >>> >>> Many thanks. >>> >>> - Tim >>> >>> >>> >>> >>> _______________________________________________ >>> Perldl mailing list >>> [email protected] >>> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >>> _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
