EmbroideryPipeline.process() should accept raster bytes, not require a file path #33

New issue

Closed

opened 2026-06-22 16:23:19 +00:00 by Mark · 1 comment

Mark commented

2026-06-22 16:23:19 +00:00

Owner

Inefficiency / API friction

EmbroideryPipeline.process(input_path: Path, ...) requires a file on disk.
For an HTTP service (see "Add HTTP service layer"), every request would have
to write the uploaded raster to a temp file, call process(), read the
output, then clean up. That's:

Inefficient: round-trip through disk for every digitize call.
Racy under concurrency: two requests writing to overlapping temp paths.
Error-prone: temp-file cleanup leaks if the process crashes mid-request.
Awkward API: the caller has to know the temp-file naming convention.

Proposal

Add a process_bytes(data: bytes, **kwargs) method (or a parallel
process() overload) that takes the input bytes directly. Internally, use
io.BytesIO to satisfy the raster/SVG readers without touching disk.

The existing process(input_path) stays for CLI compatibility and is
re-implemented as process_bytes(Path(input_path).read_bytes(), ...).

Acceptance

process_bytes(b"\x89PNG...\r\n", output_format="dst") returns the same
result as writing the bytes to a temp file and calling process().
No temp file is created for the bytes path.
Concurrent calls to process_bytes() don't interfere with each other.
The existing CLI path still works.
HTTP service can call process_bytes() directly without disk I/O.

## Inefficiency / API friction `EmbroideryPipeline.process(input_path: Path, ...)` requires a file on disk. For an HTTP service (see "Add HTTP service layer"), every request would have to write the uploaded raster to a temp file, call `process()`, read the output, then clean up. That's: - **Inefficient:** round-trip through disk for every digitize call. - **Racy under concurrency:** two requests writing to overlapping temp paths. - **Error-prone:** temp-file cleanup leaks if the process crashes mid-request. - **Awkward API:** the caller has to know the temp-file naming convention. ## Proposal Add a `process_bytes(data: bytes, **kwargs)` method (or a parallel `process()` overload) that takes the input bytes directly. Internally, use `io.BytesIO` to satisfy the raster/SVG readers without touching disk. The existing `process(input_path)` stays for CLI compatibility and is re-implemented as `process_bytes(Path(input_path).read_bytes(), ...)`. ## Acceptance - `process_bytes(b"\x89PNG...\r\n", output_format="dst")` returns the same result as writing the bytes to a temp file and calling `process()`. - No temp file is created for the bytes path. - Concurrent calls to `process_bytes()` don't interfere with each other. - The existing CLI path still works. - HTTP service can call `process_bytes()` directly without disk I/O.