DOGMA Tile Pass-B Gate v34 — Exact Preserve
If the VLM says 'nothing to fix', keep the source pixel-for-pixel
- generated
- source
- image
- info
Second restoration passes are where good images go bad. You already have a clean master, you run one more tiled pass "for detail", and a handful of tiles come back with slightly different content - a window grate that grew teeth, a roofline that moved two pixels. The second-pass gate exists to spend zero GPU time on those tiles.
What it does (it's five lines and that's the point)
It looks at the incoming prompt string. If it starts with PRESERVE THIS TILE, the node returns source unchanged. Otherwise it returns generated.
That's it. Which sounds like a joke until you see the partner node: DOGMATilePromptComposerV34B - the pass-B prompt writer - reads a FIX: field out of the tile's VLM report, and when there is no fix worth making it emits exactly PRESERVE THIS TILE. Keep the current restored master unchanged.... The two nodes are a matched pair across a graph boundary the pack can't express with a boolean, because the prompt is what travels between them.
The reason it works is that it's exact. It's not blending, not denoising at 0.1, not "gentle" - the source tile is returned byte-identical, so the pass cannot degrade a tile it declined to touch. That's a stronger guarantee than any partial-strength setting, and it's the same instinct as the KB's rule for automatic detailing: don't re-render a region that was already fine. The doc for masking/detailing has a data point on exactly this failure mode - a highly-upvoted reaction to a detailing demo that "the before and after looked the same", i.e. paying render time to change nothing.
Inputs and outputs
generated- whatever the pass-B tile sampler produced.source- the tile as it entered pass B. This is the branch that gets returned.prompt- the STRING from the pass-B composer. Only the first token sequence matters.
Outputs image and info. The info string is a one-line receipt: either VLM requested no repair; exact source tile kept or semantic repair active. Because it's a string, you can pipe it into a text preview and audit which tiles got skipped across a run - genuinely useful when you're tuning how eagerly the VLM reports defects.
Install
ComfyUI Manager → search DOGMA Nodes, or:
cd ComfyUI/custom_nodes && git clone https://github.com/axior/ComfyUI-DOGMA-Nodes
Then restart ComfyUI. Nothing else to do: requirements.txt is literally # No external dependencies., no weights, no API keys. Worth knowing that the pack's README covers only the WAN VACE nodes and the DOGMA samplers - this gate and the rest of the semantic suite are undocumented and register themselves from dogma_semantic_v5641.py.
Where it bites
It's a string match, so it's brittle by design. Rewrite the pass-B prompt yourself, or put any node between the composer and the gate that prefixes text, and the gate stops recognizing the sentinel and always returns generated. If you're building your own prompts, keep the literal PRESERVE THIS TILE opening or reimplement the branch.
Both images must be the same tile at the same resolution. There's no resizing here - a size mismatch surfaces as an error in a later composite rather than in this node, which is the least helpful place to find out.
It doesn't decide anything itself. All the taste lives in the VLM that wrote the FIX: field. A chatty model that reports a defect on every tile makes this node a no-op that costs one branch; a lazy one that says "nothing to fix" everywhere makes pass B pointless. Check the info string distribution before you trust either.
Wire it before the stitch, not after. The whole value is in the tile that never gets pasted - a source-exact tile dropped into a composite is invisible, and a re-generated one you didn't want is a permanent artifact.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| generated | IMAGE | — | |
| source | IMAGE | — | |
| prompt | STRING | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | — |
| info | STRING | — |