Badge 8.8 Target-Only Execution (DAELab)

What this is for

The 8.7 badge engine gives you a choice when you're picking a local color region: sample from the original flat artwork, or sample from a GPT-generated Color ID Map that has flattened every region into one clean palette color. The map is more reliable - but it's an extra paid generation, an extra cache to keep straight, and one more thing that can be out of date relative to the image you're actually editing.

Badge 8.8 Target-Only Execution is the "just sample the target" variant. Local colors come from the current edit target, full stop. The source switch and the map generation controls are hidden in its workflow, and if anything in the request asks for the map stage, it refuses.

That's the entire product difference. Everything else - the target selection, the draft state, the material lists, manual masks, generation controls, the optical and boundary processing - is inherited straight from 8.7.

How it works

It subclasses the 8.7 executor, and before handing the request over it rewrites it: sampling_policy becomes target_only, workflow_version stays at the 8.7 compatibility value, interaction_revision is pinned to the newer interaction set, use_map goes false, and any color_map or color_map_source fields are stripped. If the request's stage is color_map it raises - there is no map, by design.

It also swaps two prompt templates. Local edits get the constraints/local_repair_88 text instead of the generic repair constraint, and the studio photography prompt gets a side-lighting variant. Then it rewrites every report it returns to say workflow_version: 8.8 and sampling_policy: target_only, so a saved result can't be mistaken for an 8.7 run.

The workflow opts in with extra.daelabBadgeTargetOnlyV1.version=1 - the pack deliberately keeps this distinct from the older 8.8 local-materials experiment, which is a different node with a different job. If you load a workflow that has the 8.8 marker and you're missing this node, the front end will just report an unknown executor.

Same as 8.7, the real work is subgraph expansion: a native OpenAIGPTImageNodeV2 call billed to your ComfyUI account credits, then deterministic splicing so outside the validated mask nothing moves.

The inputs and outputs

request_json - required, multiline string, default {}. Compiled by the 8.8 front end; you don't author it by hand.

Outputs: image and report, same as the 8.7 stage executor. The report is where you confirm the version and sampling policy, plus the effective prompt and the region/call accounting.

Which one you actually want

If your edit target is a clean render where every region is already a solid, distinct color, target-only sampling is simpler and saves you a paid map call each time you touch the target. If your target is a glossy, gradient-y render where the same red appears as six different RGB values depending which way the light hits it, sampling it directly is worse - that's exactly the problem the ID map exists to solve, and you should stay on the 8.7 map path (or its newer revision) instead of fighting this node.

Install

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

Then load the pack's current #8.8 - Badge Workflow. The pack ships a build script for that workflow so the 8.7 file stays byte-identical - if your local 8.8 copy predates the target-only rewrite, rebuild it rather than hand-editing, and the old one is preserved as #8.8-Legacy - Badge Local Materials.json.

You need current ComfyUI core (comfy_api.latest), cv2 and scipy for region geometry, and account credits for the generation calls.

Where people get burned

Hoping to sneak the map back in. It's not hidden behind a toggle, it's rejected at the request level - asking for a color_map stage raises a Chinese-language error about 8.8 only sampling from the edit target. That's the feature, not a bug.

Restarting matters more than usual here: this node is registered from Python, and the front end that decides whether the source switch exists is JavaScript. Update the pack, restart ComfyUI, refresh the browser. Half of the "the toggle is still there" reports in any pack with a custom front end are stale JS, and this one is no exception.