Match Image Batch Size

If you've stitched a Wan-generated video back onto its source background, you've met this problem: the generated clip comes back with a different number of frames than your background, and the stitch node errors out or silently drops frames. The cause is a quirk of Wan's VAE - it compresses time roughly 4x, so it only works in frame counts that follow the 4n+1 pattern (1, 5, 9 … 221, 225), and decoding never gives you back exactly the number you asked for. Match Image Batch Size is the blunt fix: it pads or trims an image batch until its frame count matches a reference batch (or an explicit target), so your counts always line up before the stitch.

It's one node in Enigmatic Nodes, a small utility pack by the individual dev enigmatice. No models, no downloads - pure local tensor work.

How it works

The intent is stated right in the source, and it's unusually specific: the author built it for the Wan-stitch mismatch, telling you to drop it "between WanVideoDecode and InpaintStitchImproved, with the BG image wired into reference." That's the whole job. You give it your generated frames in images, your background in reference, and it matches the generated batch to the background's frame count.

The mechanism is simple and honest about it. If the batch is too long, it trims the tail. If it's too short, it pads by repeating a frame - the last one by default (last_frame), the first (first_frame), or solid black (black). That's it. It doesn't interpolate, it doesn't synthesize content; a padded frame is a copy of an existing one. For stitching purposes that's usually exactly right - a held frame at the end of a clip is far less jarring than a black flash in the middle of a composite.

The inputs that matter

• images - the batch to resize (your Wan-generated frames).
• reference - the batch whose frame count is the target. This takes precedence over target_count when connected, which is a common source of confusion: leave it plugged in and target_count is silently ignored.
• target_count - an explicit target, used only when reference is disconnected. 0 (the default) means pass through unchanged.
• pad_mode - last_frame (default), first_frame, or black. For a stitch, keep last_frame; a held final frame reads as a static end, while black reads as a flash.

The outputs

images - the resized batch. count - the final frame count as an INT, which is genuinely useful if a downstream node needs to know how long the clip is.

Installing it

Same for every node in the pack:

• ComfyUI Manager - search Enigmatic Nodes, install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/enigmatice/comfyui-enigmatic-nodes, then restart.

No model files. The pack declares torch, numpy, scipy, Pillow, opencv-python; ComfyUI core already ships all but opencv-python (which you almost certainly have from another pack), and Manager handles the install.

Common issues

• target_count doesn't do what I set. Right - because reference is connected. Unplug the reference wire if you want the explicit count to win.
• 0 gives you nothing. Yes, that's intentional: 0 means "pass through unchanged." Set a real number.
• The video has a visible glitch at the seam. Remember padding copies a frame - it doesn't create content. If the source clip is shorter than the target, the tail is a hold, not new motion. That's the price of the fix, and it's still better than a stitch that fails.

It's a young pack (mid-2026, no community footprint yet), but this node solves a genuinely annoying, real problem that the Wan ecosystem produces constantly. If you've ever stared at a "mismatched batch sizes" error, this is the one-liner that makes it go away.