stitchPreference has no effect on /v1/digitize output — all 3 accepted values produce byte-identical PES #39

New issue

Open

opened 2026-09-29 21:07:54 +00:00 by Mark · 0 comments

Mark commented

2026-09-29 21:07:54 +00:00

Owner

Bug: stitchPreference has no effect on /v1/digitize output — three accepted values produce byte-identical PES

Reproduction (verified 2026-09-25)

Upload the same pil_4color.png (200x200, 4 colored quadrants on white) three times, each with a different stitchPreference value:

stitchPreference	digitize ms	stitch count	PES bytes	PES sha256 (first 16)
`balanced`	9451	628500	3772140	(matches)
`quality`	9636	628500	3772140	(matches)
`speed`	9437	628500	3772140	(matches)

All three outputs are byte-identical (pes == pes_q == pes_s returns True).

Expected

stitchPreference is documented in the API contract as a literal field with allowed values balanced | quality | speed. The naming implies:

quality should produce denser stitches, longer processing time
speed should produce coarser stitches, shorter processing time
balanced should be a middle ground

At minimum, the three values should produce different stitch counts or different PES files. They produce the same output.

Evidence from the smoke test

$ python tests/manual/smoke_digitize.py tests/fixtures/simple_square.png
  status: 200
  regions: 2
  stitch objects: 2
  stats: {'totalStitches': 4178, 'colorCount': 2, 'processingMs': 43}

The default balanced produces 4178 stitches on simple_square.png. Same input with quality and speed should differ. (Not separately tested for simple_square.png this session; the 4-color input was tested instead and showed identical outputs across all three prefs.)

Likely cause (not verified — would need source read)

The stitchPreference literal is being accepted by Pydantic validation but not read by the digitize engine. The engine uses fixed settings regardless. Either:

The Pydantic model accepts the field but the engine ignores it
The engine reads it but maps all three values to the same internal config
The engine used to honor it and the wiring broke in a recent refactor

Severity

Medium. The value is documented in the API contract and accepted by validation, so users and front-end code will set it believing it has an effect. The front-end (ThreadCraft) likely passes one of these three values to the service. Today, none of them matter. If the front-end adds a "quality" toggle in the future, it will appear to work but will not change the output — the user will suspect the toggle is broken.

Recommended fix

Either remove stitchPreference from the API contract entirely and accept any string (passing through to a no-op), or
Actually wire it up: read settings.stitchPreference in the digitize engine and pass it to the stitch generator as a quality/density multiplier. Add a regression test that confirms the three values produce three different stitch counts on a fixed input fixture.

Labels

bug
triage-approved
back-end
tech-debt

Filed 2026-09-25 by user-driven bughunt session.

## Bug: stitchPreference has no effect on /v1/digitize output — three accepted values produce byte-identical PES ### Reproduction (verified 2026-09-25) Upload the same `pil_4color.png` (200x200, 4 colored quadrants on white) three times, each with a different `stitchPreference` value: | stitchPreference | digitize ms | stitch count | PES bytes | PES sha256 (first 16) | |---|---|---|---|---| | `balanced` | 9451 | 628500 | 3772140 | (matches) | | `quality` | 9636 | 628500 | 3772140 | (matches) | | `speed` | 9437 | 628500 | 3772140 | (matches) | All three outputs are byte-identical (`pes == pes_q == pes_s` returns `True`). ### Expected `stitchPreference` is documented in the API contract as a literal field with allowed values `balanced | quality | speed`. The naming implies: - `quality` should produce denser stitches, longer processing time - `speed` should produce coarser stitches, shorter processing time - `balanced` should be a middle ground At minimum, the three values should produce *different* stitch counts or different PES files. They produce the same output. ### Evidence from the smoke test ``` $ python tests/manual/smoke_digitize.py tests/fixtures/simple_square.png status: 200 regions: 2 stitch objects: 2 stats: {'totalStitches': 4178, 'colorCount': 2, 'processingMs': 43} ``` The default `balanced` produces 4178 stitches on simple_square.png. Same input with `quality` and `speed` should differ. (Not separately tested for simple_square.png this session; the 4-color input was tested instead and showed identical outputs across all three prefs.) ### Likely cause (not verified — would need source read) The `stitchPreference` literal is being accepted by Pydantic validation but **not read** by the digitize engine. The engine uses fixed settings regardless. Either: 1. The Pydantic model accepts the field but the engine ignores it 2. The engine reads it but maps all three values to the same internal config 3. The engine used to honor it and the wiring broke in a recent refactor ### Severity **Medium.** The value is documented in the API contract and accepted by validation, so users and front-end code will set it believing it has an effect. The front-end (ThreadCraft) likely passes one of these three values to the service. Today, none of them matter. If the front-end adds a "quality" toggle in the future, it will appear to work but will not change the output — the user will suspect the toggle is broken. ### Recommended fix 1. **Either** remove `stitchPreference` from the API contract entirely and accept any string (passing through to a no-op), **or** 2. **Actually wire it up**: read `settings.stitchPreference` in the digitize engine and pass it to the stitch generator as a quality/density multiplier. Add a regression test that confirms the three values produce three different stitch counts on a fixed input fixture. ### Labels - bug - triage-approved - back-end - tech-debt Filed 2026-09-25 by user-driven bughunt session.