Decompose: Implement real auto-digitize engine — Phase 4: Tatami Fill Stitch Generation #9

New issue

Closed

opened 2026-06-22 15:28:16 +00:00 by Mark · 2 comments

Mark commented

2026-06-22 15:28:16 +00:00

Owner

⚠️ Re-scoped — blocked on #11

This work was originally framed as "implement from scratch." After auditing the
existing ~/Projects/easystitch/ project (a complete Python embroidery CAM with
5-stage pipeline, satin/fill/running generation, ΔE color matching, and PES/DST/
EXP/JEF output), the right shape is call the EasyStitch service rather than
re-implement the algorithms.

Blocked on #11 ("Stand up EasyStitch as an HTTP service for ThreadCraft").
Until that service exists, this work has no backend to call.

Donor code in EasyStitch (do not port — call it):

~/Projects/easystitch/src/embroidery_converter/fill_stitch_generator.py

New scope (post #11)

Tatami fill generation runs in the Python service. The TypeScript
side only renders the result.

Receive stitchObjects[].type == 'fill' from the /v1/digitize
response (introduced in #6).
Render each fill object as a zigzag row pattern. The
stitches[] array is already in the rendered order (zigzag
alternation handled by the service).
Add a src/lib/canvas/fillRenderer.ts that iterates the points
and draws segments between consecutive points.
Do not port the parallel-row + ray-cast-clip algorithm.

Acceptance: a tatami fill region in a test image renders as
alternating-direction rows that visually cover the source polygon,
with row spacing consistent with the configured fillDensityMm
setting.

## ⚠️ Re-scoped — blocked on #11 > This work was originally framed as "implement from scratch." After auditing the > existing `~/Projects/easystitch/` project (a complete Python embroidery CAM with > 5-stage pipeline, satin/fill/running generation, ΔE color matching, and PES/DST/ > EXP/JEF output), the right shape is **call the EasyStitch service** rather than > re-implement the algorithms. > > **Blocked on #11** ("Stand up EasyStitch as an HTTP service for ThreadCraft"). > Until that service exists, this work has no backend to call. > > Donor code in EasyStitch (do not port — call it): - `~/Projects/easystitch/src/embroidery_converter/fill_stitch_generator.py` ## New scope (post #11) Tatami fill generation runs in the Python service. The TypeScript side only renders the result. 1. Receive `stitchObjects[].type == 'fill'` from the `/v1/digitize` response (introduced in #6). 2. Render each fill object as a zigzag row pattern. The `stitches[]` array is already in the rendered order (zigzag alternation handled by the service). 3. Add a `src/lib/canvas/fillRenderer.ts` that iterates the points and draws segments between consecutive points. 4. Do not port the parallel-row + ray-cast-clip algorithm. Acceptance: a tatami fill region in a test image renders as alternating-direction rows that visually cover the source polygon, with row spacing consistent with the configured `fillDensityMm` setting.

Mark added the

triage-approved

label

2026-06-22 15:28:16 +00:00

Mark referenced this issue

2026-06-22 15:28:19 +00:00

Decompose: Implement real auto-digitize engine #3

Mark referenced this issue

2026-06-22 16:00:02 +00:00

Stand up EasyStitch as an HTTP service for ThreadCraft #11

Mark commented

2026-06-22 16:02:41 +00:00

Author

Owner

Blocked on #11 (Stand up EasyStitch as an HTTP service for ThreadCraft).

This work has been re-scoped — see the updated body. The reframe replaces
"implement from scratch" with "call the EasyStitch service and render the
result." #11 must complete first; once the service exposes /v1/digitize and
/v1/export, this work becomes a thin client + canvas rendering job.

cc: #11

**Blocked on #11** (Stand up EasyStitch as an HTTP service for ThreadCraft). This work has been re-scoped — see the updated body. The reframe replaces "implement from scratch" with "call the EasyStitch service and render the result." #11 must complete first; once the service exposes `/v1/digitize` and `/v1/export`, this work becomes a thin client + canvas rendering job. cc: #11

Mark referenced this issue

2026-06-22 16:02:41 +00:00

Stand up EasyStitch as an HTTP service for ThreadCraft #11

Mark commented

2026-06-23 22:05:23 +00:00

Author

Owner

Blocked-on update

This issue is blocked on easystitch-service#1 ("FastAPI wrapper exposing easystitch pipeline as HTTP service").

Why: tatami fill generation runs in the service; rendering the response is the TS-side work.

The parent ticket [Kimi_Agent_Brother_10_Digitizing_App#11] is the integration contract. The actual implementation lives in Mark/easystitch-service. When easystitch-service#1 closes, this issue can move forward.

There is also a frontend-side wiring issue: [Mark/easystitch-service#3] ("TypeScript client wrapper + vite dev proxy") — that one will be mirrored into the ThreadCraft repo as a frontend sub-issue when it's ready to dispatch.

## Blocked-on update This issue is blocked on **easystitch-service#1** ("FastAPI wrapper exposing easystitch pipeline as HTTP service"). **Why:** tatami fill generation runs in the service; rendering the response is the TS-side work. The parent ticket [Kimi_Agent_Brother_10_Digitizing_App#11] is the integration contract. The actual implementation lives in [Mark/easystitch-service](https://forgejo.tail018ac4.ts.net/Mark/easystitch-service). When easystitch-service#1 closes, this issue can move forward. There is also a frontend-side wiring issue: [Mark/easystitch-service#3] ("TypeScript client wrapper + vite dev proxy") — that one will be mirrored into the ThreadCraft repo as a frontend sub-issue when it's ready to dispatch.

Mark referenced this issue from a commit

2026-06-25 03:08:07 +00:00

feat(client): add typed easystitch-service TS client + vite dev proxy

Mark

2026-06-27 09:04:16 +00:00