{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreifvlfhrybwrfwbcbtgb5hgmomonv4qzswetavzbe2voa2kmp3hxee",
"uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3moewopi6x3j2"
},
"path": "/t/nvidia-driver-update-reactor-node/176221#post_13",
"publishedAt": "2026-06-16T02:38:09.000Z",
"site": "https://discuss.huggingface.co",
"tags": [
"Wan2GP issue #511 - Progressive Light Increase When Using “Continue Video”",
"Wan2GP issue #579 - Wan 2.1 i2v generated videos progressively increased brightness and end up seriously overexposed",
"Wan2.1 issue #369 - long videos have color shifts and flickering",
"Wan2.1 issue #73 - Image2Video hardcoded at 81 frames",
"ComfyUI-KJNodes ColorMatch",
"KJNodes source / ColorMatch implementation",
"ComfyUI Essentials ImageColorMatch+",
"ComfyUI-EasyColorCorrector",
"FFmpeg documentation",
"FFmpeg filters documentation",
"Using FFmpeg to apply LUT / color correction",
"ComfyUI-KJNodes issue #349 - Color Match issue with white frames",
"FramePack project page",
"FramePack paper",
"LearnOpenCV FramePack article",
"Rolling Forcing: Training-Free Long Video Generation"
],
"textContent": "Hmm, probably:\n\n* * *\n\nI think you have found a **second, separate problem** now.\n\nThe earlier rings / nails / bracelets issue was mostly:\n\n\n object / detail continuity drift\n\n\nThis new issue sounds more like:\n\n\n color / exposure / skin-tone drift\n\n\nThey are related because both are continuity problems, but they need slightly different fixes.\n\nYour description is very specific:\n\n\n frames 1 → 80:\n very slight gradual light increase\n\n after 4–5 chained clips:\n the small increase has accumulated\n the character looks much brighter / more tanned\n the scene no longer feels like the same scene\n\n\nThat sounds less like a bad prompt and more like **cumulative clip-chain drift**.\n\n## Direct answer\n\nI would not try to solve this only by increasing steps or tweaking the prompt.\n\nOn an 8GB GPU, I would first test a **pipeline fix** :\n\n\n shorter clip\n +\n do not pass the raw last frame forward\n +\n create a corrected \"clean continuity frame\"\n +\n color/exposure match that frame to a stable reference\n +\n use the corrected frame as the next clip's first frame\n\n\nIn other words, I would stop thinking of the last frame as automatically “safe.”\n\nI would treat the last frame as:\n\n\n a candidate frame that needs inspection and correction before it becomes the next first frame\n\n\n## Why this seems like a real Wan/I2V behavior\n\nThere are a few reports that look close to what you are seeing.\n\nWan2GP has a very similar issue report:\n\n * Wan2GP issue #511 - Progressive Light Increase When Using “Continue Video”\n\n\n\nThe description there is basically:\n\n\n every time the video is extended\n brightness/light increases\n the video becomes progressively more overexposed\n\n\nThat is extremely close to your “after 4 or 5 clips” observation.\n\nThere is also this one:\n\n * Wan2GP issue #579 - Wan 2.1 i2v generated videos progressively increased brightness and end up seriously overexposed\n\n\n\nThat report describes 5–6 second Wan2.1 I2V generations where brightness increases progressively toward the end of the video.\n\nWan2.1 itself also has a long-frame color-shift/flicker issue report:\n\n * Wan2.1 issue #369 - long videos have color shifts and flickering\n\n\n\nThat issue specifically mentions long generations such as 121 frames and says the problem appears when going beyond 81 frames.\n\nSo your 80-frame / 7-second setup is right near the area where I would be suspicious of frame-length instability.\n\nThere was also an older Wan2.1 I2V frame-count discussion:\n\n * Wan2.1 issue #73 - Image2Video hardcoded at 81 frames\n\n\n\nI would not over-interpret that as “81 is always the magic number,” because workflows and implementations differ. But it does suggest that Wan2.1 I2V has historically been very sensitive around that frame-count region.\n\n## The likely mechanism\n\nI would describe the mechanism like this:\n\n\n clip 1 starts from a good frame\n ↓\n within clip 1, exposure/skin tone drifts slightly brighter\n ↓\n clip 1 last frame is now a little brighter than the original\n ↓\n clip 2 uses that brighter frame as its new starting point\n ↓\n clip 2 drifts a little brighter again\n ↓\n repeat 4–5 times\n ↓\n the accumulated change becomes obvious\n\n\nSo the problem is not necessarily that any single clip is terrible.\n\nThe problem is that a very small change becomes the new baseline each time.\n\nThis is why it can be “hardly noticeable” in one 80-frame clip, but obvious after several clips.\n\n## Two different continuity problems\n\nI would separate the current issues like this:\n\nProblem | What changes | Likely cause | Best first response\n---|---|---|---\n**Object/detail drift** | rings, nails, bracelets, sleeves | model re-invents small details after motion/occlusion | shot design, clean keyframes, still inpaint\n**Color/exposure drift** | skin tone, brightness, contrast, warmth | small exposure/color shift accumulates through chained clips | shorter clips, color reset, reference matching\n**Identity drift** | face changes | weak identity constraint over time | better reference frames, face restore/swap, shorter clips\n**Motion drift** | pose/action becomes different | long generation / weak control | shorter clips, control workflows\n**Scene drift** | room/background changes | insufficient visual anchor | stronger first frames, fewer chained assumptions\n\nRight now, #12 is mostly the second one:\n\n\n color/exposure drift\n\n\n## This is not mainly a prompt problem\n\nYou can try adding phrases like:\n\n\n consistent lighting\n constant exposure\n same skin tone\n no exposure change\n no brightness shift\n same color grading\n\n\nbut I would not expect that to fully solve it.\n\nThe issue is happening inside the generated image sequence and then getting inherited by the next clip.\n\nA prompt can bias the model, but it cannot reliably enforce:\n\n\n frame 80 must have exactly the same exposure distribution as frame 1\n\n\nSo I would put prompt tweaks low on the priority list.\n\n## Why increasing steps may not be the best first fix\n\nYou said:\n\n\n 2-pass KSampler\n cfg = 1\n KS1 steps 0–2\n KS2 steps 2–4\n higher steps make a 7 sec clip too slow on 8GB GPU\n\n\nThat is important.\n\nOn an 8GB card, trying to fix this by simply raising steps may not be practical. It may help a little, or it may not, but it makes every experiment expensive.\n\nI would first test cheaper variables:\n\n\n frame count\n clip length\n raw last frame vs corrected first frame\n color match on continuity frame\n seed sensitivity\n reference-frame color matching\n\n\nThose tests may teach you more than just increasing steps.\n\n## First test: shorten the clip\n\nBecause there are Wan reports around color shift / flicker at longer frame counts, I would first test shorter clips.\n\nFor example:\n\nTest | Frames | Goal\n---|---|---\nA | 80 frames | current baseline\nB | 48 frames | test whether drift reduces\nC | 40 frames | stronger short-clip test\nD | 32 frames | extreme stability test\n\nKeep everything else as similar as possible:\n\n\n same source image\n same prompt style\n same sampler style\n same resolution\n same approximate scene\n\n\nThen compare:\n\n\n frame 1 vs final frame\n\n\nIf the brightness drift is much smaller at 40–48 frames, then the problem is probably strongly related to clip length / frame count.\n\nThat would be useful information.\n\n## Second test: do not chain raw last frames\n\nI would test this difference:\n\n\n Test A:\n clip A raw last frame → clip B first frame\n\n Test B:\n clip A last frame\n → color/exposure corrected against original reference\n → clip B first frame\n\n\nIf Test B reduces the “sun bed” effect, then the main fix is not prompt or steps.\n\nThe main fix is:\n\n\n color reset before chaining\n\n\n## Build a reference frame\n\nPick one frame as the color reference.\n\nUsually one of these:\n\n\n original input image\n clip 1 frame 1\n best-looking frame from clip 1\n a manually corrected still frame\n\n\nThis becomes your “visual truth” for:\n\n\n skin tone\n exposure\n contrast\n warmth\n color balance\n scene brightness\n\n\nThen every time you create a new continuity frame, compare it against that reference.\n\nThe mental model:\n\n\n reference frame = color anchor\n last frame = motion anchor\n corrected continuity frame = next first frame\n\n\n## Suggested chaining pipeline\n\nInstead of:\n\n\n generate clip 1\n ↓\n use raw last frame as clip 2 first frame\n ↓\n generate clip 2\n ↓\n use raw last frame as clip 3 first frame\n\n\ntry:\n\n\n generate clip 1\n ↓\n pick a good near-final frame\n ↓\n compare it to the reference frame\n ↓\n correct exposure/color/skin tone\n ↓\n save this as clean continuity frame 1\n ↓\n use clean continuity frame 1 as clip 2 first frame\n ↓\n generate clip 2\n ↓\n repeat\n\n\nThis turns clip chaining into a controlled pipeline instead of an automatic drift amplifier.\n\n## Practical “color reset” methods\n\nThere are several levels of correction.\n\nMethod | Where | Good for | Notes\n---|---|---|---\nManual correction | editor / image tool | one boundary frame | very controllable\nColorMatch | ComfyUI | matching one frame/image to reference | quick test\nHistogram match | ComfyUI | approximate color distribution match | can help with exposure/color drift\nLUT / grade | DaVinci / ffmpeg / editor | final clip consistency | good for final polish\nFull-frame batch correction | ComfyUI / editor | all frames in a clip | more work, but useful\nVideo inpainting | ComfyUI | local objects/details | not the first fix for exposure drift\n\nComfyUI-related nodes/resources worth looking at:\n\n * ComfyUI-KJNodes ColorMatch\n * KJNodes source / ColorMatch implementation\n * ComfyUI Essentials ImageColorMatch+\n * ComfyUI-EasyColorCorrector\n\n\n\nExternal tools:\n\n * FFmpeg documentation\n * FFmpeg filters documentation\n * Using FFmpeg to apply LUT / color correction\n * DaVinci Resolve or any normal video editor\n\n\n\nI would not assume a ComfyUI color-match node will be perfect. It may be enough for boundary frames, though.\n\n## Important caution about ColorMatch\n\nColor matching is useful, but it can also fail.\n\nThere is a KJNodes issue where Color Match caused problems when later frames were very white:\n\n * ComfyUI-KJNodes issue #349 - Color Match issue with white frames\n\n\n\nAlso, if the camera angle or content changes too much, a pure color-match operation can produce weird results.\n\nSo I would test gently:\n\n\n use 50% strength first if available\n test on one frame\n do not apply blindly to a whole long clip\n compare before/after\n\n\nFor boundary-frame chaining, I would start with:\n\n\n correct only the frame that becomes the next first frame\n\n\nnot:\n\n\n color-match every frame aggressively\n\n\n## Boundary frame correction vs full clip correction\n\nThere are two different uses of color correction.\n\n### 1. Boundary-frame correction\n\nGoal:\n\n\n prevent drift from being passed into the next generation\n\n\nThis is probably the most important for you.\n\nPipeline:\n\n\n clip A final frame\n ↓\n color match to reference\n ↓\n use corrected frame as clip B first frame\n\n\n### 2. Final clip grading\n\nGoal:\n\n\n make the finished clips look consistent after generation\n\n\nPipeline:\n\n\n all clips generated\n ↓\n bring into editor\n ↓\n match exposure/contrast/skin tone across clips\n ↓\n export final movie\n\n\nBoth are useful, but they solve different parts of the problem.\n\nBoundary correction prevents the next generation from inheriting the drift.\n\nFinal grading makes the already-generated clips look consistent.\n\n## What I would test first\n\nI would run a small matrix.\n\nTest | Change | What it tells you\n---|---|---\n1 | Current 80-frame generation | baseline\n2 | 48-frame generation | whether shorter clips reduce drift\n3 | 40-frame generation | stronger short-clip check\n4 | 80-frame generation, different seed | whether seed matters\n5 | 80-frame generation, same source but lower motion | whether motion drives drift\n6 | raw last-frame chaining | baseline chaining drift\n7 | color-corrected continuity-frame chaining | whether color reset helps\n8 | final editor grade only | whether post grade is enough\n\nThe highest-value test is probably:\n\n\n 80 frames vs 40–48 frames\n\n\nand then:\n\n\n raw last frame vs corrected continuity frame\n\n\n## Why 7 seconds may be too ambitious for stable chaining\n\nA 7-second clip may be fine if you only need one clip.\n\nBut if you plan to chain:\n\n\n clip 1\n clip 2\n clip 3\n clip 4\n clip 5\n\n\nthen each clip must not only look good by itself. It must also end in a good state for the next clip.\n\nThat is much harder.\n\nA 7-second clip with a tiny internal exposure drift may look acceptable alone, but it becomes a bad building block for chaining.\n\nSo for chained scenes, shorter clips can be more stable:\n\n\n 3–4 seconds\n or\n 40–48 frames\n\n\nThen use editing to assemble the scene.\n\nThis may feel slower creatively, but it gives you more control.\n\n## The “do not pass drift forward” rule\n\nThis is probably the key rule.\n\nDo not pass this forward:\n\n\n slightly brighter last frame\n\n\nPass this forward:\n\n\n motion-continuity frame corrected back to reference exposure/color\n\n\nOnce a frame becomes brighter and you use it as the next input, the model may treat the brighter skin/scene as the new normal.\n\nThat is the same idea as the earlier rings/nails issue:\n\n\n if a bad ring becomes part of the next first frame,\n the next clip may preserve or amplify the ring\n\n\nFor color:\n\n\n if a brighter skin tone becomes part of the next first frame,\n the next clip may preserve or amplify the brighter skin tone\n\n\n## Relationship to long-video research\n\nThis is not just a “you configured something wrong” issue.\n\nLong/chained video generation has a general problem called things like:\n\n\n drift\n error accumulation\n exposure bias\n temporal degradation\n memory bottleneck\n\n\nFramePack discusses this problem directly:\n\n * FramePack project page\n * FramePack paper\n * LearnOpenCV FramePack article\n\n\n\nAnother related long-video paper:\n\n * Rolling Forcing: Training-Free Long Video Generation\n\n\n\nI am not saying you should switch to those immediately. With 8GB VRAM, that may not be the practical next step.\n\nBut these links are useful because they show that the problem category is real:\n\n\n long video generation tends to accumulate errors over time\n\n\nYour case is a practical Wan I2V version of that.\n\n## What I would not do first\n\nI would not start with:\n\n\n raising steps a lot\n trying to fix it with \"no overexposure\" in the negative prompt\n building a giant new workflow\n installing several new video systems at once\n trying full video inpainting first\n\n\nThose may be useful later, but they are not the cheapest diagnostic tests.\n\nGiven your 8GB GPU, I would first test:\n\n\n shorter clips\n color reset between clips\n boundary-frame correction\n final grading\n\n\n## A possible safe workflow for your setup\n\nSomething like:\n\n\n 1. Pick one reference frame.\n Usually original image or clip 1 frame 1.\n\n 2. Generate clip 1, but test shorter length first.\n Try 40–48 frames.\n\n 3. Inspect frame 1 vs final frame.\n Look at exposure, skin tone, warmth, contrast.\n\n 4. Pick a near-final frame for continuity.\n Do not automatically use frame 80 if frame 80 is already drifting.\n\n 5. Color-correct that frame against the reference.\n Use ColorMatch / histogram match / manual editor correction.\n\n 6. Use the corrected frame as clip 2 first frame.\n\n 7. Repeat.\n\n 8. After all clips are generated, do final color grading across the finished clips.\n\n\nIf you must keep 80 frames, then I would be stricter about step 5.\n\n## Tiny diagnostic checklist\n\nFor each generated clip, check:\n\n\n frame 1\n frame 20\n frame 40\n frame 60\n frame 80\n\n\nAsk:\n\n\n Is the face brighter?\n Is the skin warmer?\n Is contrast lower?\n Are highlights clipping?\n Is the background changing?\n Is the whole frame brighter or only the character?\n\n\nIf the whole frame is drifting:\n\n\n global exposure/color drift\n\n\nIf only the face/skin is drifting:\n\n\n subject/skin-tone drift\n\n\nIf only highlights are growing:\n\n\n overexposure/highlight clipping\n\n\nDifferent drift types may need different correction.\n\n## Suggested language for your notes\n\nI would name the two current problems like this:\n\n\n Problem 1:\n object/detail continuity drift\n rings, nails, bracelets, sleeves\n\n Problem 2:\n cumulative color/exposure drift\n brightness, skin tone, contrast over chained clips\n\n\nThen your workflow goal becomes:\n\n\n Do not let either kind of drift become the next clip's starting condition.\n\n\n## My practical expectation\n\nI would expect the best improvement from:\n\n\n shorter clips\n +\n not using raw last frames\n +\n color-correcting continuity frames\n\n\nI would expect smaller or inconsistent improvement from:\n\n\n negative prompt\n slightly more steps\n minor diffusion tweaks\n\n\nAnd I would treat model/workflow changes as later experiments.\n\n## Short version\n\nYou are probably no longer just fighting prompt adherence.\n\nYou are now fighting **clip-chain drift**.\n\nEach clip slightly changes the visual state. If the next clip starts from that changed state, the change accumulates.\n\nFor your 8GB setup, the most practical first fix is probably:\n\n\n try 40–48 frames\n use a stable reference frame\n correct the boundary frame before chaining\n then do final color grading after all clips are assembled\n\n\nThat may not be a perfect in-model fix, but it is a realistic production-style workaround.",
"title": "Nvidia driver update - reactor node"
}