DOGMA v54.2 Native-HD Spatial Chunks

Here's a genuinely annoying thing about crop pipelines: you upscale the source to work at native detail, then a crop node resizes a large region back down to a nice round target - undoing the detail you just bought, in the exact region you cared about.

v54.2 is the fix. Same grouping as v54.1, one rule changed, and that rule is the reason to pick it.

What it is

A drop-in variant of DOGMAInstanceChunkCropsV541. Identical inputs, identical outputs, identical grouping logic. What changes is the geometry policy applied after grouping, and the class docstring spells out all three points: small chunks may still be enlarged aggressively to the target long side; chunks already larger than the target are never downsampled and stay at the post-stage-2 native resolution; and native chunks are padded only to a multiple of 16 for Flux/VAE compatibility, with that padding removed again before stitching.

That last detail is more interesting than it looks. Flux-family VAEs want dimensions divisible by 16, so a native chunk of 1803 pixels has to be padded - three pixels of replicated edge. The node records how much it padded, strips it in the stitch step, and the replicated pixels never enter the master. It's the kind of thing you'd otherwise discover as a two-pixel ghost line along the edge of a repaired region.

But the headline is the no-downscale rule. It's the difference between "my crops are all 1792px, which is convenient" and "my crops are all at least 1792px, and the ones that were already bigger kept their resolution." On a restoration job run at native HD, the second one is what you actually wanted the whole time.

How it works

Everything up to the crop extraction is inherited: per-instance boxes from the mask batch at mask_threshold, IoU de-duplication at 0.72, greedy nearest-neighbour grouping in reading order bounded by group_gap_px and max_objects_per_chunk, and merging of nearest chunks when the result exceeds max_chunks. Large groups are still not split, because splitting a single building across two crops is the artifact the whole design is built against.

Then the branch. A chunk whose long side is under target_long_side gets resized up - same as v54.1. A chunk already at or above it is left alone at native resolution and padded to /16. Mask resizing follows the image exactly, so the mask and the crop never disagree about scale, and the padded region is masked out with zeros so it can't influence anything.

The output raster is written in the same format as v54.1: crops, crop_masks, stitch and info, with the stitch metadata carrying the padding amounts alongside the usual position and size.

Inputs and outputs

Ten inputs, unchanged from v54.1 - image, masks, category, kind, target_long_side (768–2048, default 1792), group_gap_px, context_px, max_objects_per_chunk, max_chunks, mask_threshold.

Four outputs: crops (IMAGE list), crop_masks (MASK list), stitch (DOGMA_STITCH) and info (STRING). The stitch list is the one thing you must not improvise with - the pads only get removed by a stitch node reading this metadata, so pair it with a DOGMA stitch from the same version family rather than a generic compositing node.

Install

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

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

Zero external dependencies - the requirements.txt is a single comment stating so - and no model files. Whether it's worth the VRAM is your checkpoint and your card's business.

Common issues

The cost of native chunks is paid in VRAM and time, and it's easy to miss until you hit it. A chunk at 3000px on the long side is not a small sampling job, and it only takes two or three of those in a batch to turn a comfortable run into an out-of-memory one. This is precisely where the pack's barrier and cleanup nodes earn their place.

Second, target_long_side's ceiling is 2048, so it isn't a way to force a minimum resolution the way people assume. Objects smaller than the target get upscaled, which can be very aggressive - a 300px chunk blown up to 1792 is a 6x interpolation before the model ever sees it, and no amount of native-resolution purity prevents the model from having to invent. For small, damaged objects that's occasionally what you want and usually where you should lower the target.

Third: version soup, again. Three nodes in this pack take this exact same ten inputs and differ only in geometry policy. If your crops are coming back at a suspiciously uniform size, you've picked v54.1 without noticing. The info string is what tells you which one you're running - read it once at the start of a session rather than debugging the symptom later.