DOGMA PrepCrops 1.0.21

This is the preparation-stage crop node - the 1.0.21 ancestor of the Phase3Crops pair, and the one to know if your workflow is on the Phase 3 preparation generation. Same job: resolve which detection owns which pixels, cut each surviving object out at native resolution with context around it, and hand the renderer a tidy list of jobs.

If you have used the later versions, the difference is that this node does not carry a denoise per job. It prepares geometry; denoise belongs to a later generation that stamps it in from the chooser. That is a real constraint, not a cosmetic one - the phase-3 render node expects a denoise value on every job, so this node belongs with the renderer generation that goes with it.

How it works

Ownership first. With overlap_policy set to smaller_regions_first, categories are ordered by total mask area and each claims its pixels against an accumulated occupied map, so a large background cannot consume a small foreground object. The same isolation then runs inside each category, instance by instance, largest first. The report logs how many overlap pixels moved and repeats the pack's own caveat: this is geometry, not semantic verification. Nothing here checks that a mask contains what its category name claims.

Then, per selected category, each surviving instance is cropped with DOGMAPObjectNativeCropsV111: the mask's bounding box plus context_px of surrounding image, scaled toward target_long_side only if needed, padded to a multiple of 32. Two masks come back per crop - a wider one for the noise support and a narrower one for the final blend - both clipped to the owning object's silhouette. That pairing is the mechanism behind the "nothing outside the mask changes" guarantee the render stage enforces later.

Budgets are shared, not first-come. The remaining crop allowance is divided across the categories still to be processed, so one huge category cannot starve the rest. Anything that does not fit is logged as DEFERRED with no caption call, and the total budget is written into the report.

Inputs that matter

• selection (DOGMA_CATEGORIES) - the chosen category bundle.
• context_px (160) - surrounding photo carried into each crop. The knob most worth tuning.
• target_long_side (2048) - per-crop resolution budget.
• max_chunks_per_category (24) and max_total_crops (48) - the budgets.
• group_gap_px (180), max_objects_per_chunk (fixed at 1), overlap_policy (smaller_regions_first only).

Outputs: crop_jobs (DOGMA_PREP_CROPS), selected_masks_after_ownership (IMAGE), crop_geometry_and_time (STRING).

Install

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

Or ComfyUI Manager → DOGMA Nodes, then restart. The pack declares scipy>=1.10 and nothing else - no extra model downloads for this node, since it only slices images and masks.

Where people get burned

Mixing generations. The pack versions its node IDs deliberately, and the changelogs say so outright: existing node IDs keep their behaviour, new nodes are opt-in. Feeding a 1.0.21 job bundle into a 1.0.22 renderer, or a 1.0.22 selection into this node, is the kind of mismatch that produces either a raised schema error or a KeyError rather than a wrong render - which, honestly, is the good outcome.

Reading the preview as the answer. selected_masks_after_ownership shows you what survived ownership. It is a diagnostic, not the masks the renderer uses. If a small object vanished from your render, compare this preview against the mask stage's output before you go digging in the render node: the object was probably claimed by a bigger category, or it never made it into a crop budget in the first place.