Shima SEGMath
Boolean algebra for your detection regions
- segs_a
- segs_b
- segs
Once you're past single FaceDetailer and into full detect-refine pipelines, the problem stops being "find the face" and becomes "find the faces, minus the ones I already fixed, plus the hands." SEGMath is a set-operation node for SEGS - the Impact Pack's container for detected regions - that lets you combine two detection results like they were sets. It's the kind of node you reach for when one detector over-picks and you want to subtract a second detector's output instead of hand-editing indices.
Three operations, one output:
- Subtract (A - B) - keeps the segments in A that don't heavily overlap anything in B. Classic use: a person detector finds everyone, a face detector finds faces, subtract gives you bodies-without-faces.
- Add (A + B) - concatenates the two segment lists. A union.
- Intersect (A AND B) - keeps only A's segments that overlap something in B. "The faces that are also in the upper half" style filtering.
How it works
It does not touch pixels. It works purely at the SEG-object level: it takes segs_a and segs_b and manipulates the inner list of segment objects, so the output is a valid (shape, seg_list) tuple that any Impact-Pack consumer - DetailerForEach, SEGSPaste, a SEG filter - will accept without complaint.
The interesting bit is the overlap math. For subtract and intersect it renders each segment to a mask via Impact Pack's internals, then measures IoA (intersection over the area of A) between candidate segments. If two segments overlap by more than 30% of A's area, they count as "the same thing." That threshold is hardcoded at 0.3, matching the spirit of Impact's own SEGSIntersectionFilter (which uses IoA > 0.5) but a bit more forgiving. Worth knowing, because it means a big A segment that mostly covers a small B segment survives - the overlap is measured against A, not the smaller one.
Empty-list handling is sane: if A is empty, subtract and intersect return an empty SEGS and add returns B; if B is empty, add returns A. And it assumes both inputs share the same base image shape - mixing SEGS from two differently-sized images is on you.
Installing it
Part of KDB-USJP/shima_wf:
cd ComfyUI/custom_nodes
git clone https://github.com/KDB-USJP/shima_wf
Restart ComfyUI. This node hard-requires ComfyUI-Impact-Pack - it imports impact.core and impact.utils at runtime - which the pack's installer clones automatically if it's missing. No model downloads for this one; it's pure logic.
Real-world gripes
The hardcoded 0.3 IoA threshold means you can't tune "how overlapping is overlapping." For most workflows that's fine; for edge cases where two detections barely graze each other you may need to re-think which detector feeds A. Also note subtract is one-directional - A minus B is not the same as B minus A when the sets differ in size. It's a small, focused tool, and that's the point: put it between two detectors and a detailer, and the region list you're refining is suddenly something you can reason about.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| segs_a | SEGS | — | |
| segs_b | SEGS | — | |
| operation | COMBO | 3 options: Subtract (A - B), Add (A + B), Intersect (A AND B) |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| segs | SEGS | — |