Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #16063

Re: Simplifying wiggly paths

Show all headers | View raw

On Sunday, 11 December 2022 at 23:49:36 UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> 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.

 

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Simplifying wiggly paths Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-12-06 02:52 -0800
  Re: Simplifying wiggly paths Paul N <gw7rib@aol.com> - 2022-12-06 05:04 -0800
    Re: Simplifying wiggly paths Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-12-06 06:50 -0800
  Re: Simplifying wiggly paths Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-11 23:49 +0000
    Re: Simplifying wiggly paths Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-12-12 04:34 -0800
      Re: Simplifying wiggly paths Julio Di Egidio <julio@diegidio.name> - 2022-12-12 10:21 -0800
        Re: Simplifying wiggly paths Y V A <yyyyyyyyyyyywwwww@zohomail.eu> - 2023-04-20 04:31 -0700
  Re: Simplifying wiggly paths Y V A <yyyyyyyyyyyywwwww@zohomail.eu> - 2023-04-20 04:31 -0700

csiph-web