ComfyUI-PainterI2V: fixing the slow motion of Wan2.2 4-step LoRAs

The problem: 4-step distilled LoRAs turn Wan2.2 into slow motion

PainterI2V is an enhanced Wan2.2 image-to-video node, and its whole reason to exist is a specific artefact rather than a general improvement.

That artefact is the slow-motion drag that appears when a Wan2.2 image-to-video workflow is driven by a 4-step LoRA, with lightx2v named as the example. Distilled few-step checkpoints are what make those workflows fast, and the side effect the node addresses is that motion in the result comes out muted. The README states the two problems it solves: it reduces the slow-motion drag by increasing motion amplitude by 15 to 50 percent, and it makes camera movement prompts more responsive while increasing the movement amplitude.

That second half is the part that is not just a slider. A user who writes a camera movement prompt and finds the camera barely moves gets two things at once here: the motion amplitude rises, and the prompt has more influence over how the camera behaves.

The node is designed around a single-frame input, explicitly for Wan2.2 single-frame image-to-video workflows, and it is presented as plug and play, fully compatible with original Wan2.2 workflows. The compatibility claim matters because it means the change is a node swap rather than a rewrite of the graph.

The node was created by the Douyin creator behind the project, and the comparisons in the README come from the author's own tests using the official Wan2.2 model with the Light2v 4-step I2V LoRA V1.0. The README is explicit that the performance with other models awaits the reader's own testing, which is the honest framing to keep in mind before drawing conclusions about your own stack.

Installing: ComfyUI Manager or a manual clone

Two installation paths are documented, and the first is the recommended one.

Through ComfyUI Manager the steps are: open ComfyUI Manager, search for PainterI2V, and click install. That is the whole procedure for anyone already running ComfyUI through the Manager, and it also handles the restart that the manual path asks for explicitly.

The manual path clones the repository into the custom_nodes directory:

```bash # Navigate to ComfyUI's custom_nodes directory cd ComfyUI/custom_nodes # Clone the repository git clone https://github.com/princepainter/ComfyUI-PainterI2V.git ```

Afterwards, restart ComfyUI so that the new node is registered.

The repository is small, and its listing shows why: an __init__.py and a __manifest__.py for the ComfyUI node registration, nodes.py with the implementation, a workflows.json, a second workflow file holding the author's comparison tests, and an image directory with the demonstration clips and screenshots used in the README. The presence of __manifest__.py is what allows the ComfyUI Manager to install the node as a package rather than as a raw git clone, and the shipped workflow files let you load a working graph instead of assembling one from scratch.

Nothing in the tree suggests a Python dependency to install. The node replaces a node in an existing graph and operates on the latents that the Wan2.2 pipeline already produces.

Using it: swap the node, then tune motion_amplitude

The usage instruction is short: in the workflow, replace WanImageToVideo with PainterI2V. Everything else in the graph stays as it was, and the README says to keep all other parameters consistent with the original node.

The one new parameter is motion_amplitude, with 1.15 given as the recommended starting value. The scale is documented as a table of what each value does to the motion, and one column is the reassuring one:

| Parameter | Motion Boost | Brightness Change | Best For | | 1.0 (original) | 0% | None | No difference from the original WAN node | | 1.15 (default) | +15% | None | General use | | 1.3 | +30% | None | Sports action | | 1.5 | +50% | None | Extreme motion |

So at 1.0 the node is a no-op relative to the original Wan node, and across the whole documented range the brightness does not change. That is the claim that makes the feature usable in practice, since a brightness shift would wreck a graded shot.

The scene recommendations follow the same logic, mapping the amplitude to the kind of motion in the prompt: fast motion such as running or jumping gets 1.25 to 1.35, normal motion such as walking or waving gets 1.10 to 1.20, and a slight enhancement gets 1.00 to 1.10. The example prompts in the table pair each range with a phrasing, from "Running forward quickly" to "Walking smoothly" and "Slightly enhance motion and camera movement".

The advanced tips are a small tuning protocol. The best results come with strong motion-related prompts, and if the motion becomes too fast the advice is to reduce motion_amplitude by 0.05 at a time, while if it is still too slow you can push up to 1.4. The prompt guidance is equally direct: describe the rhythm of the motion clearly, and avoid vague verbs like "move" or "walk around".

The algorithm: brightness-protected motion scaling

The README names three principles behind the node, and they are worth understanding because they explain both the benefit and the limits.

