Badge Material Region V1 (DAELab)

What this is for

"Make the middle gold" is not a specification. Which middle? How gold? And what happens to the thirteen other regions you didn't mention - does the model leave them alone, or does it reinterpret the whole badge while it's at it?

Badge Material Region V1 turns your flat design's colours into a material plan: each source colour maps to a material from the pack's catalogue, and everything you didn't map falls back to a material you choose - by default transparent clear lacquer. Out come the region masks, the per-region material semantics, and a validation report telling you about empty rules, overlapping colours and how much of the foreground the default is covering.

The critical design decision is right there in the node description: source colours locate regions only. They're not a target colour. The node never says "make this pixel gold"; it says "this region is satin gold, here's its mask", and the actual pixel work happens in a separate, masked model call. That keeps colour and material deliberately separate, which is what stops the classic failure where a "material change" quietly recolours half the badge.

How it works

The panel holds up to 16 groups. Each row carries id, a source color, a matching threshold, a material_id from the catalogue, a color_policy (preserve by default, or material_intrinsic for metals), a material_strength between 0.25 and 1.5, and a reroll_revision you can bump to force a fresh generation for that region without touching anything else. The whole thing normalises into a compact JSON config, which is exposed as material_region_config - optional, and used in preference to the config tucked into the node's workflow properties.

The materials themselves come from web/materials.json: baked enamel, transparent lacquer, satin gold, satin silver, glitter, each with a semantic, an application and an avoid text block plus a thumbnail. Colour policy matters: metals carry an intrinsic_color_hex and can use material_intrinsic (their own metal colour, ignoring the artwork's hue), while everything else defaults to preserve (keep the source colour, change only the surface).

On images it locates each region by colour, restricted to foreground_mask if you supplied one. Regions that match nothing become the default_material_mask. The validation_report is the part people skip and shouldn't: it flags rules that matched no pixels, two rules whose tolerances overlap, and how much of the foreground the default material is claiming - that last number is effectively "how much of your badge did you not decide about".

The inputs and outputs

Inputs are minimal: images (required), foreground_mask (optional - supply it and unconfigured background stops counting as default-material foreground), and material_region_config (optional string, for programmatic runs).

Ten outputs, which is a lot, and two of them are custom types that only wire to nodes that expect them:

• material_semantics - the STRING you send to a prompt/node. This is the one that goes downstream.
• material_assignment (BADGE_MATERIAL_ASSIGNMENT) and material_region_set (BADGE_MATERIAL_REGION_SET) - structured payloads for the pack's other material nodes.
• diagnostic_preview - coloured region map to eyeball.
• default_material_mask - everything falling through to the default.
• validation_report, applied_config, config_digest, config_revision - the audit trail.
• region_mask_batch - the region masks as one batched MASK, one slice per configured region, so you can index them downstream.

Start with diagnostic_preview and validation_report. If the preview looks like the badge you drew, everything else is bookkeeping.

Install

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

The material catalogue and thumbnails live in web/, so the panel needs the front end loaded from this pack. There's a fallback catalogue baked into Python for when materials.json can't be read - which means a partially-installed pack will still run and quietly use a different material list. If your edited catalogue isn't taking effect, that's the discovery path.

Where people get burned

Forgetting the default. Unmapped foreground becomes transparent clear lacquer. On a badge where you meant "leave everything else alone", that's a legitimate reading - but the pack's own 8.4 workflow deliberately sets the default to baked enamel instead, precisely to keep surface continuity across stages. Pick your default consciously; the default_material_mask count tells you how big the decision is.

Overlapping tolerances. Two similar source colours with wide thresholds split a region unpredictably. The validation report warns you; the fix is tighter thresholds or distinct colours in the flat art.

Strength as a magic number. 1.0 is the catalogue's recommended intensity. Going to 1.5 doesn't make glitter more glittery so much as more likely to fail the visibility and spill checks in the downstream diagnostics.

Expecting it to render anything. It doesn't call a model and costs nothing. It produces a plan and masks; the paid call happens elsewhere. That separation is the reason you can iterate on material assignment for free - use it, and don't wire it into a paid branch until the preview and the report look right.