Convert String To Int [LP]

One of the pack's set of type-conversion nodes - the README specifically calls out that this collection covers more variable types than most equivalents in other packs, and this is the plainest of them: text in, whole number out. Useful anywhere a value arrives as a string (parsed from an API response, typed into a String node, pulled off a filename) but the next node down the line needs an actual integer.

What it does

Feed it a string and it converts it directly to an INT. There's no rounding widget on this node at all - that's the detail worth noticing, because its sibling, Convert String To Number, has an explicit round_integer dropdown (round / round down / round up) for exactly this situation. This node doesn't. The reasonable inference is that it expects a string that already looks like a clean whole number, and doesn't offer a controlled way to handle a decimal value if one shows up.

Inputs and outputs that matter

• string (required, defaults to empty) - the text to convert.

Output: INT - a single whole number, ready to wire into anything expecting an integer: a batch count, a seed, a dimension.

Installing it

Through ComfyUI Manager, search "ComfyUI Level Pixel" or "ComfyUI-LevelPixel." Or:

cd ComfyUI/custom_nodes
git clone https://github.com/LevelPixel/ComfyUI-LevelPixel.git

Restart ComfyUI. No models or dependencies - this is pure Python type conversion.

Where people get burned

The obvious failure case is feeding it something that isn't cleanly a whole number - a decimal like "3.7", or anything with stray characters, units, or whitespace baked in. With no rounding mode exposed, there's no documented graceful fallback for a value like that; the safer bet is to only route strings you know are already integer-shaped through this node, and if there's any chance the value has a decimal point, use Convert String To Number instead, since that one gives you an explicit choice about how to round it down to a whole number.

The other place this bites people: anything coming out of a text pipeline that isn't guaranteed to be numeric at all - a field from a parsed JSON object that might be a string, might be empty, might have a label attached. If a workflow that uses this node fails unpredictably deeper in the graph, trace back to whatever's feeding this conversion first; a non-numeric string here is a common root cause for a failure that shows up somewhere else entirely.