Sigmas DeleteBelowFloor

There are two ways to deal with a sigma schedule that dips too close to zero: push the low values back up, or throw them out entirely. Sigmas Cleanup does the first. Sigmas DeleteBelowFloor does the second - any step whose sigma is under floor gets removed from the list rather than clamped, which means your output schedule can end up genuinely shorter than the one you fed in.

Why that distinction matters

The bottom of a noise schedule is where samplers get twitchy - sigma values near zero are numerically fragile territory, and a schedule that lingers down there can waste steps or introduce instability without adding real detail. Clamping (what Sigmas Cleanup does) keeps your step count intact and just raises the floor. Deleting (what this node does) is more aggressive: it assumes those trailing near-zero steps aren't worth running at all, and cuts them rather than distorting them upward. Which one you want depends on whether you care more about preserving your exact step count or about not spending compute on steps that barely move the image.

How it works

Straightforward: walk the input sigmas, keep every value at or above floor, drop the rest. No reordering, no interpolation to fill the gap - just a shorter list at the end.

The inputs and outputs that matter

• sigmas (SIGMAS, required) - the schedule to filter.
• floor (default 0.0291675, range -10000 to 10000) - the cutoff. Anything below it is removed. That default isn't a round number by accident - it's the same figure Sigmas Cleanup uses as its default floor, which reads like the actual minimum sigma a real model's schedule bottoms out at, not an arbitrary placeholder.

Output is a single SIGMAS list, which may be shorter than the input.

How to install it

• ComfyUI Manager - search "RES4LYF", install, restart.
• Manual - activate your venv, cd ComfyUI/custom_nodes && git clone https://github.com/ClownsharkBatwing/RES4LYF, cd RES4LYF, pip install -r requirements.txt (portable builds: use the embedded pip.exe). Restart.

Common issues & troubleshooting

A shorter output schedule than you expected. That's the whole point of this node, not a bug - if you wanted the step count preserved, you wanted Sigmas Cleanup instead, which clamps rather than deletes.

Downstream nodes that assume a fixed step count can choke. If something later in your graph (a step counter, a fixed-length latent batch, a chain-sampler split) was built around the original schedule's length, a schedule that got shorter here will throw that off. Check Sigmas Count on the output before wiring it into anything that's counting on a specific number of steps.

Setting floor too high deletes more than you meant to. This isn't just trimming the very last near-zero step - push the floor up and you can chop off a meaningful chunk of your late, fine-detail steps. Start near the default and raise it deliberately, checking the output length each time, rather than guessing at a big value up front.