Decompose: Implement real auto-digitize engine — Phase 1: Image Ingestion & Color Quantization #6

Closed
opened 2026-06-22 15:28:13 +00:00 by Mark · 2 comments
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/raster/color_quantizer.py
  • ~/Projects/easystitch/src/raster/image_processor.py
  • ~/Projects/easystitch/src/raster/raster_converter.py

New scope (post #11)

Replace the in-app color quantization with a call to the EasyStitch
service:

  1. On autoDigitize tool activation, take the Fabric.js canvas state
    (or the original uploaded raster), convert to a base64 PNG, and
    POST to http://<service>/v1/digitize with the user's settings.
  2. Receive the regions[] and stitchObjects[] from the response.
  3. Render the regions as overlay polygons on the Fabric.js canvas
    (semi-transparent fill, no stroke) for visual feedback.
  4. Store the stitch objects in the stitchObjects state slot
    (already exists in useWorkspace.ts).
  5. Do NOT port the k-means / flood-fill algorithms. They run in the
    Python service.

Acceptance: clicking the auto-digitize tool on a test image produces
a region overlay + stored stitch objects within 2 seconds end-to-end
on the dev box.

## ⚠️ 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/raster/color_quantizer.py` - `~/Projects/easystitch/src/raster/image_processor.py` - `~/Projects/easystitch/src/raster/raster_converter.py` ## New scope (post #11) Replace the in-app color quantization with a call to the EasyStitch service: 1. On `autoDigitize` tool activation, take the Fabric.js canvas state (or the original uploaded raster), convert to a base64 PNG, and `POST` to `http://<service>/v1/digitize` with the user's settings. 2. Receive the `regions[]` and `stitchObjects[]` from the response. 3. Render the regions as overlay polygons on the Fabric.js canvas (semi-transparent fill, no stroke) for visual feedback. 4. Store the stitch objects in the `stitchObjects` state slot (already exists in `useWorkspace.ts`). 5. Do NOT port the k-means / flood-fill algorithms. They run in the Python service. Acceptance: clicking the auto-digitize tool on a test image produces a region overlay + stored stitch objects within 2 seconds end-to-end on the dev box.
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
Author
Owner

Blocked-on update

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

Why: the /v1/digitize endpoint is implemented in this issue.

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:** the /v1/digitize endpoint is implemented in this issue. 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 2026-06-27 08:08:05 +00:00
Sign in to join this conversation.
No description provided.