Thread settings dict through EmbroideryPipeline (currently hardcoded) #76

New issue

Closed

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

Mark commented

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

Owner

Context

EmbroideryPipeline._emit_machine_file() (in src/main_pipeline.py) hardcodes the stitch-generation config:

config = {
    "fill_density_mm": 1.0,
    "fill_stitch_length_mm": 3.0,
    "fill_angle_degrees": 0,
    "running_stitch_spacing_mm": 2.5,
}

The kwargs accepted by process() and process_bytes() are ignored for stitch generation. Callers have no way to influence density, spacing, or stitch length.

Goal

Plumb user-provided settings all the way through to the stitch generators.

Affected call sites

src/main_pipeline.py:_emit_machine_file() — hardcoded config dict
src/main_pipeline.py:_generate_stitches_from_paths() — receives config but doesn't expose it as a parameter on the public API
src/embroidery_converter/satin_stitch_generator.py — generate_satin_stitches(path, config)
src/embroidery_converter/fill_stitch_generator.py — generate_fill_stitches(path, config)
src/embroidery_converter/running_stitch_generator.py — generate_running_stitches(path, config)

Proposed API change

class EmbroideryPipeline:
    def process_bytes(
        self,
        data: bytes,
        output_format: str = "dst",
        machine_profile: Optional[MachineProfile] = None,
        enable_pull_compensation: bool = True,
        settings: Optional[DigitizeSettings] = None,  # NEW
        **kwargs,
    ) -> dict[str, Any]:

DigitizeSettings is the dataclass introduced by the digitize_to_stitches() issue.

What to thread

fill_density_mm -> config["fill_density_mm"]
satin_stitch_spacing_mm -> config["satin_stitch_spacing_mm"]
running_stitch_spacing_mm -> config["running_stitch_spacing_mm"]
min_stitch_length_mm -> config["min_stitch_length_mm"]
max_stitch_length_mm -> config["max_stitch_length_mm"]
max_colors -> physical_optimizer color reduction
machine_profile.hoop_size -> hoop-fit constraint in physical_optimizer
machine_profile.max_stitch_length_mm -> stitches-per-segment budget

Acceptance

process_bytes(data, settings=DigitizeSettings(fill_density_mm=0.8)) produces measurably different stitches than process_bytes(data, settings=DigitizeSettings(fill_density_mm=0.2)) (test: same input, different settings, different stitch counts).
The existing kwargs path still works (no breaking change to process_bytes).
Mark/easystitch-service#1 accepts the service's settings payload and translates it to DigitizeSettings 1:1.

Blocks

Mark/easystitch-service#1 — settings flow is the entire point of the service contract.

Notes

The from_raster branch in _emit_machine_file uses convert_to_stitches(paths, config) which is a stub returning every coordinate as a "normal" stitch. That's a separate bug — issue #3.

## Context `EmbroideryPipeline._emit_machine_file()` (in `src/main_pipeline.py`) hardcodes the stitch-generation config: ```python config = { "fill_density_mm": 1.0, "fill_stitch_length_mm": 3.0, "fill_angle_degrees": 0, "running_stitch_spacing_mm": 2.5, } ``` The `kwargs` accepted by `process()` and `process_bytes()` are **ignored** for stitch generation. Callers have no way to influence density, spacing, or stitch length. ## Goal Plumb user-provided settings all the way through to the stitch generators. ## Affected call sites - `src/main_pipeline.py:_emit_machine_file()` — hardcoded config dict - `src/main_pipeline.py:_generate_stitches_from_paths()` — receives config but doesn't expose it as a parameter on the public API - `src/embroidery_converter/satin_stitch_generator.py` — `generate_satin_stitches(path, config)` - `src/embroidery_converter/fill_stitch_generator.py` — `generate_fill_stitches(path, config)` - `src/embroidery_converter/running_stitch_generator.py` — `generate_running_stitches(path, config)` ## Proposed API change ```python class EmbroideryPipeline: def process_bytes( self, data: bytes, output_format: str = "dst", machine_profile: Optional[MachineProfile] = None, enable_pull_compensation: bool = True, settings: Optional[DigitizeSettings] = None, # NEW **kwargs, ) -> dict[str, Any]: ``` `DigitizeSettings` is the dataclass introduced by the `digitize_to_stitches()` issue. ## What to thread - `fill_density_mm` -> config["fill_density_mm"] - `satin_stitch_spacing_mm` -> config["satin_stitch_spacing_mm"] - `running_stitch_spacing_mm` -> config["running_stitch_spacing_mm"] - `min_stitch_length_mm` -> config["min_stitch_length_mm"] - `max_stitch_length_mm` -> config["max_stitch_length_mm"] - `max_colors` -> `physical_optimizer` color reduction - `machine_profile.hoop_size` -> hoop-fit constraint in `physical_optimizer` - `machine_profile.max_stitch_length_mm` -> stitches-per-segment budget ## Acceptance - `process_bytes(data, settings=DigitizeSettings(fill_density_mm=0.8))` produces measurably different stitches than `process_bytes(data, settings=DigitizeSettings(fill_density_mm=0.2))` (test: same input, different settings, different stitch counts). - The existing kwargs path still works (no breaking change to `process_bytes`). - `Mark/easystitch-service#1` accepts the service's settings payload and translates it to `DigitizeSettings` 1:1. ## Blocks - `Mark/easystitch-service#1` — settings flow is the entire point of the service contract. ## Notes - The `from_raster` branch in `_emit_machine_file` uses `convert_to_stitches(paths, config)` which is a stub returning every coordinate as a "normal" stitch. That's a separate bug — issue #3.