comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » POLYFILLV weirdness
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: POLYFILLV weirdness [message #51404 is a reply to message #51350] Mon, 20 November 2006 12:31 Go to previous messageGo to previous message
JD Smith is currently offline  JD Smith
Messages: 850
Registered: December 1999
Senior Member
On Sun, 19 Nov 2006 15:43:00 -0700, Jean H. wrote:

> dktr.ted@gmail.com wrote:
>>> PolyFillV is not using the provided polygons coordinates but a "fix()"
>>> of them.... which induce this extra line on the left and at the bottom
>>> (and a few missing pixels on the right side and on the top If I remember
>>> well). I personnaly used a round() over my polygon coordinates and it
>>> was returning much better results... though still not perfect!
>>
>>
>> This practice is particularly horrifying to me considering I frequently
>> use ROIs defined in physical coordinates and convert them to array
>> coordinates (commonly fractional) before running POLYFILLV. Is there
>> anywhere I can have a look at the actual algorithm used in IDL for this
>> routine? The documentation references the scan line coordinate system
>> defined in Rogers, Procedural Elements of Computer Graphics, 1985, but
>> I'm reluctant to hunt down this out of print text without confirmation
>> that I will get something useful out of it.
>> Ted
>
> Hi Ted,
>
> the code is not available... but you can have a look here:
> http://www.ittvis.com/services/techtip.asp?ttid=3539
> The process is a bit more explained...

This is a crummy old algorithm. I've lobbied unsuccessfully for
RSI/ITTVIS to put real polygon clipping into IDL, either something
simple like Sutherland-Hodgeman, or a full-up "holes and degenerate
edges" Greiner-Hormann algorithm or other method, e.g. something
like gpc:

http://www.cs.man.ac.uk/~toby/alan/software/

Any of these can clip an arbitrary polygon against another polygon (or
just a grid in the Sutherland-Hodgeman case), compute the exact area
of overlap as well as the actual overlap polygon itself. That latter two
can even deal with holes and other weird polygon forms. I have a slow IDL
Sutherland-Hodgeman implementation, as well as a C DLM for the same, but
it sure would be nice not to have to go to that. If you share this
concern, let your ITTVIS representatives know.

JD
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Widget_Droplist
Next Topic: open and save a set of image

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Oct 10 04:29:07 PDT 2025

Total time taken to generate the page: 0.96052 seconds