Nodes/ComfyUI-MAINodes/H3 Window Crop (internal)
ComfyUI Node

H3 Window Crop (internal)

The internal node you'll touch only when a window plan is lying to you

By matlowai·Created 17 days ago·Updated about 16 hours ago· 112
H3 Window Crop (internal)
  • images
  • images
  • hold_map
  • splice_map
  • first_frame
  • last_frame
  • report
window_spec

H3 Window Crop is the rare node whose honest description starts with the word "Internal." It's the crop stage of H3 Window Expand, the rolling-window regenerator, and you should almost never wire it by hand. But "almost never" isn't "never," and knowing what it does is the difference between debugging a window plan and being mystified by one.

What it does differently

The other crop node in this pack, H3 Segment Crop, derives its window from the hold map: here's where the holds are, cut around them. H3 Window Crop deliberately does not do that, because the window planner has already made the decisions. The plan specifies the span, the per-side handle widths, and whether each handle is a real-time seam ("cold cut") or a hold-inheriting seam ("hot cut"). This node just executes the plan: it takes the world frames and a window_spec (JSON from the expand node's planner) and crops to that one planned window.

Its outputs mirror Segment Crop's shape - images (the cropped window), hold_map (that window's exact per-frame hold map), splice_map (in world coordinates), first_frame / last_frame (the seam pins), and report - because downstream, a window is a segment: it goes through the same smear → encode → v2v → sample → recover chain as any crop.

When you'd actually touch it

Two situations. First, debugging a plan: if H3 Window Expand's output is wrong and you want to see exactly what the planner told its crop to do, wiring a window_spec through this node by hand isolates the crop stage from the rest of the expansion. Second, building your own driver: if you're hand-rolling a windowed pipeline instead of using the expand/collect pair, this is the crop that respects a pre-authored plan rather than deriving one. The README's framing is blunt - "Wire it by hand only if you are debugging a plan" - and that's the right default.

Install

Ships with matlowai/ComfyUI-MAINodes:

cd ComfyUI/custom_nodes
git clone https://github.com/matlowai/ComfyUI-MAINodes

Restart, under image/minimax/motion. No extra Python deps; you need MiniMax-H3 weights and ComfyUI's H3 support (check the licence's US/EU/UK/Korea carve-outs).

The honest take: for 95% of people this node is a learning aid, not a tool. Read its report when your rolling-window output has a seam in the wrong place, because it tells you what the plan actually chose - window bounds, handle types, seam classification - and that's the information you need to fix the plan. But wire it into your main graph and you're just adding a node that duplicates work the expand driver already does.

Categoryimage/minimax/motion

Inputs (2)

NameTypeDefaultDescription
imagesIMAGEworld frames (or the running splice)
window_specSTRINGJSON from H3 Window Expand's planner

Outputs (6)

NameTypeDescription
imagesIMAGE
hold_mapSTRING
splice_mapSTRING
first_frameIMAGE
last_frameIMAGE
reportSTRING