Nodes/ComfyUI-xiaozhuguang/小珠光首尾帧
ComfyUI Node

小珠光首尾帧

First and last frame in two clean outputs

By xiaozhuguang·Created 2 months ago·Updated a day ago· 56
小珠光首尾帧
  • image
  • first_frame
  • last_frame

There's a whole category of ComfyUI workflow that starts with "give me the first and last frame of this clip." Looping a video, conditioning an image-to-video model on the end state, checking that a batch of frames actually has a sensible opening and closing - you need the two bookends, and you need them as separate clean images. 小珠光首尾帧 (Xiaozhuguang First Last Frame) does exactly that: one IMAGE batch in, first_frame and last_frame out.

It's the simplest node in the pack and proud of it. In a video pipeline you'll see it wired like this: VideoLoader → FirstLastFrame, then first_frame goes to a text-encode or img2img node as the starting condition, while last_frame goes to a "reverse the clip" or "check the ending" branch. It saves you from the error-prone habit of hand-indexing image[0] and image[-1] with slice nodes, and it stays correct even when the batch length changes between runs.

How it works

Pure tensor slicing: image[0:1] for the first frame, image[-1:] for the last, each kept as a single-frame batch so they drop straight into anything that expects an IMAGE. If the input batch is empty it returns a 1×1 placeholder rather than crashing - about the only defensive branch in the whole node. There's an IS_CHANGED-style cache-friendliness here in spirit; it's a pure function, so ComfyUI's normal caching handles it.

The input and outputs

  • image - any IMAGE batch (a video frame sequence, a stack of images, whatever).
  • first_frame - the first frame, single-image batch.
  • last_frame - the last frame, single-image batch.

No settings. That's the entire interface.

Install

From the ComfyUI-xiaozhuguang pack - Manager (search "ComfyUI-xiaozhuguang"), or:

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

Restart. No dependencies beyond torch.

Gotcha

Not much to trip on, but one thing: if your "video" is a single frame, first_frame and last_frame are the same image - that's correct behavior, and a workflow that assumes they differ (like building a loop) will just make a still. And remember these are references to frames in the batch, not fresh copies of a file - if your upstream loader is reading from input/, this node is the thing that turns "frames" into "images you can actually save and look at."

Categoryxiaozhuguang

Inputs (1)

NameTypeDefaultDescription
imageIMAGE

Outputs (2)

NameTypeDescription
first_frameIMAGE
last_frameIMAGE