I'll admit that I found getting openCV installed and working at all was an entirely frustrating and fruitless exercise - if you have managed that, then you are (at least) one step ahead of me!
In the live trace stuff I did, I struggled to bridge that last gap too - having generated bitmap blobs, how to trace them effectively into vectors. I'm positive it is a well-solved problem, but I really laboured on it. I don't have much insight into graphics - it's a very mathsey kind of area, and not my strength at all.
I don't think there's a strong developer community here, partly because the polargraph code has traditionally been so... uninviting, so I guess you'll probably have more luck on the processing boards. The polargraph library will be pretty agnostic about what it plugs into, so there needn't be anything special about how the source vectors are generated.
I am currently on the horns of a dilemma about what kind of geometry library to use. Geomerative is Processing-only, but very nice and quite well liked, though slightly over-capable for what I'm using it for. The java.awt.geom package is part of the core java runtime environment so is ubiquitous, but it's also deprecated in Processing 2 because it is not available on Android, it's probably made fun of because it's old fashioned and it's clunky in the way that java likes to be.
The reason I'm mentioning it, is because the interface to the polargraph library will likely take objects in the form of one of these (maybe both) objects. If you end up using geomerative (RShape and RPath etc), then polarlib is likely to understand that natively.
Good luck!
|