Comfy-Org

/

MiniMax-H3

like 1.65k

Follow

Comfy Org 12.8k

Summary

When generating video with the ref2va model, an unnatural, cartoon-like red patch
appears on the subject's cheeks. It is not present in the reference image, is never asked
for in the prompt, and looks like painted-on blush rather than a natural skin tone.

Two properties make me think this is a model/implementation problem rather than a
configuration mistake on my side:

1. It also occurs with no LoRAs loaded at all — the plain ref2va checkpoint.
2. It behaves like temporal colour drift, not a per-frame sampling artifact: in short
   clips it is absent at the start and intensifies frame by frame, and in longer clips
   it affects a whole contiguous segment at a time.

The MiniMax-H3-Realism-People LoRA suppresses it, which is presumably incidental —
that adapter is documented as fixing plastic-looking skin, not colour drift. Relying on
it as the only defence is fragile: at some resolutions the artifact appears even at
strength 1.0 (see Fig 2).

Environment

Graph: UNETLoader -> (optional LoRAs) -> MiniMaxH3ReferenceToVideo ->
MiniMaxH3AddGuide (frames 0, 62, 123) -> SamplerCustomAdvanced
(BasicGuider, res_multistep, simple, 8 steps) -> VAEDecode -> CreateVideo.

Reference image: a single close-up of a face (attached below). Prompt asks for a person
facing camera, vocalising, plain background. The prompt contains no words about colour,
redness or blush — I verified separately that removing all such wording changes nothing.

The reference image contains no red

The reference on the left has an even skin tone. Note that frame 0 is a guide frame
built from that exact image and is still rendered with red cheeks, so the guides do not
protect the frames they are applied to.

Fig 1 — realism LoRA strength decides it (768x1344, 124 frames, seed 4101149435)

Everything identical except the realism LoRA strength.

• strength 1.0 -> no red
• strength 0.0 (turbo LoRA still loaded) -> red
• no LoRAs at all -> red

The affected clips split into two segments at the frame-62 guide: frames 0-61 are red
throughout (including the frame-0 guide itself), and frames 62-123 are clean. The switch
at frame 62 is abrupt — background and clothing change at the same frame, i.e. the two
segments are generated as effectively different shots. In short clips with a single guide
at frame 0 the behaviour looks different: the first frames are clean and the red builds up
progressively (visible in Fig 2, rows 256 and 512).

Fig 2 — strength 1.0 is not sufficient; resolution flips it non-monotonically

Realism LoRA at 1.0 for all four, same seed and prompt, all four generated in a single
script run.

The artifact is not simply "worse at low resolution" — 384 is clean while 512 is not.

Reproduction

python h3_generator.py \
  --prompt "$(cat prompt.txt)" \
  --refs face.png --anchor-image face.png --anchor-frames 0,62,123 \
  --duration 5 --ratio 9:16 --seed 4101149435 --steps 8 \
  --ref-image-size max --realism 0.0

(--realism 0.0 keeps the turbo LoRA and sets the realism LoRA's strength_model to 0.)

Notes that may help narrow it down

• The pipeline is deterministic, but only conditionally. Repeating an identical
  command inside one script gives bit-identical output (verified: decoded frames
  maxdiff == 0 over 124 frames, at both 256px and 768px). However, the same command
  run after a different preceding job produces different output — e.g. a 768px run
  preceded by 256px runs differs from the same 768px run executed first
  (maxdiff == 239). Same ComfyUI process, same code, same seed. I suspect model
  residency/offload under --lowvram affects the numerics. This also means A/B
  comparisons are only valid inside a single script run.
• Changing sampling steps from 8 to 20 does not remove the red.
• Anchoring more densely does suppress it, but only because dense guides freeze the face
  entirely (the subject stops moving and the prompt's wardrobe is ignored), so it is not a
  usable workaround. An intermediate guide spacing did not help.
• Wardrobe wording in the prompt (hoodie / t-shirt / blazer) shifts whether the red
  appears, which I assume is just another way of perturbing the generation.

What I am asking

Is this a known characteristic of the ref2va weights, or of the ComfyUI implementation?
The fact that a LoRA not documented as addressing colour is what holds it back, and that
whole segments are affected while neighbouring segments of the same clip are clean, makes
me suspect colour drift in the conditioning path rather than an inherent property of the
base weights. I would be glad to run further tests if that would help narrow it down.

Related: #30 ("Why MiniMax H3 Ruins Faces on Wide Shots?") reports structural face
degradation but not colour.