Building My Own Tool Scanner — Part 6: Stop Reinventing the Vector

At this point, the two ends of the system were taking shape.

At one end:

The Titan Scanner.

At the other:

The Gridfinity Generator.

The scanner could capture an accurate silhouette of the physical tool.

The generator could create the Gridfinity geometry around it.

Now I needed a reliable way to connect the two.

Or, put another way:

How do I turn a mask made from camera pixels into geometry I can actually cut from a 3D model?

My first instinct: do it myself

Naturally, I started processing the contours myself.

The mask gives me the boundary between the tool and the background.

Follow that boundary and I get a contour.

Simple enough.

Except a camera image contains a lot of pixels.

Following the boundary of a real object can produce thousands of contour points.

That's technically a very detailed description of the shape.

It's also far more information than I actually need.

A nearly straight section of a ratchet handle doesn't need hundreds of individual points describing it.

So now I need contour simplification.

But simplify too aggressively and I start changing the actual geometry.

Don't simplify enough and I end up passing unnecessarily complicated profiles further down the pipeline.

Then there are internal holes.

Small features.

Sharp corners.

Noise.

Suddenly my simple contour extraction has become another project in itself.

I already had the mask

Eventually I realised I was approaching the problem backwards.

The scanner had already done the difficult bit.

It had produced a dimensionally calibrated mask representing the silhouette I wanted.

I didn't necessarily need to write my own complete vectorisation system on top of it.

There are already extremely mature tools for turning raster images into vectors.

One of them was already sitting on my computer.

Inkscape.

So I changed the pipeline.

Raster to vector

The scanner generates the mask.

That mask is then vectorised using Inkscape.

Instead of carrying thousands of raw pixel-derived contour points forward, I now get a proper vector representation of the tool profile.

The vector can be cleaned and simplified while preserving the shape that actually matters.

The scanner's calibration provides the real-world dimensions required to ensure that vector represents the physical tool at the correct scale.

Now I have exactly what I wanted from the beginning:

A dimensionally meaningful 2D representation of the actual physical object.

And importantly, it's in a format that's much easier to use further down the manufacturing pipeline.

Don't recreate the tool

This was another point where simplifying the problem made everything considerably easier.

I don't need to build a CAD model of the tool.

I don't need to know the radius of every curve.

I don't need to recreate the handles.

I don't even need to know what the object is.

I already have its shape.

So use it.

The vector profile becomes the cutting geometry.

The Gridfinity Generator creates the solid insert.

The vector is positioned where I want the tool.

I specify the required pocket depth.

Then the tool profile is extracted from the solid.

That's it.

Instead of recreating the tool and using that CAD model to create a pocket, I'm effectively using the tool's own scanned silhouette as the cutter.

Give it some breathing room

Of course, making a hole exactly the same size as the measured tool isn't necessarily a good idea.

3D printers have tolerances.

Tools aren't perfect mathematical objects.

And I'd quite like to be able to remove the tool again after putting it in. 😂

So clearance has to be incorporated into the resulting pocket.

Physical testing became important here.

A profile can be dimensionally excellent on the screen and still be too tight once it's been through the complete chain:

Camera → segmentation → vector → CAD → slicer → printer → plastic

That final printed part is ultimately the measurement that matters.

The limitation of a silhouette

There is, however, an important limitation to this approach.

The camera is looking straight down.

That means it sees the tool's projected silhouette.

For many tools, that's exactly what I need.

Pliers.

Ratchets.

Spanners.

Handles.

Cutters.

Plenty of tools can be represented extremely well this way.

But some objects change shape significantly with height.

Sockets and extension bars are good examples.

A wide section at the top of an object can hide a narrower section underneath it.

The scanner can't see through the object.

So the silhouette isn't necessarily the same geometry I want at every pocket depth.

That doesn't make the scanner wrong.

It just means a 2D scanner has a 2D scanner's limitations.

And understanding those limitations is considerably more useful than pretending they don't exist.

The complete pipeline

After all those iterations, the process had finally become remarkably close to the stupidly simple idea I started with.

Put the tool on the scanner.

↓

Capture the silhouette.

↓

Map it into calibrated real-world dimensions.

↓

Generate the mask.

↓

Vectorise the mask.

↓

Import the profile into the Gridfinity Generator.

↓

Position it and specify the pocket depth.

↓

Extract the profile from the generated solid.

↓

Generate the printable insert.

That's a long way from sitting at a desk with a pair of calipers and manually recreating a ratchet.

And, importantly:

Both ends of the system now work.

The Titan Scanner works.

The Gridfinity Generator works.

Which left one final test that no calibration report, mathematical model or software preview could answer.

Does the actual bloody tool fit in the actual bloody print?

Next: Part 7 — The Only Test That Really Matters

After camera calibration, polynomial models, illumination experiments, segmentation, masks, vectorisation and building my own Gridfinity Generator...

The next test was considerably less sophisticated.

Print it.

Put the tool in it.

See what happens.

And the first proper result?

It fitted like a glove. 😎