Assign paletteIndex to each stitch object based on catalog position #81

New issue

Closed

opened 2026-06-24 00:11:40 +00:00 by Mark · 0 comments

Mark commented

2026-06-24 00:11:40 +00:00

Owner

Context

The SAAS service contract (Mark/easystitch-service/docs/api.md) requires every stitch object to carry a paletteIndex: int:

{
  "id": "s0",
  "type": "satin",
  "threadColor": "#aabbcc",
  "paletteIndex": 12,
  "stitches": [{ "x": 1.2, "y": 3.4 }]
}

The pipeline currently tracks stitch_intents with raw colors but never assigns a palette index. ThreadCraft #10 (palette picker UI) needs this index to drive the catalog-name lookup.

Goal

After thread matching (which assigns each color to a catalog entry), assign each stitch object's paletteIndex to the index of the matched catalog entry.

Implementation

After ThreadMatcher.match_color_with_alternatives() resolves each unique color to a catalog entry, build a dict[input_color_hex -> palette_index].
In the stitch object assembly, look up each stitch's threadColor in that dict and set paletteIndex accordingly.
For colors with no close match (above tolerance), paletteIndex is null — the service already models this as paletteIndex: int | None.

Acceptance

After a successful digitize, every stitch object has a paletteIndex (or null for unmatched colors).
Same threadColor across multiple stitch objects produces the same paletteIndex.
Unit test in tests/test_main.py covers index assignment.

Blocks

Mark/easystitch-service#1 — response shape requires paletteIndex.
Mark/Kimi_Agent_Brother_10_Digitizing_App#10 — palette picker UI depends on this.

Notes

Depends on BrotherPR10ThreadLibrary (#4) being available, since the index is into the PR-10 catalog (or whatever catalog is loaded).
The "palette" in this context is the loaded catalog — BrotherPR10ThreadLibrary().entries[i]. Index 0 is the first catalog entry, not the most-used color.

## Context The SAAS service contract (`Mark/easystitch-service/docs/api.md`) requires every stitch object to carry a `paletteIndex: int`: ```json { "id": "s0", "type": "satin", "threadColor": "#aabbcc", "paletteIndex": 12, "stitches": [{ "x": 1.2, "y": 3.4 }] } ``` The pipeline currently tracks `stitch_intents` with raw colors but never assigns a palette index. ThreadCraft #10 (palette picker UI) needs this index to drive the catalog-name lookup. ## Goal After thread matching (which assigns each color to a catalog entry), assign each stitch object's `paletteIndex` to the index of the matched catalog entry. ## Implementation 1. After `ThreadMatcher.match_color_with_alternatives()` resolves each unique color to a catalog entry, build a `dict[input_color_hex -> palette_index]`. 2. In the stitch object assembly, look up each stitch's `threadColor` in that dict and set `paletteIndex` accordingly. 3. For colors with no close match (above tolerance), `paletteIndex` is `null` — the service already models this as `paletteIndex: int | None`. ## Acceptance - After a successful digitize, every stitch object has a `paletteIndex` (or `null` for unmatched colors). - Same `threadColor` across multiple stitch objects produces the same `paletteIndex`. - Unit test in `tests/test_main.py` covers index assignment. ## Blocks - `Mark/easystitch-service#1` — response shape requires `paletteIndex`. - `Mark/Kimi_Agent_Brother_10_Digitizing_App#10` — palette picker UI depends on this. ## Notes - Depends on `BrotherPR10ThreadLibrary` (#4) being available, since the index is into the PR-10 catalog (or whatever catalog is loaded). - The "palette" in this context is the loaded catalog — `BrotherPR10ThreadLibrary().entries[i]`. Index 0 is the first catalog entry, not the most-used color.