DOGMA DenoiseCategory v56.6
The caption contract your crops get held to
- kind
- caption_instruction
- info
Every other node in this pack moves pixels. This one writes a sentence - the prompt your VLM gets when it's asked to describe a single crop - and sorts your category into one of three buckets. That's it. It's the front door of the declarative-caption design, and understanding it is most of understanding why v56.6 exists at all.
Why a node for this
The older DOGMA line fed per-category edit instructions into the diffusion pass: "rebuild the car, strong detail, keep the plates". The v56.6 correction inverts that. Instead of telling the sampler what to do, you ask a vision model what's actually visible in that exact crop, filter the result into a plain description, and let the reference pixels plus that description carry the pass. The KB's captioning guidance says the same thing for LoRA datasets - describe what's there, not what you hope for - and the same reasoning holds here: a factual caption of a specific crop is a narrower, more checkable instruction than a category-level policy.
The author frames it explicitly: "Per-crop visual caption required; no fixed category edit prompt." That string is literally the info output.
How it works
Two things happen in build().
First, a keyword classifier. It tokenises the category string and matches against three sets: buildings/facades/cathedrals/bridges/towers/houses become STRUCTURE; roads, pavement, floors, ground, water, sky, clouds, vegetation, grass and walls become SURFACE; everything else is OBJECT. Word-set matching, not a model - so "cathedral facade" is STRUCTURE, "wall" is SURFACE (a wall is a surface for tiling purposes, which surprises people), and anything unrecognised lands in OBJECT.
Second, the caption instruction, built as a template around your category. The current text asks for a factual 60–110 word description of the visible contents of this exact photographic crop, describing the segmentation target only where actually visible, partial objects as partial, people and vehicles only when visible, no inferred identity/vehicle make/date/location/exact counts, lettering transcribed only if fully legible, and - the load-bearing clause - no restoration requests, editing instructions, preserve/keep/refine commands, quality tags or reference-image wording. That's the contract the next node (DOGMAChunkPromptV566) then enforces mechanically on the answer.
Inputs and outputs
- category - the string from your planner or from an upstream category slot. Both inputs are
forceInput, so both are wires. - project_context - accepted for wiring consistency with the rest of the phase-3 nodes. In the shipped v56.6 code the instruction is built from
categoryalone, so don't expect this one to change the wording.
Outputs:
- caption_instruction - send it to your VLM as the question for each crop.
- kind -
STRUCTURE,SURFACEorOBJECT. This travels the graph as a label; in the v56.6 nodes it doesn't itself alter pixels (DOGMADualMaskV566accepts it and doesn't branch on it). Use it for your own routing and for reading the reports, not as a quality dial. - info - the one-line human summary. Nothing consumes it; you read it when a category is behaving strangely.
Install
comfy node install comfyui-dogma-nodes
# or
cd ComfyUI/custom_nodes
git clone https://github.com/axior/ComfyUI-DOGMA-Nodes
pip install -r ComfyUI-DOGMA-Nodes/requirements.txt
Restart afterwards, and load a current workflow rather than an older DOGMA graph - the README's own guidance is "use workflow V56.19" for the 1.0.7 release. The pack downloads no models; you supply the VLM (the DOGMA graphs use Qwen3-VL via comfyui_vlm_nodes) and the Klein checkpoint for the diffusion side.
Gotchas
The classifier is only as good as the word in your category string. "Motorway" is OBJECT here (it's not in the SURFACE list), "tarmac" is OBJECT, but "road" is SURFACE. If your kind output looks wrong, fix the category string rather than the node.
And the real failure mode is upstream of this node: this instruction buys you nothing if the VLM answering it is a censor-prone API or a captioner that likes to editorialise. The v56.6 pipeline assumes a local vision model with reasonable prompt adherence - the author's own baseline is Qwen3-VL - because the whole design depends on getting description back instead of advice. Give it a chatty model and ChunkPrompt will spend its time deleting things.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| category | STRING | — | |
| project_context | STRING | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| kind | STRING | — |
| caption_instruction | STRING | — |
| info | STRING | — |