LatentSelector
Pick your winner before the VAE decode — same idea, way cheaper
- latent_image
- LATENT
LatentSelector is the same trick as its sibling ImageSelector, but it filters before the VAE decode - on the compressed latent tensor the sampler actually works with, not on finished pixels. If you're deciding which image from a batch to keep, doing it here saves you the VAE decode of the losers. That's the whole point.
You've seen the cost of VAE work if you've stared at a busy graph long enough: decode takes time and VRAM, and it's lossy on top of it - every encode/decode cycle degrades the image a little, which the community treats as a real quality tax. The author's own tip in the README is blunt about ordering: selector -> encode/decode is better than encode/decode -> selector. Batch of 8, one keeper? Decode just the one, not all eight, and you've skipped seven decodes plus the memory of holding eight full-resolution tensors at once.
Mechanically it's the same as ImageSelector: you pass it the latent and an index string, and it slices the batch dimension. 1-based indexes, comma-separated, : ranges with left bound included and right bound excluded - 2: means "from the second latent on", 3:-1 drops the first two and last two. Bad indexes are silently ignored, and if nothing parses, the whole latent passes through unchanged rather than erroring. Same forgiving parser, same 1-based gotcha.
Inputs and outputs
latent_image(LATENT) - a latent dict, typically straight out of VAEEncode or the samplerselected_indexes(STRING, default"1,2,3") - same syntax as the image version- Output: LATENT, ready to feed a VAE decode, another sampling pass, or an upscale latent input
Wire it between the sampler and the decode and you've got a "pick a keeper then only then spend the pixels" workflow.
One real gotcha: it drops extra latent keys
The source rebuilds the output dict with only the samples key. That's fine for a plain VAEEncode output, but if your latent carries a noise_mask - which happens when you're working with masked/inpainting workflows - that mask is silently dropped. It's a quiet footgun in exactly the workflow where you'd expect to be able to select a latent and keep its mask. If you're inpainting, select before you create the mask, or check your mask still lines up after the node.
Install
Same pack as ImageSelector, so if you have one you have all four. Through ComfyUI Manager (search "Image Selector"), or:
cd ComfyUI/custom_nodes
git clone https://github.com/SLAPaper/ComfyUI-Image-Selector
Then restart. No dependencies beyond what ComfyUI already ships, no model downloads. The latent nodes land in the latent category, alongside their image siblings.
The trade-off to keep in mind: you can't see latents, so picking by index happens blind. The typical loop is preview the decoded images once, then rewire to select the latent that corresponds to the keeper. And remember ComfyUI reruns the graph when you change the index - so pick before you're attached to the current batch, or mute the upstream sampler once you've got what you want.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| latent_image | LATENT | — | |
| selected_indexes | STRING | 1,2,3 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| LATENT | LATENT | — |