Re: A distracting puzzle [message #26814 is a reply to message #26727] |
Wed, 26 September 2001 01:53  |
Martin Downing
Messages: 136 Registered: September 1998
|
Senior Member |
|
|
Ah go on JD, show your code - then the rest of us can decide whether we
could do better without reinventing the wheel!
Martin
"JD Smith" <jdsmith@astro.cornell.edu> wrote in message
news:3BB0B6D0.43C7859F@astro.cornell.edu...
> Stein Vidar Hagfors Haugan wrote:
>>
>> If what's being sought here is only to distinguish which pixels have
*some*
>> area inside the polygon and which do not, wouldn't it be sufficient to
check
>> the corners? I.e., in a continuum of pixel coordinates, given corners
with
>> coordinates [0,0], [1,0], [1,1], [0,1], it can be checked whether each
of
>> those are inside versus outside any defined polygon. If one or more of
the
>> corners is inside, then some area is also inside..
>>
>> I have included some simple-minded routines I wrote some years ago to
check
>> whether a point is inside or outside a polygon...
>
> Thanks Stein Vidar. Your method would seem to provide the answer for
> the boolean question; however, my intent was to provide a list of pixels
> which are at least partly inside the polygon, *along with* a list of
> their fractional areas included. I came up with a solution I call
> polyfillaa, which is a direct replacement for polyfillv.
>
> inds=polyfillaa(x,y,sx,sy,AREAS=a)
>
> returns the pixel indices, along with the clipping areas if desired. It
> performs a straightforward form of polygon clipping. The "aa" is for
> anti-aliasing, which is basically what it does. It works quite well,
> but is very slow, thanks to a surplus of looping. In general it returns
> more pixels than polyfillv, which neglects pixels with small areas
> inside, and (erroneously, I feel) truncates polygon points to integer
> pixels.
>
> I may document it and put it up somewhere soon, but I'm embarrassed by
> all the for loops. We'll see.
>
> JD
|
|
|