Nvidia driver update - reactor node

Ah, so, then I think the fix changes too:

---

I think I misunderstood one important detail earlier.

If frame 1 and frame 80 are literally the same image , then this is probably not mainly cumulative last-frame chaining drift.

It sounds more like a same-frame first/last-frame problem :

frame 1  = reference image
frames 20-50 = model invents a transition path and exposure/color moves
frame 80 = the same reference image again

So the model is not simply drifting forward forever. It is doing something more like:

dark/reference
→ unwanted brighter middle
→ dark/reference again

And when you use one of the lighter middle frames as both the first and last frame, it does the opposite:

light/reference
→ unwanted darker middle
→ light/reference again

That is a very useful observation, because it changes the diagnosis.

Direct answer

I would stop treating identical first/last-frame FLF as the main tool for this specific goal.

A simple rule:

FLF is good for “A becomes B.”
FLF is not always good for “A stays A.”

Your goal seems closer to:

A
→ small motion / facial micro-movement / slight acting
→ A

But FLF may interpret identical first/last frames as:

A
→ generate some kind of transition path anyway
→ A

That generated middle path can show up as:

brightness hump
contrast shift
skin tone change
gray flicker
unwanted exposure movement
unwanted visual excursion

So yes, if frame 1 and frame 80 are exactly the same image, the fix changes.

Why identical first/last frames can be unstable

Wan FLF is not simply:

keep this image stable for 80 frames

It is more like:

given a starting frame and an ending frame,
generate the missing motion between them

The ComfyUI Wan FLF documentation describes FLF as using a start frame and an end frame, with the model filling in the intermediate dynamic change:

ComfyUI Wan2.1 FLF2V Native Example

That distinction matters.

FLF is naturally a transition tool :

first image
→ intermediate motion / transformation
→ last image

So if you give it:

first image = A
last image  = A

the model may still try to create a meaningful middle. It may not understand that you want:

A, but almost static, with constant exposure and only tiny motion

It may instead produce:

A
→ some invented motion/lighting/color path
→ A

Your light/dark/light experiment fits that explanation very well.

Similar reports / clues

There are a few reports that point in the same direction.

Same image as first/last causing loop/color problems

This issue is very relevant:

ComfyUI-WanVideoWrapper issue #1541 — Wan 2.2 I2V Looping same image Start-End step - Color contrast increase over time

That report involves using the same image as first/last for a loop and getting problems such as:

color / contrast increase
gray flicker
gray ending

It 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.

First/last frame ping-pong behavior

Another related issue:

ComfyUI-WanVideoWrapper issue #1342 — First and Last Frame Pingponging Wan 2.2

This 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.

Practical comment: identical frames may be bad

There 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:

Reddit: PSA — WAN 2.2 does First Frame Last Frame out of the box

The practical takeaway is:

Do not always use identical first/last frames.
If you use FLF, make the last frame slightly different.

That turns the task into:

A → A'

instead of:

A → A

The model may handle that more naturally.

Updated tool map

I would map the tools like this.

Goal	Better first tool	Why
A clearly changes into B	FLF	This is what first/last-frame generation is good at
A stays mostly A with slight motion	short normal I2V	Less likely to create an artificial transition arc
A loops back to A	normal I2V + editing loop	Often more stable than identical first/last FLF
A loops back to A using FLF anyway	FLF with a slightly modified last frame	Avoids the exact duplicate endpoint problem
The middle of FLF changes too much	shorter clip / middle anchor / FMLF	First+last alone may not constrain the middle
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
8GB VRAM stability	short clips and editing	More iterations, fewer heavy experiments

The main thing:

Use FLF when you want a transition.
Use normal I2V when you want a short living-still / micro-motion shot.
Use editing when you want a clean loop.

Broader map for your current project

Based on the whole thread, I would separate the tasks like this:

Task	Practical path on 8GB VRAM	Avoid as first step
ReActor face swap	Keep it simple, test stills/short clips first	full complex video workflow immediately
Basic Wan video	short normal I2V	long chained clips before stability testing
Add audio	TTS or recorded audio + mux	full speech-to-video model locally
Lip-sync	Wav2Lip / LatentSync as post-process	Wan2.2-S2V 14B on 8GB
Keep hands/nails/jewelry stable	shot planning + clean keyframes + still inpaint	negative prompt only
A→B visual change	FLF	normal I2V only
A→tiny motion→A	short normal I2V	identical first/last FLF
Loop-like result	generate a good short clip, then loop in editing	forcing exact duplicate FLF loop
More control over the middle	FMLF / middle anchor later	hoping first/last alone controls everything
Heavy local video editing	test only after the simple path works	installing many new systems at once

