Feat: Add transition_video functionality for infinite video relay (Ref: PR #1946)

[FX-FeiHou]

Description

This PR introduces the transition_video functionality to the WanVideo wrapper. This feature is a critical component for advanced long-video workflows, such as infinite video relay.

I noticed that @wuwukaka previously submitted a similar PR (#1946) which hasn't been merged yet. My friend and I have been using their modified version to develop a node system that enables infinite video relay generation through simple settings.

Since this functionality is vital for seamless stitching in relay-style workflows, I've integrated the logic from wuwukaka's fork into the current nodes.py and nodes_sampler.py. I am resubmitting this to help bring this highly requested feature to the main repository for the benefit of the entire community.

Key Features

• Seamless Transitions: Enables the logic required to "hand off" the end of one clip to the start of the next.
• Infinite Relay Support: Extensively tested in our project to ensure stability for long-form video generation.

I have attached a demonstration video below to showcase the seamless final result achieved with this implementation.

default.mp4

Acknowledgements

• Huge thanks to @wuwukaka for the original implementation and the previous PR effort.
• Thank you, Kijai, for your amazing work in maintaining these nodes! I hope this integration makes it easier for you to review and merge this feature.

https://youtube.com/shorts/yB4RMItJ1RM

[DeucalionJ]

Hi, bro. I've reviewed the code you modified. Based on your work, I've moved it to the WAN image video encode module and it's still under testing. If it works out, I'd like to hand over the final touches to you. Is that okay?

TEST-preview，PURE I2V workflow

SE_X265.DEU_ItVx3.P1+2._v1.5.2__00039.mp4

[wuwukaka]

Hi, bro. I've reviewed the code you modified. Based on your work, I've moved it to the WAN image video encode module and it's still under testing. If it works out, I'd like to hand over the final touches to you. Is that okay?

TEST-preview，PURE I2V workflow

SE_X265.DEU_ItVx3.P1+2._v1.5.2__00039.mp4

I'd be glad to help with the final touches. Just a heads-up — my schedule's been quite tight lately, so it might take me another 2–3 weeks before I can start on this part. Would that timeline work for you?

[DeucalionJ]

Hi, bro. I've reviewed the code you modified. Based on your work, I've moved it to the WAN image video encode module and it's still under testing. If it works out, I'd like to hand over the final touches to you. Is that okay?
TEST-preview，PURE I2V workflow
SE_X265.DEU_ItVx3.P1+2._v1.5.2__00039.mp4

I'd be glad to help with the final touches. Just a heads-up — my schedule's been quite tight lately, so it might take me another 2–3 weeks before I can start on this part. Would that timeline work for you?

Thank you for your reply! Sure, bro. I'm not in a hurry. I'll just reply with the code to you later (I don't know how to send files to you on GitHub). Currently, the operation is not very stable. In fast I2V scenarios, it doesn't work well with slightly higher cfg values, especially for activities like running.

Then, if there is even a little intensity in the 0123 channels of the latent transferred from image_embed, the image will break down. But if the 0123 channels are fully masked, it's as if there were no reference image, and the image degradation will be more obvious. I still don't know how to handle it. I've tried many methods, but none of them seem reasonable.

My own coding skills are very poor, and the code was completed with the help of AI, so it will be very unstandardized. However, the main framework of the entire code, as well as the two files node.py and nodes_simplers.py, were basically written following your logic.

Besides, I'm not sure what unexpected impacts it might have on other interfaces. Also, my English is very poor. I have to rely on a translator to reply. Please excuse me if there's anything inappropriate.

If you want to see the current code, I can also send it to you. But in any case, there will be some strange and odd problems.
The current test video is roughly like this：

DEU_ItVx3.P1+2._v1.5.2__00050.mp4

Sometimes, slow-motion situations may occur. At such times, the model will automatically reduce the playback speed (while the control framework (CFG) remains unchanged).

DEU_ItVx3.P1+2._v1.5.2__00046.mp4

[FX-FeiHou]

哥们，你打中文就可以了。。。。

[DeucalionJ]

哥们，你打中文就可以了。。。。

哈哈，那就好说了~
还差一点点，总之就是参考图的问题， 太容易劣化了，慢速情况下效果真的看不出来，其实跑步的问题解决差不多了，总之代码写的稀里哗啦的，和pose姿态控制完全不一样。我镜像了32帧，前32帧不再是复制了，不镜像它会往前“冲”或者“倒着跑”，然后去掉了images序列，改用batch效果好了，我问了AI他说是VAE的模型如果传入batch组会自己根据对应的训练时的时间找合理性，传序列就完全崩掉不能用。
后面传进去sample之后那个mask覆盖是大问题，会极大影响自然推理，问AI说的意思要根据latent当前的数值权重做覆盖，总之，要么“跳”一下，要么数值溢出崩掉，就是各种情况，只要画面慢一点，现在就OK，我再搞搞把

[wuwukaka]

Hi, bro. I've reviewed the code you modified. Based on your work, I've moved it to the WAN image video encode module and it's still under testing. If it works out, I'd like to hand over the final touches to you. Is that okay?
TEST-preview，PURE I2V workflow
SE_X265.DEU_ItVx3.P1+2._v1.5.2__00039.mp4

I'd be glad to help with the final touches. Just a heads-up — my schedule's been quite tight lately, so it might take me another 2–3 weeks before I can start on this part. Would that timeline work for you?

Thank you for your reply! Sure, bro. I'm not in a hurry. I'll just reply with the code to you later (I don't know how to send files to you on GitHub). Currently, the operation is not very stable. In fast I2V scenarios, it doesn't work well with slightly higher cfg values, especially for activities like running.

Then, if there is even a little intensity in the 0123 channels of the latent transferred from image_embed, the image will break down. But if the 0123 channels are fully masked, it's as if there were no reference image, and the image degradation will be more obvious. I still don't know how to handle it. I've tried many methods, but none of them seem reasonable.

My own coding skills are very poor, and the code was completed with the help of AI, so it will be very unstandardized. However, the main framework of the entire code, as well as the two files node.py and nodes_simplers.py, were basically written following your logic.

Besides, I'm not sure what unexpected impacts it might have on other interfaces. Also, my English is very poor. I have to rely on a translator to reply. Please excuse me if there's anything inappropriate.

If you want to see the current code, I can also send it to you. But in any case, there will be some strange and odd problems. The current test video is roughly like this：

DEU_ItVx3.P1+2._v1.5.2__00050.mp4
Sometimes, slow-motion situations may occur. At such times, the model will automatically reduce the playback speed (while the control framework (CFG) remains unchanged).

DEU_ItVx3.P1+2._v1.5.2__00046.mp4

原来你也是国人啊 w
劣化这个问题的话，最好的方案是直接传递未被解码的latant而不是对已经解码过的帧进行重编码。目前的代码主要是出于操作便利性的原因才将上一段视频的最后32帧进行重编码，并且由于transition video的主要使用场景是context模式，因此一次重复编解码产生的劣化是可以接受的。但是对于i2v来讲就不一样了，由于i2v不可能使用context模式，重编码造成的劣化会不对累加，最终造成画面崩坏（这一点在你的视频中也有体现，接续后的视频明显有色彩劣化），因此不能完全照搬目前wan animate的transition video 的逻辑。
至于你目前遇到的其他问题，由于没有看到你的代码，不清楚具体实现原理，我也不能妄下定论。
如果你想进一步和我交流，可以在bilibili私信我，id是wuwukasi。

[DeucalionJ]

Hi, bro. I've reviewed the code you modified. Based on your work, I've moved it to the WAN image video encode module and it's still under testing. If it works out, I'd like to hand over the final touches to you. Is that okay?
TEST-preview，PURE I2V workflow
SE_X265.DEU_ItVx3.P1+2._v1.5.2__00039.mp4

I'd be glad to help with the final touches. Just a heads-up — my schedule's been quite tight lately, so it might take me another 2–3 weeks before I can start on this part. Would that timeline work for you?

Thank you for your reply! Sure, bro. I'm not in a hurry. I'll just reply with the code to you later (I don't know how to send files to you on GitHub). Currently, the operation is not very stable. In fast I2V scenarios, it doesn't work well with slightly higher cfg values, especially for activities like running.
Then, if there is even a little intensity in the 0123 channels of the latent transferred from image_embed, the image will break down. But if the 0123 channels are fully masked, it's as if there were no reference image, and the image degradation will be more obvious. I still don't know how to handle it. I've tried many methods, but none of them seem reasonable.
My own coding skills are very poor, and the code was completed with the help of AI, so it will be very unstandardized. However, the main framework of the entire code, as well as the two files node.py and nodes_simplers.py, were basically written following your logic.
Besides, I'm not sure what unexpected impacts it might have on other interfaces. Also, my English is very poor. I have to rely on a translator to reply. Please excuse me if there's anything inappropriate.
If you want to see the current code, I can also send it to you. But in any case, there will be some strange and odd problems. The current test video is roughly like this：
DEU_ItVx3.P1+2._v1.5.2__00050.mp4
Sometimes, slow-motion situations may occur. At such times, the model will automatically reduce the playback speed (while the control framework (CFG) remains unchanged).
DEU_ItVx3.P1+2._v1.5.2__00046.mp4

    原来你也是国人啊 w
    劣化这个问题的话，最好的方案是直接传递未被解码的latant而不是对已经解码过的帧进行重编码。目前的代码主要是出于操作便利性的原因才将上一段视频的最后32帧进行重编码，并且由于transition video的主要使用场景是context模式，因此一次重复编解码产生的劣化是可以接受的。但是对于i2v来讲就不一样了，由于i2v不可能使用context模式，重编码造成的劣化会不对累加，最终造成画面崩坏（这一点在你的视频中也有体现，接续后的视频明显有色彩劣化），因此不能完全照搬目前wan animate的transition video 的逻辑。
    至于你目前遇到的其他问题，由于没有看到你的代码，不清楚具体实现原理，我也不能妄下定论。
    如果你想进一步和我交流，可以在bilibili私信我，id是wuwukasi。

哈哈！原来如此都是国人哈哈，直接传latent我想了想应该这样更合理，我试了好几次，那个latent好像还带着sigma的数据、我之前一直想用连线法实现真转移，后来发现必须上一段的sigma状态和下一段的sigma状态严格对齐，才能正常输出，要不这两段的噪声阶段不一致就不符合它的什么降噪的公式还是曲线，画面就会崩，我现在强制开启了保真的VAE FP32（我把node.py加载vae的部分也给动了）好像也不行，不行的原因是因为遮罩噪点那个部分实际相当于渐变了，数据就变少了还是什么的，就是我上传视频中间闪了一下那个地方。那个就是交界处

[wuwukaka]

Hi, bro. I've reviewed the code you modified. Based on your work, I've moved it to the WAN image video encode module and it's still under testing. If it works out, I'd like to hand over the final touches to you. Is that okay?
TEST-preview，PURE I2V workflow
SE_X265.DEU_ItVx3.P1+2._v1.5.2__00039.mp4

I'd be glad to help with the final touches. Just a heads-up — my schedule's been quite tight lately, so it might take me another 2–3 weeks before I can start on this part. Would that timeline work for you?

Thank you for your reply! Sure, bro. I'm not in a hurry. I'll just reply with the code to you later (I don't know how to send files to you on GitHub). Currently, the operation is not very stable. In fast I2V scenarios, it doesn't work well with slightly higher cfg values, especially for activities like running.
Then, if there is even a little intensity in the 0123 channels of the latent transferred from image_embed, the image will break down. But if the 0123 channels are fully masked, it's as if there were no reference image, and the image degradation will be more obvious. I still don't know how to handle it. I've tried many methods, but none of them seem reasonable.
My own coding skills are very poor, and the code was completed with the help of AI, so it will be very unstandardized. However, the main framework of the entire code, as well as the two files node.py and nodes_simplers.py, were basically written following your logic.
Besides, I'm not sure what unexpected impacts it might have on other interfaces. Also, my English is very poor. I have to rely on a translator to reply. Please excuse me if there's anything inappropriate.
If you want to see the current code, I can also send it to you. But in any case, there will be some strange and odd problems. The current test video is roughly like this：
DEU_ItVx3.P1+2._v1.5.2__00050.mp4
Sometimes, slow-motion situations may occur. At such times, the model will automatically reduce the playback speed (while the control framework (CFG) remains unchanged).
DEU_ItVx3.P1+2._v1.5.2__00046.mp4

    原来你也是国人啊 w
    劣化这个问题的话，最好的方案是直接传递未被解码的latant而不是对已经解码过的帧进行重编码。目前的代码主要是出于操作便利性的原因才将上一段视频的最后32帧进行重编码，并且由于transition video的主要使用场景是context模式，因此一次重复编解码产生的劣化是可以接受的。但是对于i2v来讲就不一样了，由于i2v不可能使用context模式，重编码造成的劣化会不对累加，最终造成画面崩坏（这一点在你的视频中也有体现，接续后的视频明显有色彩劣化），因此不能完全照搬目前wan animate的transition video 的逻辑。
    至于你目前遇到的其他问题，由于没有看到你的代码，不清楚具体实现原理，我也不能妄下定论。
    如果你想进一步和我交流，可以在bilibili私信我，id是wuwukasi。

哈哈！原来如此都是国人哈哈，直接传latent我想了想应该这样更合理，我试了好几次，那个latent好像还带着sigma的数据、我之前一直想用连线法实现真转移，后来发现必须上一段的sigma状态和下一段的sigma状态严格对齐，才能正常输出，要不这两段的噪声阶段不一致就不符合它的什么降噪的公式还是曲线，画面就会崩，我现在强制开启了保真的VAE FP32（我把node.py加载vae的部分也给动了）好像也不行，不行的原因是因为遮罩噪点那个部分实际相当于渐变了，数据就变少了还是什么的，就是我上传视频中间闪了一下那个地方。那个就是交界处

也许可以参考wan aniamate自带的loop的逻辑，不过这样的话，到后期还是会有劣化。到时候具体的再看吧，我最近比较忙，可能得等1个月左右才会有空，我也不太确定能不能找到能真正延长视频的方案，你先琢磨一下看看。

[DeucalionJ]

现在的进度感觉预览版应该是可以拿出来了，在慢速场景，粒子少的场景兼容性已经大幅度提升
The current progress suggests that the preview version should be ready. The compatibility in slow-motion scenes and scenes with fewer particles has been significantly improved.

哦对了，目测VRAM占用率会提升，独立编码的VAE貌似一直在VRAM中，有可能blockswap没生效，
Oh, by the way, it seems that the VRAM usage rate will increase. The independently encoded VAE seems to always be in VRAM, and it's possible that blockswap didn't take effect.

我下面展示的测试结果全部基于I2V生成，只有一张初始参考图做引导
The test results I am presenting below are all generated by I2V, and only one initial reference image serves as a guide.

有一定随机性，有点像训练lora的感觉~ 有点时候捕获的很好，有时候会理解错
It has a certain degree of randomness, somewhat like training Lora. Sometimes it captures very well, and sometimes it misunderstands.

我感觉写成一个独立节点应该会更好一点，放出一堆参数然去试验摸索
I think it would be better to write it as an independent node. Just throw out a bunch of parameters and then experiment and explore.

劣化一定存在，我有点明白是怎么回事了，本来写这个代码我目标是规避SVI 2.0和VACE模型带来的色偏，它们的色偏我用很强的多级校正也去不掉，现在弄来弄去搞的色差其实也差不多少了。
Degradation is inevitable. I'm starting to understand what's going on. My original goal in writing this code was to avoid the color cast brought by the SVI 2.0 and VACE models. Even with very strong multi-level correction, I couldn't get rid of their color cast. Now, after all the adjustments, the color difference is actually not much different.

劣化和色差的根本原因是传入的图像不符合模型的正态分布，说白了模型里没有找到你这个画面，也没有你传入画面的动态趋势，因此模型纠偏的前几步会有较大的比对峰值，
The fundamental causes of degradation and color difference are that the input image does not conform to the normal distribution of the model. In simple terms, the model does not recognize your specific image, nor does it capture the dynamic trend of the image you input. Therefore, in the first few steps of the model's correction process, there will be significant comparison peaks.

DEU_ItVx3.P1+2._v1.5.2__00081.mp4

上面这个视频就是当动态幅度很大时就会触发溢出，但模型自动强制纠正后有时候会恢复正常（没有任何调色）
The above video shows that when the dynamic range is very large, an overflow will occur. However, after the model automatically corrects it, sometimes it can return to normal (without any color adjustment).

DEU_ItVx3.P1+2.Origin._v1.5.2__00009.mp4

这个视频可以看出动态幅度很极端的场景，模型会延迟掌握动态频率（没有任何调色）
This video shows scenes with extremely extreme dynamic ranges. The model will delay in grasping the dynamic frequency (without any color adjustment)

在归一化之后，我引入了Tanh双曲正切曲线，通过前后控制不同的gamma值勉勉强强才让模型识别画面，接收画面，让画面继续自然生长。
The fundamental cause of degradation and color difference is that the input image does not conform to the normal distribution of the model. In plain terms, the model does not find your image and does not have the dynamic trend of the image you input. Therefore, the first few steps of model correction will have a relatively large comparison peak. After normalization, I introduced the Tanh hyperbolic tangent curve and managed to make the model recognize and accept the image by controlling different gamma values before and after, allowing it to continue to grow naturally.

在自然推理的过程数据因为噪点的存在，数据肯定会和原图不一样（因为mask的缘故），所以损耗肯定有，虽然有参考图的存在，
In the process of natural reasoning, due to the presence of noise, the data will definitely be different from the original image (because of the mask), so there will definitely be some loss, although there is a reference image.

而如果将限制的太死，模型为了符合要求，画面就会不动，这里是一个矛盾点
而如果放的太宽，模型就不会管参考帧的画面，但会出现一些意想不到的效果~（像突然被电了一下~）
本质上是一个数据在噪点中如何保持一致的问题
If the restrictions are too strict, the model will remain static to meet the requirements, which is a contradiction. If the restrictions are too loose, the model will ignore the reference frame's images, but some unexpected effects will occur (like being suddenly electrocuted). Essentially, it is a problem of how to maintain consistency of data in the noise.

DEU_ItVx3.P123GV._v1.5.2__00070.mp4

上面这个视频就是限制较大的情况（没有任何调色）
The video above shows a situation with relatively strict restrictions.No color adjustment.

DEU_ItVx3.P1+2+3.Origin_cut._v1.5.2__00028.mp4

上面这个视频就是丢失了背景运动信息，当背景运动幅度小，接近低频通道时，就可能丢失数据（没有任何调色）
The above video has lost the information of background motion. When the amplitude of the background movement is small and approaches the low-frequency range, data may be lost.

DEU_ItVx3.P1+2._v1.5.2__00076.mp4

上面这个视频采用了8尾帧融合，当帧融合区变多时，数据峰值波动剧烈，模型有时候会对T轴误判播放速度，会发现融合的过程中速度信息不准确
The above video uses 8-frame fusion.When the number of frame fusion areas increases, the data peak fluctuates greatly, and the model sometimes misjudges the playback speed along the T-axis. It can be observed that during the fusion process, the speed information is inaccurate.

DEU_ItVx3.P1+2._v1.5.2__00077.mp4

上面这个视频仅用了4尾帧融合，效果意外的发现还很好，因为峰值波动的范围变小，数值更稳定
The video above used 4-frame fusion. Surprisingly, the effect turned out to be quite good. This is because the range of peak fluctuations became smaller, and the values became more stable.

现在的设计上是支持最多32尾帧，但经过多次测试反而只给3尾帧或2尾帧效果反而好，
The current design supports up to 32 tail frames, but after multiple tests, it was found that only 3 or 2 tail frames actually produced better results.

原因是当尾帧传入更多时模型会找不到合理性会出现数值溢出的标志性黄紫色闪屏，
现在“紫色、红色闪屏”可以在推理的过程中勉强指纠正，
“黄色闪屏”数值溢出越多，丢失、劣化的也就越严重，
The reason is that when more tail frames are input, the model will fail to find rationality and display a characteristic yellowish-purple flashing screen due to numerical overflow. Currently, "purple and red flashing screens" can be corrected to some extent during the inference process, but the more severe the numerical overflow is, the more serious the loss and degradation will be for "yellow flashing screens".

在较为缓慢的行走、静态场景、动态传递的比较好，可以使用更多的参考帧，不会算错，甚至也不闪屏，但动态幅度越剧烈、画面前后差别越大，闪屏越明显，劣化也就越严重，
It performs well in relatively slow walking, static scenes, and dynamic transmission, allowing for the use of more reference frames without miscalculation or screen flickering. However, the more intense the dynamic movement and the greater the difference between consecutive frames, the more obvious the screen flickering becomes, and the more severe the degradation.

结果上有一定随机性，不能保证稳定生成，识别到慢动作的问题依然存在，尤其是参考帧在2、1时。
There is a certain degree of randomness in the results, and stable generation cannot be guaranteed. The problem of slow-motion recognition still exists, especially when the reference frames are 2 and 1.

特别注意，我测试了 ”星空“这种场景，基本上不行，因为通道的缘故，它贴近416通道的低频区，应该是会有和04通道的交叉部分，数据基本丢失，
I tested the "starry sky" scene in particular, and it basically didn't work. Due to the channel issue, it is close to the low-frequency range of channels 4 to 16. There should be an overlapping part with channels 0 to 4, and the data is basically lost.

平台Platform：comfyui 0.17.2，pytorch 2.10.0，trition3.6.0.post26，sageattention2.2.post4，CUDA 13.0
wanvideowrapper 1.4.7

基本参数 400×720×69 frame，shift 5.25 / 5.22 / 5.19 (SLG: 2)
5 + 5 steps，unipc，
models:
wan2.2-I2V-A14B-HIGH / LOW_fp8_e4m3fn_scaled
wan2.2_PusaV1_lora_HIGH_resized_dynamic_avg_rank_98_bf16
wan2.1_PusaV1_LoRA_14B_rank512_bf16
lightx2v_T2V_14B_cfg_step+distill_v2_lora_rank256_bf16

TextEncode:女孩往镜头方向健身慢跑，女孩眼睛看着镜头，女孩前进，镜头后退并且保持和女孩的距离，

一定注意我当前的测试是在真VAE FP32、clipvision也是真FP32模式下测到的，原版node.py中的VAE和clip加载实际是bf16，如果在默认状态下，效果估计会更差
Please note that my current test was conducted under the true VAE FP32 and clipvision in the true FP32 mode. In the original node.py, the VAE and clip loading are actually in BF16 format. If in the default state, the result is likely to be even worse.

当前代码版本我自己乱编的v0.4.2，就当是一种潜空间转移的思路吧，如果能稳定住降噪峰值，感觉至少稳定在16帧效果应该能很不错
The current code version was randomly created by me as v0.4.2. Let's just consider it as an idea for latent space transfer. If the noise reduction peak can be stabilized, I think the effect should be quite good at least when it reaches 16 frames.

nodes_sampler_v0.4.2.py

nodes_v0.4.2.py

连接方法非常简单，我名字都没改⌯>𖥦<⌯，如图所示：

[DeucalionJ]

DEU_ItVx3.P1+2+3.Origin._v1.5.2__00033.mp4

正好出了一个标志性的结果，1 / 2 段的视频雪花粒传递了过去，到 2 / 3段 就没捕捉到，而且这个视频刚好将劣化显示了出来
我估计我这水平是搞不定了【捂脸】

[wuwukaka]

现在的进度感觉预览版应该是可以拿出来了，在慢速场景，粒子少的场景兼容性已经大幅度提升 The current progress suggests that the preview version should be ready. The compatibility in slow-motion scenes and scenes with fewer particles has been significantly improved.

哦对了，目测VRAM占用率会提升，独立编码的VAE貌似一直在VRAM中，有可能blockswap没生效， Oh, by the way, it seems that the VRAM usage rate will increase. The independently encoded VAE seems to always be in VRAM, and it's possible that blockswap didn't take effect.

我下面展示的测试结果全部基于I2V生成，只有一张初始参考图做引导 The test results I am presenting below are all generated by I2V, and only one initial reference image serves as a guide.

有一定随机性，有点像训练lora的感觉~ 有点时候捕获的很好，有时候会理解错 It has a certain degree of randomness, somewhat like training Lora. Sometimes it captures very well, and sometimes it misunderstands.

我感觉写成一个独立节点应该会更好一点，放出一堆参数然去试验摸索 I think it would be better to write it as an independent node. Just throw out a bunch of parameters and then experiment and explore.

劣化一定存在，我有点明白是怎么回事了，本来写这个代码我目标是规避SVI 2.0和VACE模型带来的色偏，它们的色偏我用很强的多级校正也去不掉，现在弄来弄去搞的色差其实也差不多少了。 Degradation is inevitable. I'm starting to understand what's going on. My original goal in writing this code was to avoid the color cast brought by the SVI 2.0 and VACE models. Even with very strong multi-level correction, I couldn't get rid of their color cast. Now, after all the adjustments, the color difference is actually not much different.

劣化和色差的根本原因是传入的图像不符合模型的正态分布，说白了模型里没有找到你这个画面，也没有你传入画面的动态趋势，因此模型纠偏的前几步会有较大的比对峰值， The fundamental causes of degradation and color difference are that the input image does not conform to the normal distribution of the model. In simple terms, the model does not recognize your specific image, nor does it capture the dynamic trend of the image you input. Therefore, in the first few steps of the model's correction process, there will be significant comparison peaks.

DEU_ItVx3.P1+2._v1.5.2__00081.mp4
上面这个视频就是当动态幅度很大时就会触发溢出，但模型自动强制纠正后有时候会恢复正常（没有任何调色） The above video shows that when the dynamic range is very large, an overflow will occur. However, after the model automatically corrects it, sometimes it can return to normal (without any color adjustment).

DEU_ItVx3.P1+2.Origin._v1.5.2__00009.mp4
这个视频可以看出动态幅度很极端的场景，模型会延迟掌握动态频率（没有任何调色） This video shows scenes with extremely extreme dynamic ranges. The model will delay in grasping the dynamic frequency (without any color adjustment)

在归一化之后，我引入了Tanh双曲正切曲线，通过前后控制不同的gamma值勉勉强强才让模型识别画面，接收画面，让画面继续自然生长。 The fundamental cause of degradation and color difference is that the input image does not conform to the normal distribution of the model. In plain terms, the model does not find your image and does not have the dynamic trend of the image you input. Therefore, the first few steps of model correction will have a relatively large comparison peak. After normalization, I introduced the Tanh hyperbolic tangent curve and managed to make the model recognize and accept the image by controlling different gamma values before and after, allowing it to continue to grow naturally.

在自然推理的过程数据因为噪点的存在，数据肯定会和原图不一样（因为mask的缘故），所以损耗肯定有，虽然有参考图的存在， In the process of natural reasoning, due to the presence of noise, the data will definitely be different from the original image (because of the mask), so there will definitely be some loss, although there is a reference image.

而如果将限制的太死，模型为了符合要求，画面就会不动，这里是一个矛盾点 而如果放的太宽，模型就不会管参考帧的画面，但会出现一些意想不到的效果~（像突然被电了一下~） 本质上是一个数据在噪点中如何保持一致的问题 If the restrictions are too strict, the model will remain static to meet the requirements, which is a contradiction. If the restrictions are too loose, the model will ignore the reference frame's images, but some unexpected effects will occur (like being suddenly electrocuted). Essentially, it is a problem of how to maintain consistency of data in the noise.

DEU_ItVx3.P123GV._v1.5.2__00070.mp4
上面这个视频就是限制较大的情况（没有任何调色） The video above shows a situation with relatively strict restrictions.No color adjustment.

DEU_ItVx3.P1+2+3.Origin_cut._v1.5.2__00028.mp4
上面这个视频就是丢失了背景运动信息，当背景运动幅度小，接近低频通道时，就可能丢失数据（没有任何调色） The above video has lost the information of background motion. When the amplitude of the background movement is small and approaches the low-frequency range, data may be lost.

DEU_ItVx3.P1+2._v1.5.2__00076.mp4
上面这个视频采用了8尾帧融合，当帧融合区变多时，数据峰值波动剧烈，模型有时候会对T轴误判播放速度，会发现融合的过程中速度信息不准确 The above video uses 8-frame fusion.When the number of frame fusion areas increases, the data peak fluctuates greatly, and the model sometimes misjudges the playback speed along the T-axis. It can be observed that during the fusion process, the speed information is inaccurate.

DEU_ItVx3.P1+2._v1.5.2__00077.mp4
上面这个视频仅用了4尾帧融合，效果意外的发现还很好，因为峰值波动的范围变小，数值更稳定 The video above used 4-frame fusion. Surprisingly, the effect turned out to be quite good. This is because the range of peak fluctuations became smaller, and the values became more stable.

现在的设计上是支持最多32尾帧，但经过多次测试反而只给3尾帧或2尾帧效果反而好， The current design supports up to 32 tail frames, but after multiple tests, it was found that only 3 or 2 tail frames actually produced better results.

原因是当尾帧传入更多时模型会找不到合理性会出现数值溢出的标志性黄紫色闪屏， 现在“紫色、红色闪屏”可以在推理的过程中勉强指纠正， “黄色闪屏”数值溢出越多，丢失、劣化的也就越严重， The reason is that when more tail frames are input, the model will fail to find rationality and display a characteristic yellowish-purple flashing screen due to numerical overflow. Currently, "purple and red flashing screens" can be corrected to some extent during the inference process, but the more severe the numerical overflow is, the more serious the loss and degradation will be for "yellow flashing screens".

在较为缓慢的行走、静态场景、动态传递的比较好，可以使用更多的参考帧，不会算错，甚至也不闪屏，但动态幅度越剧烈、画面前后差别越大，闪屏越明显，劣化也就越严重， It performs well in relatively slow walking, static scenes, and dynamic transmission, allowing for the use of more reference frames without miscalculation or screen flickering. However, the more intense the dynamic movement and the greater the difference between consecutive frames, the more obvious the screen flickering becomes, and the more severe the degradation.

结果上有一定随机性，不能保证稳定生成，识别到慢动作的问题依然存在，尤其是参考帧在2、1时。 There is a certain degree of randomness in the results, and stable generation cannot be guaranteed. The problem of slow-motion recognition still exists, especially when the reference frames are 2 and 1.

特别注意，我测试了 ”星空“这种场景，基本上不行，因为通道的缘故，它贴近416通道的低频区，应该是会有和04通道的交叉部分，数据基本丢失， I tested the "starry sky" scene in particular, and it basically didn't work. Due to the channel issue, it is close to the low-frequency range of channels 4 to 16. There should be an overlapping part with channels 0 to 4, and the data is basically lost.

平台Platform：comfyui 0.17.2，pytorch 2.10.0，trition3.6.0.post26，sageattention2.2.post4，CUDA 13.0 wanvideowrapper 1.4.7

基本参数 400×720×69 frame，shift 5.25 / 5.22 / 5.19 (SLG: 2) 5 + 5 steps，unipc， models: wan2.2-I2V-A14B-HIGH / LOW_fp8_e4m3fn_scaled wan2.2_PusaV1_lora_HIGH_resized_dynamic_avg_rank_98_bf16 wan2.1_PusaV1_LoRA_14B_rank512_bf16 lightx2v_T2V_14B_cfg_step+distill_v2_lora_rank256_bf16

TextEncode:女孩往镜头方向健身慢跑，女孩眼睛看着镜头，女孩前进，镜头后退并且保持和女孩的距离，

一定注意我当前的测试是在真VAE FP32、clipvision也是真FP32模式下测到的，原版node.py中的VAE和clip加载实际是bf16，如果在默认状态下，效果估计会更差 Please note that my current test was conducted under the true VAE FP32 and clipvision in the true FP32 mode. In the original node.py, the VAE and clip loading are actually in BF16 format. If in the default state, the result is likely to be even worse.

当前代码版本我自己乱编的v0.4.2，就当是一种潜空间转移的思路吧，如果能稳定住降噪峰值，感觉至少稳定在16帧效果应该能很不错 The current code version was randomly created by me as v0.4.2. Let's just consider it as an idea for latent space transfer. If the noise reduction peak can be stabilized, I think the effect should be quite good at least when it reaches 16 frames.

nodes_sampler_v0.4.2.py

nodes_v0.4.2.py

连接方法非常简单，我名字都没改⌯>𖥦<⌯，如图所示：

如果是噪声的问题，感觉应该是比较难彻底解决了，后面如果有时间我就看看。或许得换其他思路才能找到解决方案（或许也可能根本没有解决方案），尝试一下总是没坏处的。

[DeucalionJ]

现在的进度感觉预览版应该是可以拿出来了，在慢速场景，粒子少的场景兼容性已经大幅度提升 The current progress suggests that the preview version should be ready. The compatibility in slow-motion scenes and scenes with fewer particles has been significantly improved.
哦对了，目测VRAM占用率会提升，独立编码的VAE貌似一直在VRAM中，有可能blockswap没生效， Oh, by the way, it seems that the VRAM usage rate will increase. The independently encoded VAE seems to always be in VRAM, and it's possible that blockswap didn't take effect.
我下面展示的测试结果全部基于I2V生成，只有一张初始参考图做引导 The test results I am presenting below are all generated by I2V, and only one initial reference image serves as a guide.
有一定随机性，有点像训练lora的感觉~ 有点时候捕获的很好，有时候会理解错 It has a certain degree of randomness, somewhat like training Lora. Sometimes it captures very well, and sometimes it misunderstands.
我感觉写成一个独立节点应该会更好一点，放出一堆参数然去试验摸索 I think it would be better to write it as an independent node. Just throw out a bunch of parameters and then experiment and explore.
劣化一定存在，我有点明白是怎么回事了，本来写这个代码我目标是规避SVI 2.0和VACE模型带来的色偏，它们的色偏我用很强的多级校正也去不掉，现在弄来弄去搞的色差其实也差不多少了。 Degradation is inevitable. I'm starting to understand what's going on. My original goal in writing this code was to avoid the color cast brought by the SVI 2.0 and VACE models. Even with very strong multi-level correction, I couldn't get rid of their color cast. Now, after all the adjustments, the color difference is actually not much different.
劣化和色差的根本原因是传入的图像不符合模型的正态分布，说白了模型里没有找到你这个画面，也没有你传入画面的动态趋势，因此模型纠偏的前几步会有较大的比对峰值， The fundamental causes of degradation and color difference are that the input image does not conform to the normal distribution of the model. In simple terms, the model does not recognize your specific image, nor does it capture the dynamic trend of the image you input. Therefore, in the first few steps of the model's correction process, there will be significant comparison peaks.
DEU_ItVx3.P1+2._v1.5.2__00081.mp4
上面这个视频就是当动态幅度很大时就会触发溢出，但模型自动强制纠正后有时候会恢复正常（没有任何调色） The above video shows that when the dynamic range is very large, an overflow will occur. However, after the model automatically corrects it, sometimes it can return to normal (without any color adjustment).
DEU_ItVx3.P1+2.Origin._v1.5.2__00009.mp4
这个视频可以看出动态幅度很极端的场景，模型会延迟掌握动态频率（没有任何调色） This video shows scenes with extremely extreme dynamic ranges. The model will delay in grasping the dynamic frequency (without any color adjustment)
在归一化之后，我引入了Tanh双曲正切曲线，通过前后控制不同的gamma值勉勉强强才让模型识别画面，接收画面，让画面继续自然生长。 The fundamental cause of degradation and color difference is that the input image does not conform to the normal distribution of the model. In plain terms, the model does not find your image and does not have the dynamic trend of the image you input. Therefore, the first few steps of model correction will have a relatively large comparison peak. After normalization, I introduced the Tanh hyperbolic tangent curve and managed to make the model recognize and accept the image by controlling different gamma values before and after, allowing it to continue to grow naturally.
在自然推理的过程数据因为噪点的存在，数据肯定会和原图不一样（因为mask的缘故），所以损耗肯定有，虽然有参考图的存在， In the process of natural reasoning, due to the presence of noise, the data will definitely be different from the original image (because of the mask), so there will definitely be some loss, although there is a reference image.
而如果将限制的太死，模型为了符合要求，画面就会不动，这里是一个矛盾点 而如果放的太宽，模型就不会管参考帧的画面，但会出现一些意想不到的效果~（像突然被电了一下~） 本质上是一个数据在噪点中如何保持一致的问题 If the restrictions are too strict, the model will remain static to meet the requirements, which is a contradiction. If the restrictions are too loose, the model will ignore the reference frame's images, but some unexpected effects will occur (like being suddenly electrocuted). Essentially, it is a problem of how to maintain consistency of data in the noise.
DEU_ItVx3.P123GV._v1.5.2__00070.mp4
上面这个视频就是限制较大的情况（没有任何调色） The video above shows a situation with relatively strict restrictions.No color adjustment.
DEU_ItVx3.P1+2+3.Origin_cut._v1.5.2__00028.mp4
上面这个视频就是丢失了背景运动信息，当背景运动幅度小，接近低频通道时，就可能丢失数据（没有任何调色） The above video has lost the information of background motion. When the amplitude of the background movement is small and approaches the low-frequency range, data may be lost.
DEU_ItVx3.P1+2._v1.5.2__00076.mp4
上面这个视频采用了8尾帧融合，当帧融合区变多时，数据峰值波动剧烈，模型有时候会对T轴误判播放速度，会发现融合的过程中速度信息不准确 The above video uses 8-frame fusion.When the number of frame fusion areas increases, the data peak fluctuates greatly, and the model sometimes misjudges the playback speed along the T-axis. It can be observed that during the fusion process, the speed information is inaccurate.
DEU_ItVx3.P1+2._v1.5.2__00077.mp4
上面这个视频仅用了4尾帧融合，效果意外的发现还很好，因为峰值波动的范围变小，数值更稳定 The video above used 4-frame fusion. Surprisingly, the effect turned out to be quite good. This is because the range of peak fluctuations became smaller, and the values became more stable.
现在的设计上是支持最多32尾帧，但经过多次测试反而只给3尾帧或2尾帧效果反而好， The current design supports up to 32 tail frames, but after multiple tests, it was found that only 3 or 2 tail frames actually produced better results.
原因是当尾帧传入更多时模型会找不到合理性会出现数值溢出的标志性黄紫色闪屏， 现在“紫色、红色闪屏”可以在推理的过程中勉强指纠正， “黄色闪屏”数值溢出越多，丢失、劣化的也就越严重， The reason is that when more tail frames are input, the model will fail to find rationality and display a characteristic yellowish-purple flashing screen due to numerical overflow. Currently, "purple and red flashing screens" can be corrected to some extent during the inference process, but the more severe the numerical overflow is, the more serious the loss and degradation will be for "yellow flashing screens".
在较为缓慢的行走、静态场景、动态传递的比较好，可以使用更多的参考帧，不会算错，甚至也不闪屏，但动态幅度越剧烈、画面前后差别越大，闪屏越明显，劣化也就越严重， It performs well in relatively slow walking, static scenes, and dynamic transmission, allowing for the use of more reference frames without miscalculation or screen flickering. However, the more intense the dynamic movement and the greater the difference between consecutive frames, the more obvious the screen flickering becomes, and the more severe the degradation.
结果上有一定随机性，不能保证稳定生成，识别到慢动作的问题依然存在，尤其是参考帧在2、1时。 There is a certain degree of randomness in the results, and stable generation cannot be guaranteed. The problem of slow-motion recognition still exists, especially when the reference frames are 2 and 1.
特别注意，我测试了 ”星空“这种场景，基本上不行，因为通道的缘故，它贴近416通道的低频区，应该是会有和04通道的交叉部分，数据基本丢失， I tested the "starry sky" scene in particular, and it basically didn't work. Due to the channel issue, it is close to the low-frequency range of channels 4 to 16. There should be an overlapping part with channels 0 to 4, and the data is basically lost.
平台Platform：comfyui 0.17.2，pytorch 2.10.0，trition3.6.0.post26，sageattention2.2.post4，CUDA 13.0 wanvideowrapper 1.4.7
基本参数 400×720×69 frame，shift 5.25 / 5.22 / 5.19 (SLG: 2) 5 + 5 steps，unipc， models: wan2.2-I2V-A14B-HIGH / LOW_fp8_e4m3fn_scaled wan2.2_PusaV1_lora_HIGH_resized_dynamic_avg_rank_98_bf16 wan2.1_PusaV1_LoRA_14B_rank512_bf16 lightx2v_T2V_14B_cfg_step+distill_v2_lora_rank256_bf16
TextEncode:女孩往镜头方向健身慢跑，女孩眼睛看着镜头，女孩前进，镜头后退并且保持和女孩的距离，
一定注意我当前的测试是在真VAE FP32、clipvision也是真FP32模式下测到的，原版node.py中的VAE和clip加载实际是bf16，如果在默认状态下，效果估计会更差 Please note that my current test was conducted under the true VAE FP32 and clipvision in the true FP32 mode. In the original node.py, the VAE and clip loading are actually in BF16 format. If in the default state, the result is likely to be even worse.
当前代码版本我自己乱编的v0.4.2，就当是一种潜空间转移的思路吧，如果能稳定住降噪峰值，感觉至少稳定在16帧效果应该能很不错 The current code version was randomly created by me as v0.4.2. Let's just consider it as an idea for latent space transfer. If the noise reduction peak can be stabilized, I think the effect should be quite good at least when it reaches 16 frames.
nodes_sampler_v0.4.2.py
nodes_v0.4.2.py
连接方法非常简单，我名字都没改⌯>𖥦<⌯，如图所示：

如果是噪声的问题，感觉应该是比较难彻底解决了，后面如果有时间我就看看。或许得换其他思路才能找到解决方案（或许也可能根本没有解决方案），尝试一下总是没坏处的。

DEU_ItVx3.P123GNU._v1.5.2__00049.mp4

我感觉得换方向，这个视频较好的展示了当传入完整32帧时的采样过程。模型努力捕捉画面，但来不及降噪，融合区就已经结束了，然后剩余的噪声被带到了自然推理的后半段，再然后找不到合理性，数值崩溃，直接甩出来了陌生画面