Image Batch Strip
Trim the junk frames off a video batch in one setting
- image
- image
- count
Video generators love to give you frames you didn't ask for. Ramp-in and ramp-out frames, freeze frames at the start, duplicate tails after a blend - they all pad your batch and mess up anything downstream that cares about exact frame counts. Image Batch Strip is the two-minute fix: it removes N frames from the start, end, or both ends of an image batch [B,H,W,C].
It's the cleanup counterpart to the Eclipse batch-extension nodes. Extend With Overlap has a cut mode that drops overlap frames from the wrong ends; Strip is the general-purpose version that just trims wherever you point it. Feed it a batch, say "drop the first 3," and you get a batch that starts where the content actually starts.
The three inputs, which is all there is
- image - the batch to trim.
- strip_count (default 1, max 256) - frames to remove.
- position -
start,end, orboth. This is the one that trips people:bothremovesstrip_countframes from each end, so it's 2×N total. Want 2 off each end of a clip? That'sstrip_count=2,position=both.
Outputs are the trimmed image and a count int so you can see what you're left with - handy when you're lining up a batch to match another batch's length before a concat or a loop calculator.
The guardrail that saves your workflow
If stripping would leave zero or fewer frames, the node returns the original batch unchanged instead of exploding or returning an empty tensor. That's friendlier than it sounds: in a reusable workflow where strip_count gets driven by a widget or a slider, a silly value won't brick the graph - it just silently does nothing. The flip side is that "silently does nothing" can confuse you mid-debug, so if your batch isn't shrinking, check that you're not asking for more frames than exist.
Where it fits
The boring, correct place for it: right after video generation or after an overlap-extend, before anything that counts frames - a video saver, a loop calculator, or a preview. "Remove the model's ramp-in freeze" is the tooltip's own description of why these frames exist, and it's accurate: many video models sit on a near-static first frame, and stripping it keeps the timeline honest.
Installing
Part of ComfyUI_Eclipse (r-vage's all-in-one pack). ComfyUI Manager → search ComfyUI_Eclipse, or:
cd ComfyUI/custom_nodes
git clone https://github.com/r-vage/ComfyUI_Eclipse
Restart; find it under Eclipse → Image → Batch Operations. Deps are the usual (torch, numpy, Pillow, opencv-python); run pip install -r requirements.txt on a clean env. Eclipse assumes a current ComfyUI (frontend 1.51.2+ for the modern widgets) and its v4.0 rewrite removed legacy RvTools_v2 nodes - the built-in Workflow Migration Tool covers old saves.
Set both when you're cleaning a full clip's ramp edges, start/end when you know exactly which side the generator polluted. And remember the 2×N math - it's the one genuine gotcha in an otherwise trivial node.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | Image batch [B,H,W,C] to strip frames from. | |
| strip_count | INT | 10–256 | Number of frames to remove. When position='both', this many frames are removed from each end. |
| position | COMBO | end | Which end to strip from: start — remove the first N frames end — remove the last N frames both — remove N frames from each end (2×N total) |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | — |
| count | INT | — |