DOGMA v35.1 Combine 2x2 Test Tiles

Tiled upscales are slow and their failures are boring: you wait twenty minutes, get a mosaic, and then spend the evening bisecting settings. This node is half of a "test lab" branch that exists to make that first pass cheap. It takes four tiles from a 2×2 rehearsal grid and combines them into one small preview image, using the same weighting as the production combiner.

Why four tiles is enough

Tile problems are local and they repeat. Seam visibility, colour drift between tiles, whether your prompt makes the model invent a window in the third tile - all of those show up in the first four tiles you sample. Meanwhile the overhead of a tile is mostly fixed (model already loaded, prompt already conditioned), so the thing that costs you real time is the count of tiles, not their size. A 2×2 at production tile size is roughly a tenth of a 6×7 run and tells you most of what you need to know.

The pack has the whole branch: a test-data builder that picks and coordinates the four tiles, a noise node for aligned test noise, a global test controls node, and this combiner. You run the branch, look at the preview, and only then commit.

What this node does specifically

It's the same math as DOGMACenterWeightedCombineV35 - a cosine ramp along interior edges, raised to center_power, accumulated into a float32 canvas and divided by the accumulated weights so the result is a proper normalized blend. Same reasoning too: a broad Gaussian average over an overlap makes the seam region a ghost of two tiles, which is the one artefact you're testing for. Sharpening the decision means the preview shows you what the tile actually looks like rather than smearing it.

The difference is where the geometry comes from. This node reads test_data (DOGMA_TEST_DATA) instead of DAC_DATA, and it uses a slightly different coordinate convention: test data carries each tile's centre (patch_x/patch_y), the patch dimensions, the overlap, and the list of grid coordinates, so the node computes each tile's top-left as centre − patch/2. That's the shape a test-grid builder produces naturally when it's picking tiles out of a big canvas.

• images (IMAGE) - the list of four sampled tiles.
• test_data (DOGMA_TEST_DATA) - geometry from the test builder, not from the DAC prepare node. Mixing the two types is the mistake to avoid.
• center_power (FLOAT, 1.0–8.0, step 0.25, default 3.0).

Outputs image (IMAGE) and info (STRING) - the info line reports the power and the canvas size, e.g. 2x2 combine power=3.00 / 3072x3072. It does not report how many tiles it used, which is a small annoyance: if your list is short the bottom-right of the preview comes back black, and that's your count check.

Install

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

ComfyUI Manager → DOGMA Nodes, or comfy node install comfyui-dogma-nodes. Zero dependencies - requirements.txt is a comment, pyproject.toml is empty of them, and the node is torch arithmetic. Nothing to download. MIT licensed, and the pack itself is built with a FLUX.2 Klein 9B workflow in mind (the author's samplers are tuned for the 4–6 step distilled build and the 20–50 step base model).

Where people get burned

List plumbing. INPUT_IS_LIST=True, so images must be a list of tiles. Feeding a batch from a standard node is the single most common way to get a confusing error out of this family.

Using it as your production combiner. It will combine whatever list you give it, so it'll happily assemble a finished 40-tile run and look like it worked. But it's built around a 2×2 test geometry and it has no tile-count reporting. Use DOGMACenterWeightedCombineV35 for the real thing - same weighting, DAC_DATA geometry, tile count in the info string.

Reading the preview at the wrong zoom. The point of the test is to inspect a seam at 100%, not to admire a thumbnail. If the four-tile preview looks fine when it's small and the final mosaic looks fine when it's small, you haven't tested anything - you've confirmed that your monitor can't resolve a 12-pixel band. Zoom to 1:1 and look at the join.

Assuming the test transfers perfectly. The four test tiles are sampled in the same run as the production tiles, so they share seeds and conditioning - that's the design and it's why the test is meaningful. What it can't predict is the tail: tile 31, the one with the person in it. Run the lab, then spot-check the full run's worst-looking region rather than the seam you already fixed.