Image Batch To Sublist (mtb)

The description says it plainly: "Splits a large batched tensor into smaller sub-batches for memory-efficient processing." If you've ever loaded a hundred-frame image batch into a workflow and watched it eat every gigabyte of VRAM before the first node even finished, this is the fix. Instead of one giant tensor moving through your graph at once, this node slices it into a Python list of smaller sub-batches, so a downstream node processing them one sub-batch at a time never has to hold more than sub_batch_size frames in memory simultaneously.

Worth noting: this node's category is batch_processing, not the usual mtb/... namespace the rest of the pack uses. The pack's own README flags that its next version is being developed on a separate dev/0.6.0 branch while main stays behind for backward compatibility - this node's naming pattern is a reasonable sign it's one of the newer additions from that line, so behavior here may still be settling.

Where you'd use it

Any time your batch size is big enough to be a VRAM problem - long animation sequences, large upscale batches, anything you'd otherwise process one frame at a time by hand. Split it here, feed the resulting list into whatever downstream processing node or loop construct you're using, then reassemble if you need a single batch back at the end (this node itself only splits; it doesn't provide a matching "combine" step).

Inputs and outputs that matter

• sub_batch_size (default 1, range 1–1000) - how many frames go into each chunk. Smaller keeps peak memory lower but means more chunks to process sequentially; bigger is faster overall but defeats the purpose if it's still too large for your GPU.
• image (optional) - the batch you're splitting.
• mask (optional) - a matching mask batch, split the same way if you're carrying one alongside your images.

Three outputs: image_list and mask_list (both list-typed - this is the actual chunked data), and item_count, a plain INT telling you how many sub-batches came out the other end. That count is handy for wiring into anything downstream that needs to know how many iterations to expect - a loop node, or a Get Item (mtb) call where you want to validate your index is in range first.

Installing it

• ComfyUI Manager - search "MTB Nodes", install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/melMass/comfy_mtb, restart. A manual clone needs pip install -r requirements.txt run inside the comfy_mtb folder first.

No models attached - this is pure tensor-slicing, so the only "dependency" that matters is having enough VRAM headroom for one sub_batch_size-sized chunk plus whatever else is loaded in your graph.

Common issues & troubleshooting

Still running out of memory even after splitting. sub_batch_size controls how many frames go into each chunk, but not what happens once they get there - if the node you're feeding chunks into doesn't actually process them sequentially and release memory between chunks (say, it's a loop-unaware node that just gets called once with a "list" input it secretly loads all at once), you haven't actually saved anything. Confirm your downstream setup genuinely iterates.

image and mask come back mismatched. Both are optional independently - if you only wire one of them, you'll only get a populated list for that one; an unconnected mask input won't magically produce a matching mask_list.

Some mtb nodes fail to load on startup. Standard for this pack given its size - check the console for [comfy_mtb] STATUS and http://127.0.0.1:8188/mtb for what didn't load. Given this node's newer-looking category, if it's missing entirely, it's worth double-checking you're on a recent enough pull of the pack.