DOGMAInstanceChunkCropsV545

v54.2 fixed the downscaling problem by refusing to shrink a big chunk. v54.5 goes one step further back and asks why the chunk got big in the first place.

The answer is usually that the grouping step was greedy about count and never looked at area. Fix that ordering - check that a group will still fit the resolution budget before you let an object join it - and you stop creating oversized groups instead of dealing with them afterwards.

What it is

The third chunker in the v54 line, and the one to start with if you're building a fresh high-resolution pipeline rather than maintaining an old v54.1 graph. Same ten inputs as its two siblings, same four outputs. The docstring states the design rule: "constrain GROUP SIZE before cropping instead of creating a huge group and then downscaling it. No multi-instance chunk is ever reduced below its native post-upscale resolution."

It inherits v54.2's no-downscale rule and v54.1's no-drop, never-split guarantees. What's new is a per-kind size budget and the loop that respects it.

How it works

The budgets come off kind, and they're both a length and an area. STRUCTURE: a gap floor of 220px, at most 3 objects per chunk, a group length of about 1.36x target_long_side and an area ceiling of 6.8 million pixels. SURFACE: 300px gap, 6 objects, 1.30x, 6.2M pixels. OBJECT: no gap floor, the max_objects_per_chunk you set, 1.25x and 5.8M pixels.

Grouping then differs from the earlier versions in one important way. When a chunk looks at its nearest candidate, it doesn't just check distance - it builds the tentative union box, expands it by context_px, and checks whether that footprint still fits both the length and the area budget. If it doesn't, that candidate is skipped and the next nearest is tried. So a chunk grows up to the limit of what the model can handle at native resolution, rather than growing freely and being resized afterwards.

max_chunks becomes a soft cap here, and that's deliberate. When there are more chunks than you asked for, it merges the nearest pair - but only if the merged crop still fits inside the same budgets. If nothing can be merged within budget, it stops and returns more chunks than you specified, on purpose. The info output says so: "soft max_chunks exceeded to preserve native resolution." Fewer, larger, blurrier chunks is the trade it refuses to make.

The crop step then branches cleanly: chunks below target_long_side are upscaled with Lanczos (through Comfy's own common_upscale), chunks at or above it are padded to /16 and left native. Small objects get their upscale; big regions keep what they had.

Inputs and outputs

image, masks, category (forced), kind (forced), target_long_side (768–2048, default 1792), group_gap_px, context_px, max_objects_per_chunk, max_chunks, mask_threshold - the standard ten.

Outputs are crops (IMAGE list), crop_masks (MASK list), stitch (DOGMA_STITCH) and info (STRING). The stitch metadata here is richer than v54.1's: alongside position and size it carries a model_mode per chunk, the pad amounts, and the original pre-resize dimensions, which is how the stitch step knows which chunks were upscaled and which were left native. The info line reports the unique instance count, the chunk count and members per chunk, plus warnings for soft-cap overflow and for any single instance whose own native crop exceeds the grouping budget - a warning, not an error, because it's kept native anyway.

Install

ComfyUI Manager → search DOGMA Nodes (publisher axior), install, restart. Manual:

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

No external dependencies beyond torch and ComfyUI itself, and nothing in the repo to download. Your checkpoints and segmenter models are separate installs.

Common issues

The area caps mean you can end up with more render passes than you budgeted for, and on a card where each pass is a real cost that's a scheduling problem, not a bug. Read the info string; if it says the soft cap was exceeded, your context_px or object density is what's driving it, not max_chunks.

Small-object upscaling is the other thing to watch. Because a lone 300px detection gets Lanczos'd up to the target, and because OBJECT groups have the smallest budgets, there's a failure mode where a scattered set of small detections becomes many chunks each interpolated 5x or more. That's a lot of model time spent inventing detail for objects the source barely recorded. Raising max_objects_per_chunk for the category, or accepting a lower target_long_side, is usually the better deal.

And the family reminder: v54.1, v54.2 and v54.5 all look identical on the canvas. Check the info prefix before assuming which one is in your graph - the geometry differences are invisible until you examine crop sizes, at which point you've already run the expensive half.