Keep Calculator
How many frames do you keep?
- frames_to_keep
Seamless video loops are a numbers game. You generate short overlapping chunks of frames, and whether the loop actually closes depends on getting the frame counts right - which is fiddly enough that Eclipse ships a calculator for it. Keep Calculator answers one specific question: given your total frame count, your context length, your overlap between contexts, and your current loop iteration, how many frames should you keep this pass so the loop comes out whole? It outputs a single integer, frames_to_keep, and the rest of your workflow just follows it.
Why this needs a node at all
Eclipse's video pipeline generates looping clips by sliding a context window across the timeline with overlap between passes - the "keep N, discard overlap, continue" pattern that makes ends meet. Get the arithmetic wrong and you either drop frames, duplicate frames, or end the loop one frame short of a clean cycle. The calculator exists to take that arithmetic off your desk: you tell it the shape of your video and it tells you how much to keep, every loop, with nothing to hand-compute. It's the bookkeeping half of the pair; Loop Calculator in the same pack handles the timing side of the same problem.
The inputs
total_frames- the full frame count of your video (default 16). This is what you're ultimately trying to produce.context_length- the length of each context window in frames (default 8). Your per-pass generation size.overlap_frames- how many frames overlap between consecutive contexts (default 4). This is the seam allowance that makes loops seamless.image_loop_count- which loop iteration you're on (default 1). Because the keep-count can change as the window advances, this lets the node give you a per-iteration answer rather than one number for the whole job.
The output, frames_to_keep, feeds directly into whatever trims or selects frames at the end of a pass - in Eclipse's own vocabulary, this is the "keep" side of the Loop/Keep pair that the pack's video nodes build on.
How to think about it
Start from defaults and watch what happens as you bump each value: increase overlap_frames and the node keeps fewer frames per pass (you're throwing more away for the seam); increase context_length and you keep more. The image_loop_count input is the one that makes this usable in a real loop - a static calculator can't know how far along you are, so if you're running multiple passes, feed it the actual current loop number. If your pipeline is a single-pass generate-and-trim, leave it at 1.
Install
Ships with ComfyUI_Eclipse:
cd ComfyUI/custom_nodes
git clone https://github.com/r-vage/ComfyUI_Eclipse
Or install ComfyUI_Eclipse via ComfyUI Manager and restart. No models, no heavy dependencies - it's integer arithmetic wrapped in a node. If you're building looping video workflows with Eclipse's video nodes, this is the piece that stops you from debugging a broken loop that's actually a broken frame count.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| total_frames | INT | 161β10000 | Total number of frames in the video. |
| context_length | INT | 81β32 | Context length for frame calculation. |
| overlap_frames | INT | 40β32 | Number of overlapping frames between contexts. |
| image_loop_count | INT | 11β1000 | Current loop count for image processing. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| frames_to_keep | INT | β |