Bug: export colors snap to pyembroidery built-in thread table, ignoring source hex #9
Labels
No labels
blocked:needs-attention
blocked:needs-decision
bug
feature-request
in-progress
needs-decompose
quickfix
triage-approved
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Mark/easystitch-service#9
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Round-trip read of exported PES/JEF shows the design colors mutated from the input:
#000000#000000(Black)#000000(Black)#FD5A1E(SF Giants orange)#FE370F(pyembroidery Vermilion)#FF6600(pyembroidery Orange)Root cause
app.py:256-261constructspyembroidery.EmbThread()and callsset_color(r, g, b)without attaching the catalog thread metadata (code, name, brand). pyembroidery writers snap colors to its built-in thread table when the underlying writer (PES/JEF) requires catalog references.Suggested fix
When the request includes a
thread_palette_index(already inStitchObject.palette_index), pass the matchingEmbThreadfrom the catalog — or accept the source hex asEmbThread.description/customso the writer preserves it.Reproduction
Digitize a 2-color image, export to PES, read back, observe thread color deltas:
Severity
MEDIUM — visually noticeable for brand-matched colors (SF orange, Harvard crimson, etc.). Tests should assert color stability, not just stitch count.