GLM BBox JSON Protected Expand
Expand GLM boxes into the dead space, then subtract what you protected
- image
- bbox_json
The GLM extractor tends to return tight boxes around whatever it recognized - a logo's exact glyphs, a banner's text block. For cleanup you often want those regions bigger, to cover the surrounding design element. And you want them bigger without stepping on the parts you're trying to keep. That's this node: it expands every box in B by a percentage of the image size, then removes all protected regions from A from the result.
The key difference from the pack's older A/B expand node is right in the name: here, every A box is protected. There's no matching of B items against A and subtracting pairs - A is simply the no-go zone, full stop. So B's expansion runs toward open space and away from whatever you put in A.
How it works
Each B bbox first grows left/right by horizontal_expand (a percent of image width) and top/bottom by vertical_expand (a percent of image height), clipped to the image. Then all A regions are cut out of it, with safety_margin adding that many pixels of extra protection around every A box. Existing B/A overlap is removed too, so one B record can split into several rectangles - each inheriting B's original desc and class. A B record that gets fully covered just disappears. B records don't block each other, and boxes are half-open: touching an A edge is allowed, positive-area overlap never is (including at diagonal corners).
The inputs
bbox_json_a- protected regions (from one extractor).bbox_json_b- regions to expand (from another - the Dual Extractor is the natural partner).coord_base- the shared base for both inputs:0for pixels, positive (like1000) for normalized.coordinate_order_a/coordinate_order_b- set each independently tox1,y1,x2,y2ory1,x1,y2,x2, matching the prompt that produced that JSON. This is the forgiving bit: the two inputs may use different orders.horizontal_expand/vertical_expand- image-size percentages, step 0.1.safety_margin- extra protected pixels around every A box.
image is required (it supplies dimensions). Output is a single bbox_json in canonical x-first pixel coordinates, which is nice: you can wire it straight into GLM BBox JSON To Mask with coord_base=0 and the default order.
Installing
Part of comfyui-dsocr-bbox. ComfyUI Manager (search "dsocr") or:
cd ComfyUI/custom_nodes
git clone https://github.com/maomaozi/comfyui-dsocr-bbox
restart. The GLM nodes add no dependencies - stdlib HTTP plus pure geometry.
Gotchas
Mind the semantics: this is not "expand B but keep A-B safe" like the DeepSeek A-B node - it's "expand B, then subtract all of A." If you wanted pair-wise avoidance, this isn't the node. Also, because expansion is a percentage of the image (not of each box), the same horizontal_expand value produces very different pixel growth on a wide banner versus a tall product shot - tune per image aspect, not once globally. And if a B record vanishes entirely, that usually means A covered it after expansion, which is the node working as designed, not a bug.
Inputs (9)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| bbox_json_a | STRING | — | |
| bbox_json_b | STRING | — | |
| horizontal_expand | FLOAT | 0.00–100 | — |
| vertical_expand | FLOAT | 0.00–100 | — |
| safety_margin | INT | 00–10000 | — |
| coord_base | INT | 00–100000 | — |
| coordinate_order_a | COMBO | 2 options: x1,y1,x2,y2, y1,x1,y2,x2 | |
| coordinate_order_b | COMBO | 2 options: x1,y1,x2,y2, y1,x1,y2,x2 |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| bbox_json | STRING | — |