🧩 V2 Dynamic Multi-Image Analysis

Here's a node whose honest job is organization: V2 Dynamic Multi-Image Analysis is functionally identical to Dynamic Multi-Image Collector, just living in the pack's v2/Business menu instead of Business. Same eight optional image ports, same images batch output, same summary string. The "Analysis" in the name is aspirational - the node collects; it doesn't analyze. The analysis happens downstream when you feed that batch to a VLM runner.

Why does the pack ship two copies of the same node? Because it's mid-migration. The v2 nodes are the pack's roadmap: the authors are re-organizing the menu into v2/Remote, v2/Local, v2/Text, and v2/Business categories, and these V2 classes are aliases that keep the old behavior while establishing the new IDs. If you're building a fresh workflow, grab the V2 version so you land on the menu structure the pack is clearly moving toward; if you're loading an existing workflow, the old ID keeps working.

What it does (same as the original)

• image_1 … image_8 - all optional IMAGE inputs. Only connected ones get collected.
• images - the concatenated IMAGE batch (frames stacked along the batch dimension). Feed it to Batch Remote VLM Task or a local V2 analysis node.
• summary - a STRING like Collected 4 image input(s), batch=4, handy for a sanity check.

Under the hood it's torch.cat(images, dim=0) - nothing fancier. At least one input must be connected or it raises.

The thing to know before you use it

The name overpromises. If you searched "multi-image analysis" expecting this node to do the comparing, you'll be disappointed - it's purely a batch builder. The comparison (or "what changed between these images", or "caption all of these consistently") happens in whatever you connect the images output to. The pack's real analysis is in the remote/local analysis nodes; this one is the tray that carries the images to them. Set your expectations there and the node will behave exactly as advertised.

Also worth noting: batch semantics. Each input is concatenated as a whole tensor, so feeding a 30-frame video into one port gives you 30 frames in the output batch, not one "item." The summary string is the reliable way to see what actually happened.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/walke2019/ComfyUI-GGUF-VLM.git
cd ComfyUI-GGUF-VLM
pip install -r requirements.txt

Restart ComfyUI; find it under GGUF-VLM → v2 → Business. No model downloads, no extra dependencies beyond the pack's requirements.

Troubleshooting

"At least one image input is required" means nothing is actually connected - check for broken links. A batch that's bigger than you expected usually means one input carried multiple frames (see above). And if your downstream VLM chokes on the batch, that's the context window fighting the frame count - sample fewer frames upstream or lower n_ctx on the loader. The collector is not the place to fix that; it did its job.