Bug: every fill region is paired with a duplicate running-stitch region of identical polygon #122

New issue

Closed

opened 2026-08-27 15:28:31 +00:00 by Mark · 1 comment

Mark commented

2026-08-27 15:28:31 +00:00

Owner

Summary

A 2-color SF Giants logo with 3 logical shapes produces 6 regions / 6 stitch objects from the digitizer:

r0  tatami_fill #000000  polygon 11pts
r1  running     #000000  polygon 11pts  ← duplicate of r0
r2  tatami_fill #000000  polygon 32pts
r3  running     #000000  polygon 32pts  ← duplicate of r2
r4  tatami_fill #FD5A1E  polygon  5pts
r5  running     #000000  polygon  5pts  ← duplicate of r4, color also wrong

The shape count doubles. Region r5 (running on the orange panel) is also a color mismatch — registered as black instead of orange. That risks laying black running stitches on top of the orange fill.

Likely cause

region-classifier.ts or pipeline_runner.py is double-classifying each segmented shape as both tatami_fill AND running (probably a registration / underlay outline). When the running companion is the same color as the fill, the on-machine effect is overlapping stitches inside the fill.

Suggested fix

If running is intentional underlay reinforcement, gate it behind a user setting (default OFF) and place it on a thread stop, not inline with the fill color.
Verify the running companion inherits the parent fill color, not a stale default.

Reproduction

# Upload any 2-color PNG (e.g., the shakedown SF logo) at default settings.
curl -X POST http://127.0.0.1:8080/v1/digitize -F image=@logo.png -F "settings={"maxColors":2}"
# Count regions — should equal logical shapes, not 2x.

Severity

LOW-MEDIUM — visual quality issue. Most designs will sew, but thread waste and registration drift may compound on dense fills.

## Summary A 2-color SF Giants logo with 3 logical shapes produces **6 regions / 6 stitch objects** from the digitizer: ``` r0 tatami_fill #000000 polygon 11pts r1 running #000000 polygon 11pts ← duplicate of r0 r2 tatami_fill #000000 polygon 32pts r3 running #000000 polygon 32pts ← duplicate of r2 r4 tatami_fill #FD5A1E polygon 5pts r5 running #000000 polygon 5pts ← duplicate of r4, color also wrong ``` The shape count doubles. Region r5 (running on the orange panel) is also a **color mismatch** — registered as black instead of orange. That risks laying black running stitches on top of the orange fill. ## Likely cause `region-classifier.ts` or `pipeline_runner.py` is double-classifying each segmented shape as both `tatami_fill` AND `running` (probably a registration / underlay outline). When the running companion is the same color as the fill, the on-machine effect is overlapping stitches inside the fill. ## Suggested fix - If running is intentional underlay reinforcement, gate it behind a user setting (default OFF) and place it on a thread stop, not inline with the fill color. - Verify the running companion inherits the parent fill color, not a stale default. ## Reproduction ```bash # Upload any 2-color PNG (e.g., the shakedown SF logo) at default settings. curl -X POST http://127.0.0.1:8080/v1/digitize -F image=@logo.png -F "settings={"maxColors":2}" # Count regions — should equal logical shapes, not 2x. ``` ## Severity LOW-MEDIUM — visual quality issue. Most designs will sew, but thread waste and registration drift may compound on dense fills.

Mark added the

bug

triage-approved

labels

2026-08-27 15:31:09 +00:00

Mark referenced this issue from a commit

2026-09-04 21:34:41 +00:00

fix(raster): stop duplicating every fill with a running companion (Mark/easystitch#122)

Mark referenced this issue from a commit

2026-09-04 21:34:41 +00:00

tests: fix import path for issue #122 raster region border gate

Mark commented

2026-09-04 21:35:08 +00:00

Author

Owner

Fixed in 8cb738f (fix(raster): stop duplicating every fill with a running companion).

Root cause: every fill region was getting a paired running-stitch companion with identical polygon and color, doubling the stitch object count and (in r5) producing a color mismatch (black running on orange fill).

Fix: gate the running-stitch underlay behind a new enable_border_detection flag (default False). When enabled, the underlay inherits the parent fill color instead of a stale default black.

Tests: tests/test_issue_122_duplicate_running_region.py (10 new regression tests, all pass), tests/test_raster_region_borders.py (parametrized gate), full suite (338+ tests) green. Pushed to origin/main (4487757). Closing.

Fixed in 8cb738f (fix(raster): stop duplicating every fill with a running companion). Root cause: every fill region was getting a paired running-stitch companion with identical polygon and color, doubling the stitch object count and (in r5) producing a color mismatch (black running on orange fill). Fix: gate the running-stitch underlay behind a new `enable_border_detection` flag (default False). When enabled, the underlay inherits the parent fill color instead of a stale default black. Tests: tests/test_issue_122_duplicate_running_region.py (10 new regression tests, all pass), tests/test_raster_region_borders.py (parametrized gate), full suite (338+ tests) green. Pushed to origin/main (4487757). Closing.

Mark closed this issue

2026-09-04 21:35:08 +00:00