Auto-digitize output is off-center, single-color white blob, super-linear scaling — engine unusable for any realistic input #40

New issue

Open

opened 2026-09-30 01:39:15 +00:00 by Mark · 0 comments

Mark commented

2026-09-30 01:39:15 +00:00

Owner

Bug: /v1/digitize output is off-center and produces useless "white noise" stitch patterns at non-trivial sizes

Reproduction (verified 2026-09-25)

User-driven bughunt: uploaded a multi-color image via the front-end (ThreadCraft). The pipeline responded with HTTP 200 and stitched something, but the result was:

Mostly white stitches — the color decomposition failed (filed separately as #38)
Off-center — the stitched region did not align with the input image's bounding box
Oddball pattern — stitches filled the whole hoop area with white fill, not the actual shape
Not useful — produces a single-color blob where there should be a multi-color design

Evidence (API-level, this session)

Same engine via direct API call with a 4-color quadrant test pattern (200x200):

Stat	Value
Input image	200x200 px, 4 distinct RGB colors on white background
Service response time	9451ms (vs. 49ms for the 100x100 simple_square fixture)
Stitch count	628,500 (vs. 4,178 for the 100x100 fixture = 150x more stitches for 4x the pixels)
Stitch objects returned	1 (single white tatami_fill, ignoring input colors)
Output PES size	3.77 MB
Pattern	Single tatami_fill covering what appears to be the full bounding box of all detected regions, in white

Scaling problems

The 100x100 simple_square fixture runs in 49ms and produces 4,178 stitches. The 200x200 4-color fixture takes 9.5 seconds and produces 628,500 stitches. That's:

4x pixel count → 150x stitch count → 120x PES size → 190x processing time

This is super-linear scaling that makes the engine unusable for any input larger than a tiny thumbnail. A 1000x1000 image would take hours and produce tens of millions of stitches — far beyond any real embroidery machine's tolerance.

Off-center / oddball pattern

The output is described by the user as "off-center" and "oddball." Possible causes (not verified):

Region detection finds all 4 colored regions but reports a single polygon that's the union of their bounding boxes
That union is not aligned with the input image's geometric center
The single tatami_fill stitches fill the entire union polygon in white
The "off-center" impression comes from the union polygon being shaped like a + (cross) or asymmetric blob, not the centered design the user uploaded

Severity

Critical. This is the core product. Today the digitizer:

Only works correctly for images with a single non-background color (the simple_square fixture case)
Takes seconds-to-minutes for anything larger than 100x100
Produces garbage output for any multi-color input — single white blob, no color separation, off-center, no useful stitch pattern
Returns 200 OK the whole time, masking the failure from the user and the front-end

A user-facing copy of "auto-digitize your image" is a lie today. The engine is not production-ready for any realistic input.

Recommended fix (in priority order)

Color quantization (#38) — fix the multi-color path so each detected color gets its own stitch object
Region bounding — make sure the union of regions in the output matches the bounding box of the input design, centered at hoop (0,0)
Stitch density — add a hard cap on stitches-per-region (e.g., 50000) and reject inputs that would exceed it with a clear error
Input size cap — reject inputs larger than 500x500 with HTTP 413, or downscale automatically with a clear "input was 1000x1000, downscaled to 500x500" note in the response
Timing budget — if processing takes more than 5 seconds, return a 504 or partial result with a warning header
Telemetry — log stitch count, processing time, and input size for every request so future regressions surface immediately

Labels

bug
triage-approved
back-end
critical

Filed 2026-09-25 by user-driven bughunt session. User's framing: "auto-stitch produced nothing but white stitches in an oddball pattern... not very useful at all... it's all off-center... so it doesn't seem to scale very well... the color decomposition fails... otherwise... no good."

## Bug: /v1/digitize output is off-center and produces useless "white noise" stitch patterns at non-trivial sizes ### Reproduction (verified 2026-09-25) User-driven bughunt: uploaded a multi-color image via the front-end (ThreadCraft). The pipeline responded with HTTP 200 and stitched something, but the result was: - **Mostly white stitches** — the color decomposition failed (filed separately as #38) - **Off-center** — the stitched region did not align with the input image's bounding box - **Oddball pattern** — stitches filled the whole hoop area with white fill, not the actual shape - **Not useful** — produces a single-color blob where there should be a multi-color design ### Evidence (API-level, this session) Same engine via direct API call with a 4-color quadrant test pattern (200x200): | Stat | Value | |---|---| | Input image | 200x200 px, 4 distinct RGB colors on white background | | Service response time | 9451ms (vs. 49ms for the 100x100 simple_square fixture) | | Stitch count | **628,500** (vs. 4,178 for the 100x100 fixture = **150x more stitches for 4x the pixels**) | | Stitch objects returned | **1** (single white tatami_fill, ignoring input colors) | | Output PES size | **3.77 MB** | | Pattern | Single tatami_fill covering what appears to be the full bounding box of all detected regions, in white | ### Scaling problems The 100x100 simple_square fixture runs in 49ms and produces 4,178 stitches. The 200x200 4-color fixture takes 9.5 seconds and produces 628,500 stitches. That's: - **4x pixel count** → **150x stitch count** → **120x PES size** → **190x processing time** This is **super-linear scaling** that makes the engine unusable for any input larger than a tiny thumbnail. A 1000x1000 image would take hours and produce tens of millions of stitches — far beyond any real embroidery machine's tolerance. ### Off-center / oddball pattern The output is described by the user as "off-center" and "oddball." Possible causes (not verified): - Region detection finds all 4 colored regions but reports a single polygon that's the union of their bounding boxes - That union is not aligned with the input image's geometric center - The single tatami_fill stitches fill the entire union polygon in white - The "off-center" impression comes from the union polygon being shaped like a + (cross) or asymmetric blob, not the centered design the user uploaded ### Severity **Critical.** This is the core product. Today the digitizer: 1. Only works correctly for images with **a single non-background color** (the simple_square fixture case) 2. Takes **seconds-to-minutes** for anything larger than 100x100 3. Produces **garbage output** for any multi-color input — single white blob, no color separation, off-center, no useful stitch pattern 4. Returns **200 OK** the whole time, masking the failure from the user and the front-end A user-facing copy of "auto-digitize your image" is a lie today. The engine is not production-ready for any realistic input. ### Recommended fix (in priority order) 1. **Color quantization** (#38) — fix the multi-color path so each detected color gets its own stitch object 2. **Region bounding** — make sure the union of regions in the output matches the bounding box of the input design, centered at hoop (0,0) 3. **Stitch density** — add a hard cap on stitches-per-region (e.g., 50000) and reject inputs that would exceed it with a clear error 4. **Input size cap** — reject inputs larger than 500x500 with HTTP 413, or downscale automatically with a clear "input was 1000x1000, downscaled to 500x500" note in the response 5. **Timing budget** — if processing takes more than 5 seconds, return a 504 or partial result with a warning header 6. **Telemetry** — log stitch count, processing time, and input size for every request so future regressions surface immediately ### Labels - bug - triage-approved - back-end - critical Filed 2026-09-25 by user-driven bughunt session. User's framing: "auto-stitch produced nothing but white stitches in an oddball pattern... not very useful at all... it's all off-center... so it doesn't seem to scale very well... the color decomposition fails... otherwise... no good."