{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifkiki3pbame2s5nxmjeuukazu74yr6jqrdal56e2nqrjoark4e2i",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mohhawacdsf2"
  },
  "path": "/t/nvidia-driver-update-reactor-node/176221#post_15",
  "publishedAt": "2026-06-16T23:17:01.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "ComfyUI Wan2.1 FLF2V Native Example",
    "ComfyUI-WanVideoWrapper issue #1541 — Wan 2.2 I2V Looping same image Start-End step - Color contrast increase over time",
    "ComfyUI-WanVideoWrapper issue #1342 — First and Last Frame Pingponging Wan 2.2",
    "Reddit: PSA — WAN 2.2 does First Frame Last Frame out of the box",
    "RIFE paper",
    "RunComfy: WanFirstMiddleLastFrameToVideo",
    "Reddit: Wan 2.2 First Frame Middle Frame Last Frame FMLF middle-frame flash issue"
  ],
  "textContent": "Ah, so, then I think the fix changes too:\n\n* * *\n\nI think I misunderstood one important detail earlier.\n\nIf frame 1 and frame 80 are **literally the same image** , then this is probably **not mainly cumulative last-frame chaining drift**.\n\nIt sounds more like a **same-frame first/last-frame problem** :\n\n\n    frame 1  = reference image\n    frames 20-50 = model invents a transition path and exposure/color moves\n    frame 80 = the same reference image again\n\n\nSo the model is not simply drifting forward forever. It is doing something more like:\n\n\n    dark/reference\n    → unwanted brighter middle\n    → dark/reference again\n\n\nAnd when you use one of the lighter middle frames as both the first and last frame, it does the opposite:\n\n\n    light/reference\n    → unwanted darker middle\n    → light/reference again\n\n\nThat is a very useful observation, because it changes the diagnosis.\n\n## Direct answer\n\nI would stop treating identical first/last-frame FLF as the main tool for this specific goal.\n\nA simple rule:\n\n\n    FLF is good for “A becomes B.”\n    FLF is not always good for “A stays A.”\n\n\nYour goal seems closer to:\n\n\n    A\n    → small motion / facial micro-movement / slight acting\n    → A\n\n\nBut FLF may interpret identical first/last frames as:\n\n\n    A\n    → generate some kind of transition path anyway\n    → A\n\n\nThat generated middle path can show up as:\n\n\n    brightness hump\n    contrast shift\n    skin tone change\n    gray flicker\n    unwanted exposure movement\n    unwanted visual excursion\n\n\nSo yes, if frame 1 and frame 80 are exactly the same image, the fix changes.\n\n## Why identical first/last frames can be unstable\n\nWan FLF is not simply:\n\n\n    keep this image stable for 80 frames\n\n\nIt is more like:\n\n\n    given a starting frame and an ending frame,\n    generate the missing motion between them\n\n\nThe ComfyUI Wan FLF documentation describes FLF as using a start frame and an end frame, with the model filling in the intermediate dynamic change:\n\nComfyUI Wan2.1 FLF2V Native Example\n\nThat distinction matters.\n\nFLF is naturally a **transition tool** :\n\n\n    first image\n    → intermediate motion / transformation\n    → last image\n\n\nSo if you give it:\n\n\n    first image = A\n    last image  = A\n\n\nthe model may still try to create a meaningful middle. It may not understand that you want:\n\n\n    A, but almost static, with constant exposure and only tiny motion\n\n\nIt may instead produce:\n\n\n    A\n    → some invented motion/lighting/color path\n    → A\n\n\nYour light/dark/light experiment fits that explanation very well.\n\n## Similar reports / clues\n\nThere are a few reports that point in the same direction.\n\n### Same image as first/last causing loop/color problems\n\nThis issue is very relevant:\n\nComfyUI-WanVideoWrapper issue #1541 — Wan 2.2 I2V Looping same image Start-End step - Color contrast increase over time\n\nThat report involves using the same image as first/last for a loop and getting problems such as:\n\n\n    color / contrast increase\n    gray flicker\n    gray ending\n\n\nIt is not exactly the same workflow as yours, but it is close enough to be useful: identical first/last conditioning can create unwanted color/exposure behavior.\n\n### First/last frame ping-pong behavior\n\nAnother related issue:\n\nComfyUI-WanVideoWrapper issue #1342 — First and Last Frame Pingponging Wan 2.2\n\nThis is useful because it shows that FLF can behave less like “hold this image steady” and more like a temporal path that may move toward one endpoint and then back.\n\n### Practical comment: identical frames may be bad\n\nThere is also a practical Reddit discussion where users mention that identical first/last frames can give worse results, and that slightly changing the last frame may help:\n\nReddit: PSA — WAN 2.2 does First Frame Last Frame out of the box\n\nThe practical takeaway is:\n\n\n    Do not always use identical first/last frames.\n    If you use FLF, make the last frame slightly different.\n\n\nThat turns the task into:\n\n\n    A → A'\n\n\ninstead of:\n\n\n    A → A\n\n\nThe model may handle that more naturally.\n\n## Updated tool map\n\nI would map the tools like this.\n\nGoal | Better first tool | Why\n---|---|---\n**A clearly changes into B** | FLF | This is what first/last-frame generation is good at\n**A stays mostly A with slight motion** | short normal I2V | Less likely to create an artificial transition arc\n**A loops back to A** | normal I2V + editing loop | Often more stable than identical first/last FLF\n**A loops back to A using FLF anyway** | FLF with a slightly modified last frame | Avoids the exact duplicate endpoint problem\n**The middle of FLF changes too much** | shorter clip / middle anchor / FMLF | First+last alone may not constrain the middle\n**Color/brightness hump appears mid-clip** | avoid same-frame FLF first; then post-correct if needed | The hump may be part of the generated FLF path\n**8GB VRAM stability** | short clips and editing | More iterations, fewer heavy experiments\n\nThe main thing:\n\n\n    Use FLF when you want a transition.\n    Use normal I2V when you want a short living-still / micro-motion shot.\n    Use editing when you want a clean loop.\n\n\n## Broader map for your current project\n\nBased on the whole thread, I would separate the tasks like this:\n\nTask | Practical path on 8GB VRAM | Avoid as first step\n---|---|---\nReActor face swap | Keep it simple, test stills/short clips first | full complex video workflow immediately\nBasic Wan video | short normal I2V | long chained clips before stability testing\nAdd audio | TTS or recorded audio + mux | full speech-to-video model locally\nLip-sync | Wav2Lip / LatentSync as post-process | Wan2.2-S2V 14B on 8GB\nKeep hands/nails/jewelry stable | shot planning + clean keyframes + still inpaint | negative prompt only\nA→B visual change | FLF | normal I2V only\nA→tiny motion→A | short normal I2V | identical first/last FLF\nLoop-like result | generate a good short clip, then loop in editing | forcing exact duplicate FLF loop\nMore control over the middle | FMLF / middle anchor later | hoping first/last alone controls everything\nHeavy local video editing | test only after the simple path works | installing many new systems at once\n\nThis is why I would not put FLF in the “bad” category. It is not bad. It may just be the wrong tool for this exact task.\n\n## What I would test next\n\nI would run a small test matrix.\n\n### Test 1 — normal I2V, no FLF\n\n\n    Use the same source image.\n    Do not set the same image as both first and last.\n    Generate a short normal I2V clip.\n    Try 40–48 frames first.\n\n\nGoal:\n\n\n    Does the brightness hump still appear?\n\n\nIf the brightness hump mostly disappears, then same-frame FLF was probably the trigger.\n\n### Test 2 — FLF, but last frame slightly different\n\nInstead of:\n\n\n    first = A\n    last  = A\n\n\ntry:\n\n\n    first = A\n    last  = A'\n\n\nWhere `A'` is almost the same image, but with a tiny real change:\n\n\n    slightly different expression\n    slightly different head angle\n    slightly different hand position\n    slightly different eye direction\n    slightly different camera crop\n\n\nGoal:\n\n\n    Give the model a real A→A' path,\n    instead of forcing it to invent an A→A loop path.\n\n\n### Test 3 — shorter FLF\n\nTry the same setup at:\n\n\n    32 frames\n    40 frames\n    48 frames\n\n\ninstead of:\n\n\n    80 frames\n\n\nGoal:\n\n\n    Does the middle brightness hump shrink when the model has less time to invent an excursion?\n\n\n### Test 4 — loop in editing, not generation\n\nGenerate a normal short I2V clip that looks good.\n\nThen loop it afterward using editing techniques:\n\n\n    cut off bad ending frames\n    crossfade end to start\n    reverse a copy and ping-pong it\n    use interpolation between end/start\n\n\nFor interpolation, RIFE is one common frame interpolation family:\n\nRIFE paper\n\nThis is not necessarily “better AI generation,” but it may be a more stable production trick.\n\n## About FMLF / middle anchors\n\nIf first/last alone gives too much freedom to the middle, then a middle anchor is the logical next idea.\n\nThere are Wan first-middle-last / multi-keyframe workflows and nodes, for example:\n\nRunComfy: WanFirstMiddleLastFrameToVideo\n\nThe idea is:\n\n\n    first frame = A\n    middle frame = controlled middle state\n    last frame = A or A'\n\n\nThis can reduce the model’s freedom in the middle.\n\nBut I would treat FMLF as a later experiment, not the first fix, because:\n\n\n    more keyframes = more complexity\n    more nodes = more installation/debugging\n    8GB VRAM = test carefully\n    middle-frame workflows can have their own artifacts\n\n\nThere are also practical reports of middle-frame workflows having artifacts such as flash-like problems, so it is not guaranteed to be magic:\n\nReddit: Wan 2.2 First Frame Middle Frame Last Frame FMLF middle-frame flash issue\n\nSo the order I would use is:\n\n\n    normal I2V short clip first\n    then slightly different FLF endpoint\n    then FMLF/middle anchor only if needed\n\n\n## If the goal is a loop\n\nIf the goal is a clean loop, I would not force a perfect AI-generated loop first.\n\nI would first generate a good short clip.\n\nThen make it loop in editing.\n\nPossible approaches:\n\nLoop method | When useful | Notes\n---|---|---\n**Cut before the bad ending** | The clip looks good until the final frames | simplest\n**Crossfade end→start** | Slight mismatch | easy in any editor\n**Ping-pong / reverse** | Motion can naturally reverse | can look artificial, but stable\n**Frame interpolation** | Need smoother transition | RIFE/other interpolation tools\n**Slightly different FLF endpoint** | You still want FLF | avoid identical A→A\n**FMLF / middle anchor** | Middle needs control | later experiment\n\nFor 8GB VRAM, editing tricks are not a compromise. They are often the practical route.\n\n## My suggested order for your setup\n\nGiven your constraints, I would try:\n\n\n    1. Stop using identical first/last frame for this test.\n    2. Try short normal I2V at 40–48 frames.\n    3. If you need FLF, make the last frame slightly different.\n    4. If you need a loop, create a good non-loop clip first, then loop in editing.\n    5. If the middle still needs control, try FMLF / middle anchor later.\n    6. If color still bumps in the middle, correct it after generation.\n\n\nI would avoid doing this first:\n\n\n    80-frame identical first/last FLF\n\n\nbecause your own test suggests that it creates:\n\n\n    reference → brightness/color excursion → reference\n\n\nwhich is exactly the pattern you are trying to avoid.\n\n## Short version\n\nI would now think of it like this:\n\n\n    Your previous setup:\n      identical first frame + identical last frame\n      = asks FLF to generate an A→A path\n\n    The problem:\n      the model fills the middle with an unwanted exposure/color path\n\n    The fix:\n      do not ask FLF for A→A unless you really need that.\n      use short normal I2V for subtle motion,\n      or use A→A' with a slightly changed last frame,\n      or make the loop later in editing.\n\n\nSo the practical rule is:\n\n\n    FLF for transitions.\n    Normal I2V for living-still motion.\n    Editing/interpolation for loops.\n    FMLF only if the middle needs extra control.\n",
  "title": "Nvidia driver update - reactor node"
}