Sigmas To Float

SIGMAS is one of those ComfyUI types that's everywhere in sampling and invisible everywhere else - it's the tensor of noise levels a sampler steps through, one value per denoising step, and it's opaque by design: you can wire it between a scheduler node and a sampler, but you can't easily look inside it or use it anywhere that expects a plain number. Sigmas To Float exists purely to break that opacity: feed it a SIGMAS tensor, get back a plain FLOAT list, the same values in a form any generic node - a debug text display, a math node, a custom schedule builder - can actually work with.

Why you'd want this

The obvious case is inspection: you're using a scheduler node (or a custom sampler that builds its own sigma schedule) and you want to actually see the numbers - is the schedule front-loaded or back-loaded, how many steps is it really taking, does a "custom sigmas" option somewhere upstream look like what you expected. Piping the schedule through this and into a text-display node turns an invisible tensor into something you can read.

The less obvious case is reuse: once your noise schedule is a plain float list, you can feed it into anything else in ComfyUI that consumes float lists - building your own per-step logic, logging it alongside other run metadata, or comparing two schedulers' output side by side as numbers instead of squinting at generated images and guessing which one changed.

The input and output that matter

There's exactly one of each - nothing to configure:

• sigmas in - a SIGMAS tensor, from any scheduler or custom sampler node that produces one.
• float out - the same values as a plain float list.

How to install it

Standard KJNodes install: ComfyUI Manager → search "KJNodes for ComfyUI" → install, or cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, then pip install -r ComfyUI-KJNodes/requirements.txt, then restart. This is a pure type conversion - no dependencies, no model downloads.

Common issues & troubleshooting

There's genuinely not much to go wrong here - it's a one-step tensor-to-list conversion with no parameters to misconfigure. The couple of things worth knowing:

The output length is exactly your step count (plus one). Sigma schedules include a final near-zero value marking "fully denoised," so if you're comparing the float list's length against your sampler's step count and it looks off by one, that's expected, not a bug.

Different samplers and schedulers produce genuinely different-shaped schedules, and this node just reports whatever it's handed - it doesn't normalize or interpret anything. If two workflows using different schedulers look wildly different once converted here, that reflects a real difference in how those schedulers pace their noise removal, not an error in the conversion.