Get Last Image
Chain Video Clips With Get Last Image
- images
- IMAGE
Get Last Image is the most popular node in this pack by search traffic, and for good reason: it's the one that makes iterative animation possible. DragNUWA only generates a fixed window of frames (14 by default), so a single pass gives you a short clip and then stops. To keep a scene going - to drag a character across a longer path than 14 frames allow - you need the final frame of one generation to become the starting frame of the next. That's this node's entire job.
It takes an IMAGE batch and returns only the last frame: index batch_size - 1 off the batch dimension, no more, no less. Combined with Get First Image it bookends the frame stack that comes out of DragNUWA Run or DragNUWA Run MotionBrush, and it's the frame you'll feed back as the new image input on a second drag. It's also exactly the kind of thing that's trivial to write and easy to get wrong in raw Python, so the pack ships it as a node you can just wire.
Why this is the one people search for
Because "take the last frame and keep going" is the natural way to make DragNUWA do more than a single wobbly 14-frame shot. The loop rig in this pack - Loop, LoopStart_IMAGE, LoopEnd_IMAGE - is built around this exact pattern: generate, grab the last frame, feed it back, repeat. Even without the Loop nodes, a manual chain works: two DragNUWA Run nodes in sequence, with Get Last Image between them, extends your motion path by another 14 frames per hop. It's manual, but it's dead simple and you control every step.
The one input, the one output
- images - an
IMAGEtensor (the frame batch from a run node, or any video-frame stack). - Output: an
IMAGEof just the last frame.
The honest caveat
A batch is not a loop, and this node is not a memory. Get Last Image extracts; whether the graph re-executes and feeds the extracted frame back around is a separate question. The pack's Loop family makes that work through a mutable attribute on a LOOP token plus an IS_CHANGED hook that forces re-runs - which is clever and also exactly the kind of thing that can leave stale frames sitting on a wire if the loop's state doesn't reset. If you see your chain "reusing" an old last frame or the loop appearing to do nothing, that's the loop state, not this node - the extraction itself is bulletproof.
One more: remember motion_bucket_id affects how much the last frame wanders off from your intent. If frame 14 of clip one is already drifting from the image you wanted, chaining it forward compounds the drift. Check the last frame before you commit it to a next pass. For 36 search impressions' worth of "how do I keep the video going," though - this is the node.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |