LatentOperationSlice

LatentOperationSlice extracts a slice of a latent along one axis - the tensor equivalent of cutting a strip out of an image. It's the node you reach for when you need one channel, one row, one frame of a batch, or a chunk of the width: grab the part, work on it, and if you need it back in place you pair it with the pack's other structural tools. It sounds trivial, and mostly it is - but it has one behavior from the source that will absolutely trip you up the first time.

The mechanism

start_ = start if start != 0 else None
end_   = end if end != 0 else None
step_  = step if 1 < step else None
slices = [slice(None)] * latent.ndim
slices[axis] = slice(start_, end_, step_)
return latent[tuple(slices)]

Four inputs, all integers:

• axis (INT, default -1) - "Axis to slice along." On a 4D [batch, channels, height, width] latent, 0 is batch, 1 channels, 2 height, 3/-1 width.
• start (INT, default 0) - "Start index for slicing."
• end (INT, default 0) - "End index for slicing."
• step (INT, default 1, min 0) - "Step size for slicing."

And now the quirk, straight from the source: zero means "default", not "index 0". A start of 0 becomes None (from the beginning), an end of 0 becomes None (to the end), and a step of 1 or 0 becomes None (default step). Consequences:

• To slice the middle of a batch, start=3, end=7 works - a literal 3:7 slice.
• To slice from index 3 to the end, you write start=3, end=0 (end 0 → "to the end").
• To slice the first N entries, start=0, end=N works because 0-start means "from the beginning."
• But you cannot express a range that ends exactly at index 0 - end=0 always means "to the end." Want the batch minus the last item? That's start=0, end=-1, not end=0.

The most common real use: pulling one item out of a latent batch with axis=0, start=i, end=i+1 - a single-item slice. For width or height strips (say, cropping a latent band), axis=2 or axis=3 with the 0-means-end convention in mind.

The op output

Output is op of type LATENT_OPERATION - a deferred closure, like every node in this pack. ComfyUI-latent-ops builds operations and ships no apply node, so you need a LATENT_OPERATION consumer (Sonar's SonarApplyLatentOperationCFG is the one that exists) or your own apply node. Directly wiring op into a VAE Decode gives you a type mismatch - the pack's universal first trap, by design.

Install

The usual. ComfyUI Manager → search ComfyUI-latent-ops, or git clone https://github.com/hnmr293/ComfyUI-latent-ops into ComfyUI/custom_nodes, then restart. No requirements.txt, no model downloads - plain PyTorch. This is hnmr293's private workbench (sd-webui-cutoff, llul), barely known to the community, so latent_ops/ops.py is your documentation - and it's exactly where you'd have to look to discover the "0 means end" behavior, since no tooltip warns you. Everything registers under hnmr/latent_ops.