Deflicker Frames

You know the look: you stitch a long Wan, VACE, or FramePack generation together and the result has a visible brightness jump every chunk boundary, plus a fine per-frame shimmer that makes the whole clip feel unstable. That's not your render being broken - it's the inherent cost of generating video in 81-frame windows and slapping the pieces together. Deflicker Frames exists to scrub those artifacts out before you save, and it's refreshingly honest about what it does: no API calls, no keys, no model downloads. Just a stack of PyTorch math that runs on the frames you already have.

It sits in the simplest possible spot in your graph: Load Video → Deflicker Frames → Save Video (or wire its images output straight into a preview or the VAE decode of a chunked pipeline). Feed it an IMAGE tensor - the whole frame sequence - and it hands back two outputs: the corrected images, and a debug_heatmap that shows you exactly what it changed (red = brightened, blue = darkened, black = untouched). Plug that second one into a Preview node once to sanity-check before you trust the result.

How it actually works

The code ships as pure torch - requirements.txt is literally just torch, which you already have - and it runs up to four phases depending on your mode:

• step_removal (default): hunts for sharp frame-to-frame brightness discontinuities that stand out from the normal noise floor - those are your latent-space shifts at chunk seams - and applies an affine gain/gamma correction to pin every frame back to the stable reference level. Crucially, it preserves the natural brightness trend; it only eats the discrete jumps.
• temporal_smoothing: computes per-frame mean brightness, smooths the curve with a Gaussian window, and matches each frame to it. This is the fix for random per-frame flicker rather than steps. A linear-regression trend detector tries to tell a real fade from noise and leave the fade alone.
• both: step removal first, then temporal smoothing on the result. Use this when you've got both problems, which is most of the time on long renders.

On top of that there's auto-equalize (eq_enable), which converts to LAB, finds abnormal brightness jumps, and blends across them with CDF histogram matching. And a genuinely nice touch: it auto-detects black letterbox/pillarbox borders from stabilized footage and excludes them from all the statistics, so your black bars don't drag the correction. No cropping step required.

The inputs that matter

Two are worth your attention; the rest are tune-knobs with sane defaults.

• mode - step_removal first, then both if you still see shimmer. temporal_smoothing alone is for footage with no chunk seams at all.
• channels - leave it on L (brightness only, colors preserved). LAB also corrects color shifts; it's slower and usually unnecessary.
• step_strength (default 1.5) - how sensitive the step detector is. Drop toward 1.0 to be conservative.
• smooth_window (default 25) - aggressiveness of temporal smoothing. Bump it to 31+ for heavy flicker; the widget steps by 2 so you always get an odd number (and if you type an even one, the code silently rounds it down).
• smooth_drift - set to flicker_only if a slow brightness drift is surviving the auto trend detection.

Installing it

ComfyUI Manager is the easy path: search "comfyUi-deflicker" (or just "deflicker") and install. Or, old-school:

cd ComfyUI/custom_nodes
git clone https://github.com/karcsiha/comfyUi-deflicker

Restart ComfyUI and the node shows up under Add Node → deflicker → Deflicker Frames. That's the whole install - no model files, no extra pip packages.

Where people get burned

• Long clips eating RAM: the output_heatmap output is a full-size extra image buffer. On 200+ frame renders or low-RAM machines, flip it off - the heatmap becomes a 1×1 placeholder and your peak memory drops to roughly one input plus one output copy.
• Overcorrection: smooth_strength above 1.5 can smear things and smooth_pixel (per-pixel smoothing, 0.3–0.5 for AI video) is a known ghosting risk on motion. Treat those as last resorts, not defaults.
• Expecting a miracle on real footage: this is a statistics-based deflicker in the LRTimelapse tradition, not a temporal inpainter. Bad VAE decode wobble won't be saved by it - only brightness/color flicker will.

It's a small, young pack with no big community footprint yet, but the defaults are sensible and the debug heatmap means you're never flying blind. For anyone doing multi-chunk Wan/FramePack work, it's the kind of two-node addition that quietly upgrades every render you put through it.