XListRestore
Put every processed image back exactly where it came from
- list_input
- slot_map
- list
- count
Here's the problem this node solves, in one scenario. You have ten image slots but only seven are connected - the other three branches produced nothing. You pack the seven into a compact list with XListCreate, run them through a batch processor like XImageResize, and now you have seven processed images. But your downstream graph reads by position, and if you just re-expand the list you've silently lost track of which result belongs in slot 1 vs. slot 5. XListRestore fixes that: it puts every processed item back into its original slot, and fills the gaps with None so the positions stay aligned.
How it works
Two inputs. list_input is the compact, processed list - usually the output of a batch-processing node whose items originally came from XListCreate. slot_map is the position record that XListCreate saved, so connect XListCreate's slot_map output here. The node then scatters the items back into a sparse list: restored items sit in their original positions, every empty slot is None, and the list length equals the total slot count.
You get two outputs:
- list - the restored, position-correct list, ready to be pulled apart or fed onward.
- count - the total number of slots including empty ones. Wire it into XListPull or XListToPipe and they'll expand to match.
The recommended loop from the pack's changelog is exactly this: XListCreate to pack → XImageResize (or any batch node) to process → XListRestore to scatter back, with the slot_map wired across from the Create side. The processed list goes into list_input; the original slot_map goes into slot_map; positions come out correct.
The validation you should appreciate
This node is strict on purpose, and the errors are unusually readable. Wrong slot_map? It says so. List length doesn't match the map? It says so. And the one people actually hit: if the same slot index appears twice in the map, it means one XListCreate input received a multi-value list that got flattened - one slot can hold only one item, so it refuses rather than silently dropping data. That's the same trap XListCreate warns about: if you plan to restore, keep every input port to a single value.
Installing it
XListRestore ships in ComfyUI-Xz3r0-Nodes (by Xz3r0-M) under ♾️ Xz3r0/Workflow-Processing. ComfyUI Manager: search ComfyUI-Xz3r0-Nodes and install. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/Xz3r0-M/ComfyUI-Xz3r0-Nodes.git
cd ComfyUI-Xz3r0-Nodes
pip install -r requirements.txt
Restart ComfyUI after. No models, no FFmpeg, no GPU - pure graph plumbing, and one of the most useful three-node workflows in the pack once you've got a batch pipeline going.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| list_input | COMFY_MATCHTYPE_V3 | The compact list to restore, usually the output of a batch-processing node (e.g. XImageResize). Its items originally come from XListCreate. | |
| slot_map | xlist_slot_map | The position record saved by XListCreate: which item belongs to which slot. Connect XListCreate's slot_map output here. |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| list | COMFY_MATCHTYPE_V3 | The restored list with items back in their original positions. Empty slots are None. Length equals the count output. |
| count | INT | Total number of slots (including empty ones). Connect to XListPull / XListToPipe to expand their ports. |