小珠光首尾帧
First and last frame in two clean outputs
- 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."
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| first_frame | IMAGE | — |
| last_frame | IMAGE | — |