The first is brightness-protected motion scaling, described as separating the luminance mean before scaling motion vectors. The problem it solves is specific: if you scale the motion vector of a latent directly, the values in the tensor grow, and a model decoding those values into pixels tends to interpret the growth as a change in brightness. Separating out the luminance mean first, scaling the motion, and recombining means the amplitude change is carried by direction and speed rather than by overall energy, which is why the table can claim no brightness change at any amplitude.

The second is zero latent initialization, described as strictly preserving the temporal dependency chain required by 4-step LoRAs. This is the constraint that makes the node specific to distilled few-step checkpoints. A 4-step sampler has a chain of dependencies between its steps, and the node has to leave that chain intact rather than re-initialising latents in a way that breaks the step-to-step consistency the distillation was trained for.

The third is reference frame enhancement, which uses reference_latents to maintain subject consistency without constraining motion. That phrase is doing careful work. The subject has to stay recognisable across the clip, which is what a reference frame provides, but the reference must not act as an anchor that suppresses movement, which is exactly the failure that produces the sluggish look this node is trying to remove.

Read together, the three principles describe a narrowly targeted intervention: it does not change the model, the sampler or the number of steps, and it only changes how much motion the sampled trajectory carries.

Which version to install: the advanced node and the consolidated package

The README contains a migration trail that is easy to miss, and it matters for anyone arriving now.

The English section states that on 2025-12-30 an upgraded PainterI2Vadvanced was released and is recommended, with its own repository. The Chinese section adds a later step: on 2026-07-25, for convenience of upgrades, all of the author's nodes including PainterI2V were merged into a single node package at the ComfyUI-PainterNodes repository.

So there are three things a new user can install: this original repository, the PainterI2Vadvanced repository, and the consolidated package. The author's recommendation is the advanced node, and the consolidated package is where the nodes live going forward.

There is also a specialist build. The README mentions that if you are using KJ's wan2.2-i2v workflow, there is a node developed specifically for KJ, with the note that the effect is consistent, in the ComfyUI-PainterI2VforKJ repository. That is worth knowing about because it suggests the node's behaviour is sensitive to the surrounding workflow, not only to the model.

None of these repositories have a published release on the platform, and this one's last push was on 2026-08-01 with the repository not archived. The project also carries no licence file in its tree, which means the terms for reuse are not stated in the repository and are a question for the author rather than something you can read off a LICENSE file.

Where PainterI2V is the wrong tool

The first wrong case is a workflow that does not use a 4-step LoRA. The node's rationale is the slow motion that appears with distilled few-step checkpoints, and the zero latent initialization is specifically about preserving the temporal dependency chain those checkpoints require. If your pacing problem comes from the base model, the prompt, the resolution or the frame count, an amplitude multiplier on the motion vectors is not the instrument for it.

The second wrong case is a workflow built around something other than Wan2.2. The node is a modified WanImageToVideo, and the parameters it keeps consistent with the original are Wan2.2 parameters.

The third is a project that needs reproducible, pinned behaviour. There are no releases, the code is a single nodes.py, and the author tested one model plus one LoRA combination, leaving other models to the reader's own testing. That is fine for a hobby workflow and awkward for a pipeline where someone else has to reproduce your result six months from now.

The fourth is any requirement around licensing. The repository ships no licence file, so for a redistribution or a commercial pipeline the terms are simply not stated in the project, and that has to be resolved with the author before you build on it.

The realistic alternative is not another node so much as the opposite approach: use the higher-step sampler with the full Wan2.2 model and accept the longer generation time, or tune the prompt and the LoRA strength instead of the motion vectors. The difference in approach is that PainterI2V changes the trajectory after the model has been loaded, keeping the generation cost of four steps, whereas the higher-step route spends compute to get the pacing from the model itself. Which is the better trade depends on whether your constraint is generation time or model fidelity.

Editorial conclusion

PainterI2V is worth installing if your Wan2.2 image-to-video workflow uses a 4-step LoRA and the output looks like slow motion, because it is a one-node swap with one parameter to tune rather than a model change. It is not the right tool if the pacing problem comes from the base model rather than the distillation, and the author only verified the behaviour against the official Wan2.2 model with the Light2v 4-step I2V LoRA V1.0, so other combinations need their own testing. Verify first that you are installing the version you intend to keep, since the author points new users at PainterI2Vadvanced and has consolidated the nodes into a single package, and that your workflow still uses the original Wan2.2 parameters apart from motion_amplitude.

Frequently asked questions

Official sources

1. Issues
2. princepainter/ComfyUI-PainterI2V on GitHub
3. README