ZML_获取列表项

The list counterpart to the pack's ZML_复制到列表: that node makes a list, this one takes one apart. You feed it any list - images, prompts, seeds, a list your batch node produced - plus an index, and it hands back the single item at that position. The useful extra: a second output reports the list's total length, which is exactly what you want when a downstream step needs to know how many items it's dealing with.

How it works

The node is marked INPUT_IS_LIST = (True, False), so the engine passes the list input as a real Python list and the index as a single value. Inside, it clamps defensively: an index past the end snaps to the last item, a negative index snaps to 0, and an empty list returns (None, 0). So the contract is "give me an index, get back a valid item" - out-of-range never crashes, it just gives you the nearest thing.

That safety is genuinely useful for batch workflows where the list length changes between runs. Wire the length output into a condition or a loop counter and you can branch on "how many did we get this time" without counting yourself.

The inputs

• 输入列表 - any list (*). Accepts any type; the node is polymorphic.
• 索引 - INT, 0–99999, default 0.

Outputs: 选定项 (the item, any type) and 列表总数 (INT).

Installing

Standard pack install:

cd ComfyUI/custom_nodes
git clone https://github.com/zml-w/ComfyUI-ZML-Image

restart, or ComfyUI Manager (search "ComfyUI-ZML-Image"). Translation patch at https://github.com/zml-w/ZZZ_ZML_English_Patch. No extra dependencies.

Common issues

The clamping behavior is the main thing to internalize - it's forgiving, but forgiving can hide bugs. If your index is out of range you get the last item silently, which means a stale or miscalculated index won't error out; it'll just quietly feed you the wrong item. If you're relying on "index 3 must exist," check the length output first. Second, "list" here means a real list output from a list-producing node (like ZML_复制到列表 or a batch-to-list converter) - if you connect a plain single value, the engine may or may not wrap it depending on how the upstream node is marked. Third, note the index is 0-based: item 1 is index 0. The README's own batch-processing examples pair this with list-making nodes for n8n-style "process each item" pipelines, and that's where it earns its keep - pick the Nth image from a batch, extract the Nth prompt, or drive a sequential "load LoRA by index" loop.