LatentOperationLogistic

The name says "logistic function" - the classic S-curve that maps any real number into (0, 1). The code does something else. LatentOperationLogistic is implemented as torch.nn.functional.logsigmoid(latent * alpha), which is the log of the sigmoid. That's not a rounding error; it changes the shape of the curve completely, and every output is ≤ 0. If you came here expecting a gentle squash into 0–1, you've come to the wrong node - that's LatentOperationSigmoid, sitting one row down in the same pack.

What log-sigmoid actually does

For a value x, logsigmoid(x) = log(sigmoid(x)). It's a monotone function that:

• approaches 0 as x → +∞,
• approaches x (roughly) as x → −∞ - it's near-linear on the negative side,
• is always at or below zero.

So applying it to a latent shifts the entire distribution negative and compresses the positive tail hard while leaving the negative side mostly alone. That's a very different transformation from "logistic." The README's table says "Apply logistic function," and the node even defaults alpha to 1.0 like every other activation in the pack - none of that hints at what the source does. This is a genuine "trust the code, not the docs" moment, and it's worth being blunt about because it will produce garbage when you expected a sigmoid.

The one input

• alpha (FLOAT, default 1.0) - input gain, exactly like every LatentOperation* activation in this pack. logsigmoid(latent * alpha). The tooltip is silent, but the source is unambiguous: alpha scales the latent before the function runs. Larger alpha makes the compression more aggressive; smaller alpha flattens everything toward the linear negative branch.

There's no other knob. No optional slope, no temperature. One float, that's it.

Output and the apply gotcha

The single output is op, type LATENT_OPERATION - a deferred callable, not a result. That's how the whole hnmr293/ComfyUI-latent-ops pack works: every node builds an operation description that something else has to execute. The pack ships no apply node, so your options are feeding the op into a consumer that accepts LATENT_OPERATION (Sonar's SonarApplyLatentOperationCFG is the one people actually find), or writing your own apply node. Expect a type mismatch if you wire op directly into a VAE Decode.

Do you need it?

Honestly? Probably not. If you wanted to squash values into a 0–1 range, use LatentOperationSigmoid (true sigmoid) or the pack's Latent01ToImage for the actual display path. Log-sigmoid's asymmetry - soft ceiling, linear floor - is a real tool if you're deliberately modeling "bright values compress, dark values pass through," the kind of thing you'd chase when tonemapping or shaping a latent distribution by hand. It's a niche of a niche, and the misleading name means it's mostly useful for catching people off guard. But if you know what you're signing up for, at least now you know what it really does.

Install

Boring and easy. ComfyUI Manager → search ComfyUI-latent-ops, or clone it:

cd ComfyUI/custom_nodes
git clone https://github.com/hnmr293/ComfyUI-latent-ops

Restart and you're done - no requirements.txt, no model downloads, just PyTorch. The author, hnmr293 (of sd-webui-cutoff fame), wrote this as his personal latent toolkit, and it shows: terse, correct, and entirely unmarketed. Everything's under hnmr/latent_ops. And if you ever wonder whether a node does what its name says, the source is five files of clean Python in custom_nodes/ComfyUI-latent-ops/latent_ops/ - cheap to read, and this node is exhibit A for why you should.