DOGMA FinalMasks v1.0.9

What it is, and why it's still here

DOGMAFinalMasksV109 takes a DOGMA_REVIEW and returns the approved masks plus a report. Functionally it's a thin wrapper - thirteen lines in the source. It strips the pack's internal state markers (DOGMA110_STATE= lines and their relatives, which the search nodes use to carry detection budgets between passes) out of the notes, then hands the whole thing to DOGMAFinalMasksBoundedV2 and returns its outputs.

So why does it exist as its own node rather than being deleted? Because that's this pack's entire versioning policy: existing node IDs never change behaviour. Each release adds new IDs and leaves the old ones doing exactly what they did, so a workflow JSON you saved against DOGMA 1.0.9 loads and produces the same masks on 1.0.14. If you have a V3/V4-era workflow you still run, this node is the reason it kept working through five releases. If you're building anything new, use DOGMAFinalCleanMasksV111 (adds micro-hole repair) or DOGMAFinalCoverageV110 (adds a coverage percentage) instead.

What you get

• review (DOGMA_REVIEW) - the only input, same bundle shape across the family.
• approved_instances (MASK) - up to 32 masks, one per surviving instance, ranked by score * sqrt(area) and de-duplicated by 90% containment before the cap applies. An empty category yields a (0, H, W) tensor and a report saying so, rather than an error.
• report (STRING) - the same report the v2 finisher produces, minus the internal bookkeeping lines. This is the difference you'll actually notice: with the raw v2 node you can see the state markers, here you don't, and the visible report is all audit verdicts and search notes.

The 32-instance cap is worth stating plainly because it's silent. Nothing warns you when the 33rd mask is dropped. If you're near the ceiling, the report's count is the only signal - and if you need more headroom, the v1.0.10 finalizer caps at 64.

The error you might hit

Like every node in this pack, it resolves its dependencies by looking classes up in ComfyUI's node registry at run time:

RuntimeError: DOGMA v2 requires the existing node pack containing DOGMAFinalMasksBoundedV2

If you see that, your install is incomplete - most often the pack's Python files are present but scipy>=1.10 never got installed, so one of the modules failed to import during ComfyUI's startup and never registered its classes. The fix is the requirements line, not a downgrade:

cd ComfyUI/custom_nodes/ComfyUI-DOGMA-Nodes
pip install -r requirements.txt
# restart ComfyUI

The same class of error shows up across the family (DOGMAAuditBatchV114 needs the v56.7 audit-view builder, DOGMAObjectNativeCropsV111 needs DOGMANativeChunkCropsV2) and it's always a partial install, never a version you picked wrong.

Does the mask quality change between finishers?

Barely, and this is the honest answer for most of these variant articles: the finishers all wrap the same bounded_instances ranking and containment dedupe. What differs is the cap (32 vs 64) and the post-processing bolted on top (coverage reporting, or a scipy micro-hole repair limited to enclosed holes of four pixels or fewer inside a 0.5% area budget). If your masks are wrong, they were wrong upstream - in the search queries, the SAM threshold or the audit verdicts. The finisher is arithmetic.

What the pack is good at, and what makes it worth the version sprawl, is provenance: the report from this node tells you which search pass produced a mask, what the audit said about it, and whether the budget truncated the search. When a category comes out with four masks on a scene with forty objects, that report is how you find out why without guessing.

Install

Manager → search DOGMA Nodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/axior/ComfyUI-DOGMA-Nodes
# restart ComfyUI

Only scipy>=1.10 from the shipped requirements.txt; no weights, nothing added to models/, no ComfyUI core patches. The models involved - SAM 3 for the masks, a VLM for the audit - are installed and wired separately, and the KB's caveat about SAM 3's Triton dependency (a real obstacle on Windows) is about those, not this node.