home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.programming      Programming issues that transcend langua      57,431 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 56,749 of 57,431   
   Malcolm McLean to Ben Bacarisse   
   Re: Simplifying wiggly paths   
   12 Dec 22 04:34:28   
   
   From: malcolm.arthur.mclean@gmail.com   
      
   On Sunday, 11 December 2022 at 23:49:36 UTC, Ben Bacarisse wrote:   
   > Malcolm McLean  writes:   
   >   
   > > I'm working on a problem where a user enters a degraded, wiggly curve   
   > > (it's actually created by tracing software from what might have been   
   > > once a rectangle, for example, but has been physically printed, then   
   > > scanned, and so on, so that there are plenty of stray pixels picked up   
   > > by the tracing software).   
   > >   
   > > So basically what I want to do is sample the curve at a fairly low   
   > > resolution, then re-fit it, to get rid of the noise. However I want to   
   > > retain the genuine sharp corners. So in the rectangle case, the   
   > > desired output wouldn't be a mathematical rectangle, but it would be   
   > > four clean almost straight curves, connected by four corners of almost   
   > > ninety degreees.   
   > >   
   > > The curve tends to go back on itself. It's like a coastline. It's easy   
   > > to pick out the real curve from the noise by eye, but harder to do it   
   > > automatically.   
   > How is this going? I can't help, but I was hoping so see some   
   > interesting discussion as it seems both challenging and likely to have   
   > been solved before (though possibly with constraints that don't match   
   > your circumstances).   
   >   
   I got an artist to draw up a test set for me.   
      
   The core of it is a function called "GetRealCorners", which takes a Bezier   
   path,   
   and returns the real corners. A Bezier path has a corner if the two handles at   
   a knot point don't form a straight line. But a mathematical corner could   
   represent   
   either a real corner in the underlying image, or local noise.   
      
   So what I am doing is taking ten pixels in curve space on each side of the   
   corner.   
   If either the leading or the trailing sample isn't at least three times a long   
   as it is   
   wide, as measured by the bounding box, I say that the corner isn't real. If any   
   of the leading or the trailing curves overhangs the corner, I say the corner   
   isn't   
   real. Then I compare the angles of the tangents at the corner point to the   
   vectors   
   obtained by going from  start to end on the leading and trailing curves. If   
   they are   
   not similar enough, I say the corner isn't real. Finally I take the angle   
   between the   
   start o fthe leading curve, the corner, and the end of the trailing curve. If   
   it is too   
   close to 180 degrees, I say the corner isn't real.   
      
   Having marked the real corners, I sample the curve at fairly coarse intervals,   
   apply a Gaussian filter to smoothing things out and then refit it with a sloppy   
   tolerance factor, which gives me a fairly smooth curve between the corners.   
      
   Whilst it works on the test set, the snag is that I had to fiddle with the   
   parameters   
   in an ad hoc way to achieve this.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca