TR Forums

Here's the situation: I'm working on a control system, and I would like to control a human to move a tool around in a desired arbitrary shape. This shape will be etched into some kind of material, where it can be evaluated.

Now, I would like the shape to be represented by a black and white image, which has no grey values in between black and white. I don't know if I need to convert this collection of black pixels into a line, or a function, which the control program can then use to determine the vector in which it should propel the human. The problem, though, is what image libraries are out there that can do this for me? I'm sure there are already tons of image libraries out there that can probably do something like report which pixel coordinates are black, or something. Problem is, I have no idea where to start.

EDIT: Basically, I want my control program to receive a shape from a program that understands the difference between a black and white pixel, and can generate a shape out of an image, represented via a path, or just a collection of points, which the program could probably follow.

Crayon Shin Chan wrote:

Here's the situation: I'm working on a control system, and I would like to control a human to move a tool around in a desired arbitrary shape.

That might be the more difficult problem that you should tackle first. Computer-control of humans isn't a mature technology!

On a more serious note, there might be better ways to represent the desired shape than a bitmap image. Using (or converting to) a vector format could be a better option. I'd work backward from what the program/tool can *definitely* follow rather than moving forward from "what can I do with a bitmap", unless that requirement is etched in stone.

Crayon Shin Chan wrote:

This shape will be etched into some kind of material, where it can be evaluated.

Does the GUI initially capture the user input as a sequence of lines/points? Does the machine receive its etching instructions as a sequence of lines? If both answers are yes, then I agree with mattsteg that keeping it in a vector format might be better.

It seems like two sources of error would be introduced if a bitmap was used as an intermediate format (ie, (1) converting from the GUI's vector format to a bitmap, and then (2) converting the bitmap to the etching machine's instructions).

If you want to determine if the theoretical pixel should be black or white, maybe you could use similiar logic that XAML uses to determing its FillRule (see the page's first and third images).

But I'm making a lot of guesses about the overall system. Is this even in the right ballpark?

Well I've done some research, and I've found
http://openil.sourceforge.net/
which fits, since all data is recorded from the camera as points. But suppose I don't want to deal with converting 72dpi to x dpmm, and also want to include SVG support. But then the only SVG library I can find is librsvg, which seems to only be for POSIX OSes. I don't want cygwin on this machine!

I see that Cairo has SVG support, but it seems to render GUIs too, which is unfortunate as the project already uses Qt 3 for that.

EDIT: Also, I heard SVG support is kinda flaky? Would I have trouble specifying, for instance, that a certain length along Curve X would correspond to X mm in the real world? The camera is only accurate down to 1mm.
EDIT2: mattsteg - that was my last task, a fuzzy controller for the system. And now I have to code this new experiment that uses this controller (and others as well, like a APID or PID controller) to guide a human's hand along a shape.

After a lot of humming and hawing, I've decided to go with SVG. It's really convenient since SVG is a text based format so I can kinda parse it directly in the program without adding too much code. The only problem is converting the SVG path tag into something my program can use... if I rasterize it within the program then it would defeat the purpose of using a vector format and add a lot of extra code, so I will definitely keep the path represented as a path... I'm not very sure about that part.

In any case I have control over how the program represents the path to be travelled internally, which should alleviate most of your concerns, if you're still reading. Thanks all.

Crayon Shin Chan wrote:

so I will definitely keep the path represented as a path... I'm not very sure about that part.

Is it ever stored in a database?

Nope, will be recalculated every time an image is loaded.