🔍 Analyze Sigma

A sigma schedule is a list of noise levels, and once you start generating, joining, scaling, and truncating them by hand, they stop being trustworthy. SigmaAnalyzer is the node you put in front of a schedule to find out what it actually contains - max, min, mean, step count, and a full JSON breakdown. If you're reshaping schedules with this pack's other sigma nodes, this is the debugging companion you'll reach for when the output suddenly looks wrong and you want to know why.

The inputs and outputs

One input: sigmas (required, type SIGMAS). Five outputs:

• max_sigma (FLOAT) - the loudest noise level. In a normal txt2img schedule this is your starting noise (≈14.6 for the standard base). If this number looks huge after you scaled something, you've found your problem.
• min_sigma (FLOAT) - the quietest level, where sampling ends.
• mean_sigma (FLOAT) - the average noise level across steps.
• num_steps (INT) - how many steps the schedule actually has. Trivially useful: a truncate-mode denoise modifier silently shortens a schedule, and this is how you'd confirm it.
• analysis (STRING) - a JSON blob with the rest: standard deviation, range, median, variance, and an average slope estimate. Wire it into a text display (or the pack's ShowText-style node) if you want the full picture.

What you'd actually do with it

The realistic workflows are all "check my work" patterns:

• After a SigmaScaler pass, confirm the max didn't explode and nothing went negative (the scaler clamps at zero, but verify).
• After a DenoisingStrengthModifier truncate, check num_steps to see how many steps you're really running - the effective step count is the whole point of truncation.
• Before feeding a schedule to a sampler, sanity-check that max/min look sane. A schedule whose max drifted to 0.01 is going to sample essentially at denoise 0 - probably not what you wanted.
• Comparing two schedules - like the join node's inputs - the min/max/mean trio tells you at a glance whether they're in the same ballpark.

What it won't do

It's statistics, not judgment. It won't tell you whether a schedule is right for your model. That's a question of architecture: an aggressive Karras-shaped curve is fine on DDPM-style checkpoints and a known failure mode on flow-matching ones, so a schedule with a skewed mean isn't inherently bad - it's only bad if it doesn't match what your model wants. Use this node to know the numbers, and use your head for what they mean.

Install

Pack: InitialB Util. ComfyUI Manager → search "InitialB Util" → Install, or:

cd ComfyUI/custom_nodes
git clone https://github.com/benjiyaya/Comfyui_InitialB_Util
cd Comfyui_InitialB_Util
pip install -r requirements.txt

Restart ComfyUI. No model downloads; requirements are torch/numpy/scipy/Pillow, all bundled. The README's clone URL is a placeholder - use the real repo above or Manager. It lives in InitialB/sigma/custom.