🔪🖼 Horizontal Cut and Shift 🔼🔽

Full honesty upfront: this node is newer than the pack's own README documentation, so there's no author write-up to lean on for exactly what it does step by step. What's genuinely verifiable is the interface - a single image in, a single image out, and three plain pixel-based integer controls plus a fill color. That combination points squarely at a cut-and-displace effect: slicing the image at a horizontal position and offsetting part of it, filling whatever gap that exposes with a solid color. It's the kind of tool people reach for to build a deliberate glitch look, a torn-strip effect, or a stylized displacement rather than anything photorealistic.

Rather than guess at which of the three numeric inputs controls which exact behavior - that's not something the schema or the README settles - the honest move is to wire it up, connect a Preview Image node right after it, and nudge each value up from zero one at a time. You'll see the effect immediately and it'll be obvious within a minute which control does what for your specific image.

The inputs and outputs that matter

Required: image, your source. Three integer controls - X, Y, Z - each ranging 0 to 4096, default 0, sized to match pixel dimensions rather than percentages, which is a hint that at least one of them is a cut position or shift distance measured directly in pixels. And fill_color, a simple dropdown of black or white, for whatever area the cut-and-shift operation exposes that isn't covered by the original image content.

Output is a single IMAGE.

Installing it

Through ComfyUI Manager: search Bjornulf_custom_nodes, install, restart. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/justUmen/Bjornulf_custom_nodes

Install the shared requirements.txt afterward. This is pure image-array manipulation - no heavy dependency required, so it works on a minimal install of the pack.

Where people get burned

The obvious one, given the honesty above: don't build a workflow that depends on precise, predictable output from this node without testing it on your actual image first. With three unlabeled-by-documentation pixel controls, the fastest way to understand it is trial and error with a preview attached, not assumption. If you're after a specific, well-established effect - a clean horizontal displacement/glitch look with more predictable controls - it may be worth comparing this against dedicated glitch-effect nodes elsewhere in the ecosystem before committing to this one for a production pipeline, simply because those tend to ship with clearer documentation of what each parameter does. This is a reasonable node to experiment with; it's not yet one you should build blind automation around.