Nodes/IAMCCS-nodes/Image Batch Range (VRAM) ???
ComfyUI Node

Image Batch Range (VRAM) ???

Slice a frame batch without a RAM spike

By IAMCCS·Created 11 months ago·Updated 8 days ago· 113
Image Batch Range (VRAM) ???
  • images
  • images
  • count
  • report
moderange
count9
start_index0
end_index9
count_in0
start_index_in0
end_index_in0

Long video work is a war against VRAM, and one of the sneakiest ways to lose it is by accident: a node that takes a 600-frame batch and passes the whole thing downstream even though you only need frames 400–450. The "Lite" in IAMCCS Image Batch Range Lite is the promise - it slices a batch that's already in VRAM without building a huge intermediate copy.

The tooltip on the required images input says it outright: "Source IMAGE batch kept in VRAM." This node is for the in-memory case, where the frames are already loaded as a tensor and you just need a window of them. Its disk-reading sibling, Load Images From Dir (Lite), handles the case where you spill frames to disk instead.

How it works

mode picks the slicing strategy:

  • all - pass everything through.
  • from_start - the first count frames.
  • from_end - the last count frames.
  • range - frames from start_index to end_index (this is the default).

Each mode uses count/start_index/end_index as its knobs. The three optional inputs - count_in, start_index_in, end_index_in - are linked overrides: if a linked value is present and positive, it wins over the widget. That's the pattern that lets one control node drive the slicing parameters across several segments without editing widgets everywhere.

Outputs are images (the sliced batch), count (how many frames you actually got), and report (a text summary of what was selected). The report is worth reading once - it's the fastest way to confirm your range math did what you thought.

Why it lives in IAMCCS/LTX-2

This is squarely aimed at LTX-2 video extension, where the workflow is: generate a segment, keep the tail frames, feed them as context for the next segment. In that loop you're constantly slicing "last N frames" out of the previous generation - which is exactly mode = from_end + count. The author added the VRAM framing because a naive slice in a long loop can balloon memory; this one keeps the operation tight.

Install

Same pack, standard routes:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

or ComfyUI Manager → search IAMCCS, restart. No extra dependencies.

Gotchas

Feeding an empty batch raises a clear error rather than silently returning nothing. And remember the mental model: if your frames are on disk (e.g. saved to avoid holding them in VRAM), this isn't the node - that's the directory loader's job. Use the right one for the memory strategy you picked.

CategoryIAMCCS/LTX-2

Inputs (8)

NameTypeDefaultDescription
imagesIMAGESource IMAGE batch kept in VRAM.
modeCOMBOrange4 options: all, from_start, from_end, range
countINT91–100000
start_indexINT00–100000
end_indexINT90–100000
count_inoptINT00–100000
start_index_inoptINT00–100000
end_index_inoptINT00–100000

Outputs (3)

NameTypeDescription
imagesIMAGE
countINT
reportSTRING