BFS Sigmas Preview

What it's for

Your sampler does not divide its work evenly. On a flow-matching model - H3, LTX, Flux, anything from the last two years - the sigma schedule decides whether the twenty-eight steps you queued up are mostly deciding the layout and the identity of the person on screen, or mostly polishing texture. Both are "28 steps". They are not the same run.

BFS Sigmas Preview draws that schedule as a picture: the noise level at the start of each step, with the high-noise end labelled layout / identity, the middle shapes, and the low end detail. It changes nothing - sigmas passes straight through untouched - it just makes an invisible knob visible. The author wrote it for H3's video shift of 12, where most of your steps sit crammed at the top, but it works on any sigmas wire.

How it works

The node reads the schedule after the scheduler and the shift have already done their thing, which is the only place the answer is honest - a shift you set upstream is invisible in a sampler widget but obvious in the curve. It buckets every step except the last by its starting sigma relative to the first one: above 85% is layout/identity, 50–85% is shapes, below 50% is detail. That's a coarse reading of the noise level, not a claim about the model's internals, but it matches the behaviour people describe - composition locks in early, details arrive late.

There's also an optional compare input. Feed it a second schedule - the same step count with a different shift, say - and it's drawn behind yours in blue. That's the useful trick: you're not reading one curve, you're reading what shifting your schedule actually moved.

Inputs and outputs

Required: sigmas, the schedule going to the sampler. Optional: compare, the second schedule.

Three outputs:

• sigmas - the same tensor you fed in, unchanged. That's deliberate: you splice this node inline between your scheduler and the sampler rather than branching off it, so nothing about the run changes when you add it.
• chart (IMAGE) - the 640×360 plot. Drop a Preview Image node on it.
• text (STRING) - a one-line summary: how many steps, how many landed in each zone, and the raw sigma values. Wire it to a Show Text node and you can read the numbers instead of squinting at the graph.

Reading it

If the chart shows most of your steps sitting in the top band, adding steps is mostly adding more layout deliberation - you'll get a marginally different video, not a sharper one. Lowering the shift moves steps down into shapes and detail. The KB's rule of thumb applies here: on a straight flow-matching trajectory, aggressive reshuffling of the schedule hurts more than it helps, so treat the shift as one or two ticks to nudge rather than a big lever. And if compare shows the curve barely moved when you changed a shift value, that's your answer - something upstream is ignoring it, which is a real and well-documented trap with third-party schedulers that apply their own shift.

Install

ComfyUI Manager: search ComfyUI-BFSNodes. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/alisson-anjos/ComfyUI-BFSNodes.git
pip install -r requirements.txt

Restart. It's pure numpy/PIL drawing; no models, no GPU work.

Gotchas

It needs an actual SIGMAS wire, which means the custom-sampling route - a scheduler node feeding SamplerCustomAdvanced. A plain KSampler keeps its schedule inside the node where nothing can read it, so there is no sigmas to hand this node. If you're on KSampler and want to see the curve, move the sampler first.

It's a viewer, not a fixer. The sigmas output is a literal pass-through, so leaving it connected never changes your result, and a curve you don't like has to be fixed upstream - in the scheduler, the step count or the shift. Which is fine: knowing the fix is upstream is most of the value. Half the confusion around shift in this ecosystem is people changing it, seeing nothing, and concluding it does nothing - when what they needed was to look at what the schedule did afterwards.