This 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.

What I would test next

I would run a small test matrix.

Test 1 — normal I2V, no FLF

Use the same source image.
Do not set the same image as both first and last.
Generate a short normal I2V clip.
Try 40–48 frames first.

Goal:

Does the brightness hump still appear?

If the brightness hump mostly disappears, then same-frame FLF was probably the trigger.

Test 2 — FLF, but last frame slightly different

Instead of:

first = A
last  = A

try:

first = A
last  = A'

Where A' is almost the same image, but with a tiny real change:

slightly different expression
slightly different head angle
slightly different hand position
slightly different eye direction
slightly different camera crop

Goal:

Give the model a real A→A' path,
instead of forcing it to invent an A→A loop path.

Test 3 — shorter FLF

Try the same setup at:

32 frames
40 frames
48 frames

instead of:

80 frames

Goal:

Does the middle brightness hump shrink when the model has less time to invent an excursion?

Test 4 — loop in editing, not generation

Generate a normal short I2V clip that looks good.

Then loop it afterward using editing techniques:

cut off bad ending frames
crossfade end to start
reverse a copy and ping-pong it
use interpolation between end/start

For interpolation, RIFE is one common frame interpolation family:

RIFE paper

This is not necessarily “better AI generation,” but it may be a more stable production trick.

About FMLF / middle anchors

If first/last alone gives too much freedom to the middle, then a middle anchor is the logical next idea.

There are Wan first-middle-last / multi-keyframe workflows and nodes, for example:

RunComfy: WanFirstMiddleLastFrameToVideo

The idea is:

first frame = A
middle frame = controlled middle state
last frame = A or A'

This can reduce the model’s freedom in the middle.

But I would treat FMLF as a later experiment, not the first fix, because:

more keyframes = more complexity
more nodes = more installation/debugging
8GB VRAM = test carefully
middle-frame workflows can have their own artifacts

There are also practical reports of middle-frame workflows having artifacts such as flash-like problems, so it is not guaranteed to be magic:

Reddit: Wan 2.2 First Frame Middle Frame Last Frame FMLF middle-frame flash issue

So the order I would use is:

normal I2V short clip first
then slightly different FLF endpoint
then FMLF/middle anchor only if needed

If the goal is a loop

If the goal is a clean loop, I would not force a perfect AI-generated loop first.

I would first generate a good short clip.

Then make it loop in editing.

Possible approaches:

Loop method	When useful	Notes
Cut before the bad ending	The clip looks good until the final frames	simplest
Crossfade end→start	Slight mismatch	easy in any editor
Ping-pong / reverse	Motion can naturally reverse	can look artificial, but stable
Frame interpolation	Need smoother transition	RIFE/other interpolation tools
Slightly different FLF endpoint	You still want FLF	avoid identical A→A
FMLF / middle anchor	Middle needs control	later experiment

For 8GB VRAM, editing tricks are not a compromise. They are often the practical route.

My suggested order for your setup

Given your constraints, I would try:

1. Stop using identical first/last frame for this test.
2. Try short normal I2V at 40–48 frames.
3. If you need FLF, make the last frame slightly different.
4. If you need a loop, create a good non-loop clip first, then loop in editing.
5. If the middle still needs control, try FMLF / middle anchor later.
6. If color still bumps in the middle, correct it after generation.

I would avoid doing this first:

80-frame identical first/last FLF

because your own test suggests that it creates:

reference → brightness/color excursion → reference

which is exactly the pattern you are trying to avoid.

Short version

I would now think of it like this:

Your previous setup:
  identical first frame + identical last frame
  = asks FLF to generate an A→A path

The problem:
  the model fills the middle with an unwanted exposure/color path

The fix:
  do not ask FLF for A→A unless you really need that.
  use short normal I2V for subtle motion,
  or use A→A' with a slightly changed last frame,
  or make the loop later in editing.

So the practical rule is:

FLF for transitions.
Normal I2V for living-still motion.
Editing/interpolation for loops.
FMLF only if the middle needs extra control.