PiD Color Bias Correction

If your Flux.2 outputs keep coming back a little too bright and with a faint blue tint - especially on darker scenes - that's not your prompt or your sampler, it's a known systematic drift in the model's fast decoder path. PiD Color Bias Correction patches it out with a small, cheap correction applied at the very start of sampling.

What it's actually doing

The node subtracts a per-channel bias from x0_pred (the model's running prediction of the final clean image) at the first sampling step. That bias isn't guessed - it's a small linear model calibrated specifically against Flux.2's observed drift: it tends to brighten dark scenes and add a blue cast on top. Because the correction is applied once, early, and cheaply, it's not adding meaningful compute to your generation - it's a one-shot nudge in the right direction before the rest of sampling proceeds normally.

This lands squarely in "small tool, real problem" territory. Flux.2's fast, distilled paths have a documented color-drift habit - Klein at 4 steps is reported to shift toward warmer tones on edits specifically, reproducible on both fp8 and fp16, and the community's own fix for that particular symptom is histogram/color matching against the source image. The brighten-and-blue pattern this node targets reads as a related but distinct symptom of the same underlying class of problem: a fast decoder path that doesn't hold color as faithfully as a full, unhurried one. Different corner of the same issue, different fix - this one's a calibrated bias patch instead of post-hoc histogram matching.

The inputs and outputs that matter

• model (MODEL) in, model (MODEL) out - a straight patch, wire it in before your sampler like any other model-patching node.
• strength (default 1, range -20 to 20) - how hard the correction pushes. 1 is calibrated-normal; push it up if you're still seeing the brighten/blue symptom after applying it, or down toward 0 if the correction is overshooting and making things look flat or off in the other direction. Negative values invert the correction - there's no obvious reason to go there unless you're deliberately chasing a warmer/darker look, but the range is open if you want to experiment.
• backbone (enum) - currently a single choice, flux2. This node is Flux.2-specific; it isn't a general-purpose color corrector for whatever model you happen to be running.

Installing it

No separate install - it's part of KJNodes:

• ComfyUI Manager - search KJNodes for ComfyUI, install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, then pip install -r ComfyUI-KJNodes/requirements.txt, restart.

Nothing extra downloads for this specific node - it patches a Flux.2 model you already have loaded.

Common issues & troubleshooting

It's filed under KJNodes/experimental for a reason. This is a young, narrowly-scoped fix for a specific backbone's specific drift pattern, not a battle-tested general tool. If a future Flux.2 checkpoint update changes the underlying drift behavior, the calibrated bias here could stop matching reality - if outputs start looking worse after an update, try disabling the node before assuming your workflow is broken elsewhere.

Wrong backbone, no effect (or the wrong effect). The correction is fit to Flux.2's specific bias. Bolting this onto a different model family via a workaround wouldn't correct anything real - there's nothing to select besides flux2 today, and that's deliberate rather than an oversight.

Over-correction reads as flat, desaturated images. If your images look color-corrected to the point of losing punch, back strength down from 1 rather than off entirely - you usually want some of the fix, not none.