Reorder SEGS

The order a SEGS list is in quietly decides a lot. Impact's detailer processes entries in sequence; anything that saves per-region output will number its files in that sequence; and if two runs spend their time in a different order, comparing them gets annoying. Reorder SEGS rewrites the sequence without touching a single field of the SEG objects themselves - same crop regions, same masks, same bboxes, just a different order.

The one condition that matters

This node is for tile grids, and the description says so plainly. It works out the grid by collecting the distinct row spans (each crop's y1/y2 pair) and column spans (x1/x2 pair), sorting them, and mapping every entry onto a logical cell. Then it walks those cells in the requested order and emits whatever sits in each one.

That means two hard requirements, both checked: crop regions must be unique across the set, and there must be at most one entry per logical cell. Scattered detector output - a handful of faces at arbitrary positions on a full frame - will either error on the duplicate check or land multiple regions in one cell and stop. If your SEGS came from a YOLO pass rather than a tiling node, this is the wrong tool.

The five orders

• left_to_right_top_to_bottom - plain raster reading order. Grid row by row, left to right within each row. This is the one to use if you just want deterministic, human-sensible output ordering.
• clockwise / counter_clockwise - an inward spiral: the outer ring of tiles first, then the next ring in, and so on to the centre. If your grid is 3×3, this is ring one then the middle tile.
• clockwise_outward / counter_clockwise_outward - the same spiral running the other way: the centre tile first, then rings expanding outwards.

The outward variants are the interesting ones, and the reason is attention. All the work in a tiled pass is the same cost per tile, but the tiles with the subject in them are the ones you care about, and those are usually central. Processing centre-first means the frame is visibly resolving where it matters while the boring edge tiles grind on - and if you're going to abort a run, you'll know sooner whether it's worth finishing. It also means a first-pass spot check on a partially finished run shows you the interesting part rather than the top-left corner.

Inputs and output

segs in, segs out, plus the order combo. That's the entire node. The header - the source dimensions at the front of the SEGS tuple - is preserved, so the output is the same SEGS type and drops into the same consumers. No re-sorting of pixels happens, so there's no quality cost and no extra GPU work.

Worth pairing with Preview SEGS Regions while you set it up: the preview numbers each region with its index, so the before-and-after of a reorder is one glance instead of guesswork.

Install

Manager: search ComfyUI Utility Suite (publisher tom-m) → install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/tom-m-2020/ComfyUI-Utility-Suite

No models, nothing to download; the pack's only requirement is opencv-python-headless, which this node doesn't use - it's pure Python list manipulation. It's authored against ComfyUI's V3 node API and defines the SEGS socket itself as a duck-typed custom type, so it works with Impact-Pack SEGS without requiring it - but you'll need something from Impact's ecosystem (or this pack's MASK to Tile SEGS) to produce the SEGS in the first place. On an outdated ComfyUI the pack imports and registers nothing.

Troubleshooting

"found multiple entries in logical cell." Two entries share the same row and column spans - usually a grid that got assembled from two different tilings, or duplicate tiles. Deduplicate upstream.

"found duplicate crop_region." The same rectangle appears twice. Some tiling schemes emit edge tiles with identical geometry.

"ambiguous row spans starting at ..." Two different row heights start at the same y. The grid isn't a clean rectangular layout, which is what this node assumes. For odd-shaped layouts, reorder a genuine list with the list nodes instead and keep SEGS as-is.

The order looks right but the output didn't change. You may have been looking at a cached preview. Force a re-run of the preview node.