Badge 8.8 Stage Execution (DAELab)

What this is for

Say a badge has four colour regions and you want baked enamel on two, satin gold on one and glitter on the last. The 8.7 engine has a material path, but it's one material, one call, one mask. Badge 8.8 Stage Execution was the experiment that let you build a list: each row a color, a tolerance, a material and a strength, and each row gets its own masked call against the same frozen target.

This is the historical 8.8. The pack is refreshingly clear that it's an experiment rather than the recommended path - its workflow has since been superseded by the target-only 8.8 build, and the local-materials version is preserved as #8.8-Legacy - Badge Local Materials.json. Read that as: still works, still registered, don't build your new pipeline on it without a reason.

The reason you might anyway: this is the cleanest example in the pack of a region-list executor done properly - frozen masks, one call per region, union-limited final composite. If you're stealing ideas for your own multi-region edit node, read this one's README.

How it works

The workflow opts in with extra.daelabBadgeLocalMaterialsV1.version: 1, whose nodeId points at a separate instance of Badge Material Region V1 - the node that owns the color-to-material list. The 8.8 request compiler then selects this executor explicitly by setting edit_mode: region_materials. Everything else delegates to the 8.7 backend, unchanged.

Inside, prepare_regions walks your rows: it samples the source colors, computes each region's pixel distance to its configured color, assigns every pixel to the nearest matching color once (ties keep the earlier row), and turns each assignment into a mask. Any row with fewer than 16 pixels aborts before a single model call - that's the "you left a color in the list that matches nothing" guard. Rows are only ever assigned once, so two rows with overlapping tolerances can't both claim a pixel.

Then, for each output: start from the target, apply one masked model call per row, keeping the material's optical response, and take the final composite limited to the union of all region masks. Selection masks are frozen before generation and the edited intermediate is never re-sampled, which is the whole point - re-sampling after the first edit is how you get region 3 sliding off region 2. The call count is honest arithmetic: regions × outputs, plus a colour-finish call when a palette reference is present.

The preview ledger hashes each individual region mask as well as the union, so swapping two ID-map labels can't reuse a validation token just because the union is unchanged. That's a small detail that saves you from applying an edit you previewed against different geometry.

The inputs and outputs

request_json - required string, compiled by the front end. Outputs are image (the batch) and report, which lists each region by id with its selected_pixels, effective_prompt, material_id, material_strength, mask-transport state and whether the region was transported as an alpha mask.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/TeutonicMepheles/ComfyUI-DAELab-Custom-Nodes-Library.git
# restart ComfyUI

Load the legacy workflow (#8.8-Legacy - Badge Local Materials), which carries the opt-in marker and the region node instance. You'll want account credits for the API calls and cv2/scipy for the geometry helpers.

Where people get burned

Count the calls before you commit. Two regions × two variants plus colour finishing is six paid calls for one badge. Four regions × four variants is a bad afternoon.

Rows that match nothing. The 16-pixel floor is the only feedback you get, and it fires before generation - good - but the error names the row by id, so keep ids readable instead of whatever the picker generated.

Overlap. Nearest-match assignment means the colour with the tighter tolerance usually wins, not the one you meant. If two of your source colors are near-neighbours (two teals, two golds), raise the threshold precision or split them in the flat art first.

The validation honesty. The pack's own validation section states plainly that the visual quality of the generated materials was not accepted by its test run, and that the smoke test used a synthetic fixture with no paid calls. Take it at face value: the plumbing is tested, the aesthetic is on you.