DIAGRAM EDITION  the stages in plain languageReference edition →

Stage 6 of 14

Storing a shared border once, not twice

When two regions touch, there are two easy ways to draw the line between them, and both are wrong: draw it twice and the two copies can drift apart into a hairline gap, or overlap the shapes and the same geometry gets painted twice. This stage stores every shared boundary exactly once, so neither failure is possible.

Technical reference: 06-planar-map.md

A choice most tracers do not get to avoid

Picture two regions of a logo sitting side by side — say, a light shape and a dark shape sharing an edge. A tracer that stores each shape as its own independent outline has to decide what happens exactly on that shared edge, and the obvious approaches both fail in visible ways:

Lay them edge to edge

Each shape gets its own copy of the boundary. The two copies are computed separately, rounded separately, and simplified separately — so they hardly ever agree to the last fraction of a pixel. The result is a hairline seam: a sliver of background showing through exactly where two shapes were meant to meet with no gap at all.

Overlap them slightly

Hide the seam by letting the two shapes overlap by a hair. Now there is no gap — but the same strip of geometry is drawn twice, once by each shape, which is wasteful, and an edit to move or reshape that boundary now has to be made twice, in two different places, or the two copies drift out of sync again.

A widely used tracer, measured against this project's own baseline, was found to sit squarely on that second failure: its output redraws 1.64 times as much geometry as the picture actually needs, against a ground truth of 1.00, and its seams grow 2.4 times worse between a normal view and a four-times zoom.

Store the border once, and let both sides point to it

This stage sidesteps the choice entirely. A boundary between two regions is stored as a single piece of geometry, and both of the regions that touch it simply refer to that same piece by name, one calling it "my edge, walked forward" and the other "my edge, walked backward." There is only ever one copy of the line itself.

Three regions, three borders, each stored once region A region B region C one edge, A and C both point to it
Each line between two colours here is one object in memory, indexed once. Face A knows it borders that edge on one side; face C knows it borders the same edge, the same object, on the other. Move the edge and both faces move with it, automatically, because there is nothing else to keep in sync.

The gain is structural, not a matter of careful rounding. A seam becomes something that cannot be represented at all, rather than something that is merely rare — and overdraw is exactly one copy of every boundary, by construction, not by tuning any threshold after the fact.

What a seam looks like when the guarantee is missing

It is worth seeing the failure this stage removes, concretely, to see why storing the border once is worth the extra bookkeeping.

Two copies of one boundary, rounded independently a hairline gap along the seam — the two copies do not quite agree
Exaggerated for clarity: two shapes, each carrying its own separately rounded copy of what should be the same line, disagree by a fraction of a pixel along its length. Stored once, that disagreement has nowhere to come from.

Topology first, position later

This stage decides only who is adjacent to whom, reading that directly off the exact grid of integer region labels the previous stage produced. It does not yet decide exactly where, to sub-pixel precision, each boundary sits — that comes in the next stage. This ordering is deliberate: because moving a point cannot change which two faces it separates, later stages are free to refine a boundary's exact position as precisely as the picture supports, without ever risking a shape suddenly belonging to the wrong neighbour.

The one genuine ambiguity, resolved once, upstream

There is exactly one situation where "who is adjacent to whom" is not obvious from the label grid alone: four regions meeting at a single shared corner, where the two diagonally opposite ones happen to be the very same shape. Read one way, that shape pinches to a single point there and reopens — a bowtie. Read the other way, two separate shapes simply touch at a point. Whichever reading is correct is decided earlier in the pipeline, by looking at the actual picture rather than the labels; by the time this stage runs, it treats that decision as already made and simply keeps the corner as an ordinary meeting point whenever four different shapes are honestly present. What it does guard against unconditionally is the geometric consequence of the bowtie reading: welding two arms of one shape at a single point produces exactly one shared location for what should be two independently movable corners, and no later stage could ever separate them again once that has happened.

This is why the ambiguous four-way corner is handled here, before any curve is fitted and before any point moves off the pixel grid: once two corners have been welded into one, nothing downstream can tell that a mistake was made.

What this stage hands forward

The result is a structure of faces and shared boundary pieces in which every line in the picture is represented exactly once, referenced by every region that borders it. Every later stage — moving points to their true sub-pixel position, fitting curves, checking for symmetry, writing the final file — works on this shared structure, which is precisely what keeps two sides of one boundary from ever being able to drift apart.