The main purpose of this workflow is to make the operation compact when performing repeated generation. It minimizes screen scrolling during operations such as prompt input, input image selection, specifying time, step count, resolution, and, most importantly, LoRa selection. Furthermore, all nodes are fixed to prevent unintended movement, improving usability.

Wan2.2 I2V PainterI2V Workflow

wan22I2VPainteri2v_v10_trainingData.zip

v1.0

v2.4 - The subgraph specification in the model input area has been discontinued and reverted to the v2 specification. The layout has also been changed.We received several reports from the community that models such as CLIP and VAE were not functioning correctly due to the subgraph, and also received feedback that the model placement was unclear. Therefore, we decided to revert to the v2 specification.v2.3 - Layout has been adjusted.v2.2 - The Seed node has been changed from "CR Seed" to "Seed (rgthree)". We've received reports of issues with the CR Seed implementation, so we've made it consistent with the custom node commonly used for this workflow.v2.1 - The GGUF model loader is now available as standard. The input method for the model area has also been changed, allowing bulk input using sub-graph nodes.The number of frames per second was previously fixed at 16 fps, but can now be changed arbitrarily. Accordingly, the RIFE-VFI node multiple can now be changed in the input area.v2.0 - The issue where the second section would not generate has been fixed.<img src="https://image.civitai.com/xG1nkqKTMzGDvpLrqFT7WA/851e1190-f9ad-45b9-a04f-f7ad9884bfb6/original=true/851e1190-f9ad-45b9-a04f-f7ad9884bfb6.jpeg" />The explanations in this workflow are solely my personal opinions. Please be aware that I do not possess expertise in AI generation, and therefore some information may be inaccurate.The main purpose of this workflow is to make the operation compact when performing repeated generation. It minimizes screen scrolling during operations such as prompt input, input image selection, specifying time, step count, resolution, and, most importantly, LoRa selection. Furthermore, all nodes are fixed to prevent unintended movement, improving usability.Links to the Basic models of the Wan2.2CLIP:<a target="_blank" rel="ugc" href="https://huggingface.co/Comfy-Org/Wan_2.1_ComfyUI_repackaged/tree/main/split_files/text_encoders">https://huggingface.co/Comfy-Org/Wan_2.1_ComfyUI_repackaged/tree/main/split_files/text_encoders</a>VAE:<a target="_blank" rel="ugc" href="https://huggingface.co/Comfy-Org/Wan_2.1_ComfyUI_repackaged/tree/main/split_files/vae">https://huggingface.co/Comfy-Org/Wan_2.1_ComfyUI_repackaged/tree/main/split_files/vae</a>Links to the LORAs and nodes used in this workflow(PainterI2V)<a target="_blank" rel="ugc" href="https://github.com/princepainter/ComfyUI-PainterI2V">https://github.com/princepainter/ComfyUI-PainterI2V</a>(PainterI2V Advanced)<a target="_blank" rel="ugc" href="https://github.com/princepainter/ComfyUI-PainterI2Vadvanced">https://github.com/princepainter/ComfyUI-PainterI2Vadvanced</a>(FFGO)<a target="_blank" rel="ugc" href="https://github.com/zli12321/FFGO-Video-Customization">https://github.com/zli12321/FFGO-Video-Customization</a><a target="_blank" rel="ugc" href="https://huggingface.co/Video-Customization/FFGO-Lora-Adapter/tree/main/merged_lora">https://huggingface.co/Video-Customization/FFGO-Lora-Adapter/tree/main/merged_lora</a>PainterI2V is advertised as improving slow motion, but it also enhances camera work. Using it should improve camera movement. Since I intentionally incorporate camera movement into my videos, this node is essential to my workflow.FFGO is a LORA designed to maintain consistency in the input image. Maintaining facial consistency is crucial, especially when dealing with female characters, and I believe FFGO helps in this regard. I have set the weight to 0.3, but feel free to adjust it. However, be aware that too high a weight may affect the video's movement.You can also generate and combine two videos, in which case the final frame of the first generation becomes the starting image of the second generation. Unlike SVI, there is no 5-frame overlap, and the content of the first input image is not preserved. Therefore, depending on the final frame, the face may change significantly, or the movement may appear unnatural.For example, if you look closely at the beach video of a woman I uploaded, you'll notice that a person who wasn't in the first 5 seconds appears in the background, and the movement at the transition is clearly unnatural. These unnatural artifacts are a major drawback. However, if the woman's face is clearly visible in the first generation, it won't become a different person in the second generation.So why combine the two videos using this workflow instead of SVI? Because trying to reproduce the same movement with SVI results in extremely unnatural movement and doesn't work well. This is one of the challenges of video generation with SVI. I believe this workflow is suitable for achieving dynamic yet natural movement.Technically, it's possible to loop the second video or combine a third or subsequent video, but in my experience, the resulting video becomes unusable. I consider two videos to be the practical limit.I hope this workflow helps make video creation using PainterI2V and FFGO more enjoyable.

Wan2.2 I2V PainterI2V Workflow Kenpechi

v2.4 - The subgraph specification in the model input area has been discontinued and reverted to the v2 specification. The layout has also been changed. We received several reports from the community that models such as CLIP and VAE were not functioning correctly due to the subgraph, and also received feedback that the model placement was unclear. Therefore, we decided to revert to the v2 specification.v2.3 - Layout has been adjusted.v2.2 - The Seed node has been changed from "CR Seed" to "Seed (rgthree)". We've received reports of issues with the CR Seed implementation, so we've made it consistent with the custom node commonly used for this workflow.v2.1 - The GGUF model loader is now available as standard. The input method for the model area has also been changed, allowing bulk input using sub-graph nodes.The number of frames per second was previously fixed at 16 fps, but can now be changed arbitrarily. Accordingly, the RIFE-VFI node multiple can now be changed in the input area.v2.0 - The issue where the second section would not generate has been fixed.

Files with SHA256: 82ea7dd6fc52c735cde1be1d5f3fadf37837377b0bc6fb70492f1d77fa6f391f