hi joreg,
thanks for the quick reply!
my problem is how to get the inside of the contour “as a shape”?
how do i calculate the inside with the outside coordinates?

wats the difference between inside and outside coordinates of a shape? the contour node returns the coordinates “sourrounding” the shapen. using those you should be able to build a shape using Delaunay (2d Triangle) and joining your custom vertexbuffer…i am not aware of any out of the box demo for something like this. anybody?

your intention is understood. let me clarify the challenge:

while a ‘stroke’ can be achieved by just feeding the coordinates from the contour-tracker into a Line (DX9) or Rope (DX9), the actual ‘fill’ is more difficult to achieve. you would need to calculate a mesh from the contour points (which is in itself also simple using the Mesh (Join) and VertexBuffer (Join)). the real problem is the proper indexing of the mesh, the way the points will be connected.

Delaunay (2D) will give you a working set of indices, but the calculation will only describe a convex hull around the points you are using. this works fine as long as you are dealing with convex shapes, which stops being the case very quickly when using contourtracking on complex objects like hands & people, for example. so there is the mathematical problem of interpreting the contour points of concave shapes. wikipedia links to this example; and that’s all i can tell you about it ;)

hi diki,
the wikipedia link sounded pretty interesting/promising.
unfortunately my math-skills aswell as my patching-skills are still pretty limited… :(

i was hoping somone already faced the concave/convex problem in vvvv
or is up for a collaboration

if you can live with some limitations in the algorithm, it gets significantly easier.

e.g. you could approximate your object with a Triangle Fan with one center point in the middle (calculated from the average of all points) and a number of points from the contour. Note that most concave objects will look wrong with this technique, but perhaps you can work around this from a conceptual design side.

Another approach could be approximating your object through a one-dimensional linear arrangement quads with different heights and y positions. Map (Value Interval) might be at the core of a patch for this. This also would have some limitations, but some abstractions might look nice anywsy.

One of the reasons why there is no node in vvvv for filling countours is, that a general solution is quite slow for complex shapes. So even with the aforementioned plugin (which would be fun to write) it can pay off to think about alternative algorithms.

note also that the input to the Contour basically already is a filled contour. So a bit of image manipulation and the use of textures could do quite similar things.

hi oschatz,
thanks a lot for your detailed answer! you got some points there…

i am aware that tracking different objects moving around would result in a lot of points and calculation, so give a rather slow system or even kill it …

my project is actually not directly about tracking moving objects. its more a about pattern recognition in still images.
i actually was heading in the direction of “tracking” - fonts and doing this manipulating them.
therefore a too rough approximation doesnt help.

conceptually for me it is really important to get “what the computer understands” out of the image.
taking the video-output of contour is an option to get the shapes but then in the end its just a tresholded image…

For now i will try like you suggested to work around it with approaching my objects with arrangements of different shapes … this could give some interesting “accidents”…

many thanks for your patient help anyway!

p.s.: still i would put the “fill-for-contour”-node on the vvvvishlist.
(maybe i should start a little competition: i offer some best-bavarian-beer “grüner august” for the winning-patcher! ;) )

if it is about pattern recognition OpenCV might help. if i remember correctly it has some functions to compare contours. so you could define some contours and then compare those to live “tracked” contours and get a likelyhood of match. this would involve some serious c/freeframe coding though…