DOGMAInstanceChunkCropsV541
DOGMA Instance Chunk Crops v54.1
- image
- masks
- crops
- crop_masks
- stitch
- info
The obvious way to do per-object detailing is to crop each detected object and re-render it. It's also the way that produces a room full of clones - the crowd-of-identical-people failure, where every region re-rendered on the same seed converges on the same face.
This node's answer is to never work on a single instance. It groups detections into spatial chunks and edits those, and its other rule is just as important: nothing gets dropped to make the maths work.
What it is
It's the crop generator in the v54 line, and it sits between your masks and the re-render. You give it the image, the mask batch, the category, and the kind - same three values as the rest of the v54 pipeline - and you get back a list of crops, a matching list of masks, and the geometry needed to put them back.
The docstring is unusually pointed about the design: "Preserve SAM instance identity during grouping, but NEVER edit one instance at a time and NEVER discard detections." Every detected instance ends up in exactly one chunk. That "never discard" property is what separates this from the older clustered-crop nodes, which capped groups and dropped the remainder - fine when you're detailing a face, bad when a dropped detection means a damaged building on the edge of frame never gets repaired.
How it works
Per-instance bounding boxes are taken from each mask at mask_threshold, scaled from the mask's resolution up to the image's, and tiny detections under 3px a side are dropped as noise. Duplicates are then removed by IoU - anything overlapping an already-kept box by 0.72 or more is treated as the same physical object and skipped, which is what collapses SAM's habit of returning several near-identical masks per object.
Grouping is greedy nearest-neighbour. Detections are visited in reading order (top-to-bottom, left-to-right) so the result is stable and inspectable rather than depending on mask order, and each chunk keeps absorbing the closest remaining instance until it hits max_objects_per_chunk or the nearest candidate is further away than group_gap_px. STRUCTURE and SURFACE chips get a bigger gap and a bigger member budget, because they're allowed to be one large coherent region.
Then the two safety nets that define this node. If the run produced more chunks than max_chunks, it merges the two nearest chunks - repeatedly, until it's under the cap. Nothing is sliced off. And if a chunk is bigger than target_long_side, the whole chunk is resized as one piece; it is never spatially split to fit, because splitting a building at a crop boundary is exactly the artifact the chunking exists to avoid. The crop edges are then snapped outward to a 16px grid, which only ever expands the region.
Inputs and outputs
Ten inputs. image (IMAGE) and masks (MASK) are the pipeline's image and your segmenter output. category (STRING, forced) and kind (STRING, forced) come from the prompt node - the kind is what selects the grouping budget. target_long_side (768–2048, default 1792, step 32) is the resolution chunks are normalised to. group_gap_px (0–1200, default 180) is how far apart two objects can be and still share a chunk. context_px (32–640, default 160) is how much surrounding image each chunk carries as context for the model. max_objects_per_chunk (1–20, default 6) and max_chunks (1–64, default 24) are the caps discussed above. mask_threshold (0.05–0.80, default 0.30) is the binarisation point.
Four outputs, three of them lists: crops (IMAGE list), crop_masks (MASK list), stitch (DOGMA_STITCH - the geometry list, containing each chunk's x/y/width/height, source dimensions, group id and member count), and info (STRING). That info line is the one to read: it names the number of unique instances, the number of chunks, and the members-per-chunk breakdown, then states outright that zero detections were dropped and zero instances were split. If those numbers look wrong, the problem is upstream in detection.
Install
ComfyUI Manager → search DOGMA Nodes (publisher axior), restart. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/axior/ComfyUI-DOGMA-Nodes
# restart ComfyUI
No pip installs - the pack has no external dependencies - and no bundled weights. It's tensor maths and geometry.
Common issues
The output lists are the first thing that confuses people. crops is a real ComfyUI list, so it must go into a node that consumes a list - the DOGMA stitch nodes do, and DOGMAImageListToBatchV25 is there for anything that wants a batch instead. Wiring it into a plain IMAGE input gives you a type mismatch or, worse, only the first crop.
The second is chunk count creep. With group_gap_px at 180 on a busy street scene you can end up with twenty-plus chunks, each needing its own sampler pass, and the run becomes slow enough that you'll blame the model. Raising the gap merges more aggressively; raising max_objects_per_chunk does too. Watch the info members-per-chunk readout to see which you're actually getting.
And keep version expectations straight: this is v54.1, the first of three chunkers in the pack with identical input signatures and different geometry policies. v54.2 stops chunks downscaling below native, and v54.5 constrains group size before cropping so nothing needs resizing at all. If you're running high-resolution native chunks, this is the wrong one of the three - and nothing in the UI will tell you, because they all look the same on the canvas.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| masks | MASK | — | |
| category | STRING | — | |
| kind | STRING | — | |
| target_long_side | INT | 1792768–2048 | — |
| group_gap_px | INT | 1800–1200 | — |
| context_px | INT | 16032–640 | — |
| max_objects_per_chunk | INT | 61–20 | — |
| max_chunks | INT | 241–64 | — |
| mask_threshold | FLOAT | 0.300.05–0.8 | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| crops | IMAGE | — |
| crop_masks | MASK | — |
| stitch | DOGMA_STITCH | — |
| info | STRING | — |