Nodes/XB_ToolBox/XB-BOX - Wan First/Last Frame2Video
ComfyUI Node

XB-BOX - Wan First/Last Frame2Video

Wan first/last frame animation that stays on rails

By wjluoxiao·Created 5 months ago·Updated 6 days ago· 302
XB-BOX - Wan First/Last Frame2Video
  • positive
  • negative
  • vae
  • clip_vision_start_image
  • clip_vision_end_image
  • start_image
  • end_image
  • positive
  • negative
  • latent
width480
height832
length81
batch_size1
vae_tile_size64
scale_methodlanczos
crop_modecenter

Plain image-to-video pins the first frame and lets Wan freewheel the rest - which is fine until you need the clip to end somewhere specific. XB_WanFirstLastFrameToVideo ("XB-BOX - Wan First/Last Frame2Video") is the pack's answer: give it a start image and an end image, and the video has to land on both. It's the Wan equivalent of keyframing, and it's the single most useful node in this pack for short-drama work where scene B has to open exactly where scene A closed.

It does for two frames what XB_WanImageToVideo does for one. The node VAE-encodes both bookend images, then builds a concat_mask that zeros out the start and end regions of the latent - telling the sampler "these parts are already decided, animate between them." It even handles the CLIP vision side: feed it clip_vision_start_image and clip_vision_end_image (both run through a CLIP Vision encode first) and it concatenates their hidden states into a single clip-vision conditioning, so the model carries both faces/identities into the middle of the clip.

Why you'd reach for it

Two workflows lean on this hard:

  • Chained segments. Feed segment A's last frame as both the end image of A and the start image of B. The overlap removes the biggest failure mode of naive chaining - the visible "jump" where character and lighting drift between segments.
  • Deliberate transitions. A camera shot that must finish on a particular composition, a dance that has to resolve on a pose, a looping clip where the last frame must flow back into the first. Wan respects the end frame well enough to make looping genuinely viable, which is a capability people used to leave the ecosystem for.

The inputs that matter

Everything behaves like the I2V node: positive, negative, vae, then width/height (480×832 default), length (81), batch_size, vae_tile_size. The two optional inputs that make it a first/last-frame node are start_image and end_image - supply at least one, ideally both. scale_method and crop_mode control how each bookend is fitted to your target resolution; if your start and end images are different aspect ratios, center crop will handle both but you'll lose edges.

Outputs are positive, negative, latent - straight into the pack's XB_WanSampler, or into the relay chain where it's used as the per-segment engine for the Wan Param Bus long-form pipelines. The length wisdom carries over: keep to 81ish frames (or the 4×-compression-friendly neighbors) or quality starts falling apart.

Install

Identical to the rest of the pack - ComfyUI Manager → XB_ToolBox, or:

cd ComfyUI/custom_nodes
git clone https://github.com/wjluoxiao/XB_ToolBox.git

restart. Pack declares only opencv-python and easyocr as pip deps, ships no weights - the Wan checkpoints, VAE and text encoders are yours. One caveat worth knowing: end-frame fidelity is good, not perfect - the model treats the end image as a strong hint, not a locked contract, so give it a few seeds if the landing pose is critical.

CategoryXB_ToolBox/Pipeline

Inputs (14)

NameTypeDefaultDescription
positiveCONDITIONING
negativeCONDITIONING
vaeVAE
widthINT48016–8192
heightINT83216–8192
lengthINT811–8192
batch_sizeINT11–8192
vae_tile_sizeINT6464–3840
clip_vision_start_imageoptCLIP_VISION_OUTPUT
clip_vision_end_imageoptCLIP_VISION_OUTPUT
start_imageoptIMAGE
end_imageoptIMAGE
scale_methodoptCOMBOlanczos5 options: lanczos, bilinear, bicubic, nearest-exact, area
crop_modeoptCOMBOcenter2 options: center, disabled

Outputs (3)

NameTypeDescription
positiveCONDITIONING
negativeCONDITIONING
latentLATENT