`computeThreadStops` aggregates by `paletteIndex`; `paletteIndex: null` from the engine collapses to one fake stop at index 0 #77

New issue

Closed

opened 2026-09-14 03:24:15 +00:00 by Mark · 0 comments

Mark commented

2026-09-14 03:24:15 +00:00

Owner

Where: src/lib/digitize-adapters.ts:203-218 (computeThreadStops), in concert with src/lib/digitize-adapters.ts:143 (the paletteIndex ?? 0 fallback in fromServiceStitchObject).

Bug:

The easystitch-service engine returns paletteIndex: null for every stitch (see comment at digitize-adapters.ts:120-124 — "The engine currently returns paletteIndex: null because the Brother PR10 catalog lookup is a downstream concern (see issue #24).").
fromServiceStitchObject collapses null → 0 (paletteIndex: obj.paletteIndex ?? 0 as number).
computeThreadStops aggregates by paletteIndex via a Map<number, ThreadStop> keyed on obj.paletteIndex. After the null-collapse, every stitch hashes to 0, so the result is one ThreadStop regardless of how many distinct colors the design actually has.
BottomThreadBar (src/components/workspace/BottomThreadBar.tsx) then displays one color stop even for multi-color designs.

This is the visible side of #24 / #29 — until the catalog lookup lands, the UI shows a single merged thread stop.

Fix consistent with existing patterns:
Mirror how commitDigitizedResult (useWorkspace.ts:391) already keys by hex:

Change computeThreadStops's map key from paletteIndex to a stable identity per distinct color:

const seen = new Map<string, ThreadStop>();
for (const obj of objects) {
  const key = obj.hex ?? obj.colorId;
  if (seen.has(key)) continue;
  seen.set(key, { id: `stop-${seen.size}`, colorId: obj.colorId, paletteIndex: obj.paletteIndex, hex: obj.hex, length: 1.0 });
}
return Array.from(seen.values());

The existing per-hex grouping in commitDigitizedResult (useWorkspace.ts:391) means stitches already share colorId when colors match, so this key is stable across the design.

Acceptance: digitizing a 4-color test image produces 4 thread stops in the bottom bar (not 1).

**Where:** `src/lib/digitize-adapters.ts:203-218` (`computeThreadStops`), in concert with `src/lib/digitize-adapters.ts:143` (the `paletteIndex ?? 0` fallback in `fromServiceStitchObject`). **Bug:** - The easystitch-service engine returns `paletteIndex: null` for every stitch (see comment at `digitize-adapters.ts:120-124` — "The engine currently returns `paletteIndex: null` because the Brother PR10 catalog lookup is a downstream concern (see issue #24)."). - `fromServiceStitchObject` collapses null → 0 (`paletteIndex: obj.paletteIndex ?? 0 as number`). - `computeThreadStops` aggregates by `paletteIndex` via a `Map<number, ThreadStop>` keyed on `obj.paletteIndex`. After the null-collapse, every stitch hashes to `0`, so the result is **one** `ThreadStop` regardless of how many distinct colors the design actually has. - BottomThreadBar (`src/components/workspace/BottomThreadBar.tsx`) then displays one color stop even for multi-color designs. This is the visible side of #24 / #29 — until the catalog lookup lands, the UI shows a single merged thread stop. **Fix consistent with existing patterns:** Mirror how `commitDigitizedResult` (useWorkspace.ts:391) already keys by hex: 1. Change `computeThreadStops`'s map key from `paletteIndex` to a stable identity per distinct color: ```ts const seen = new Map<string, ThreadStop>(); for (const obj of objects) { const key = obj.hex ?? obj.colorId; if (seen.has(key)) continue; seen.set(key, { id: `stop-${seen.size}`, colorId: obj.colorId, paletteIndex: obj.paletteIndex, hex: obj.hex, length: 1.0 }); } return Array.from(seen.values()); ``` 2. The existing per-hex grouping in `commitDigitizedResult` (useWorkspace.ts:391) means stitches already share `colorId` when colors match, so this key is stable across the design. Acceptance: digitizing a 4-color test image produces 4 thread stops in the bottom bar (not 1).