Pixel Sort (ASDF)
The glitch look that drags a whole Java runtime into your graph
- image
- IMAGE
Pixel sorting is the effect that makes everything look like it was scanned mid-glitch: each row and column of pixels gets sliced at brightness boundaries and the runs between them sorted, so streaks of color smear sideways and down like datamoshing's calmer cousin. This node brings Kim Asendorf's 2010 ASDFPixelSort Processing sketch into ComfyUI. The look is great for album covers, poster art, and "my render has been corrupted by the machine" vibes. The cost of getting it is real, and you should know it going in.
Here's the thing the README buries: this node does not do any pixel sorting in Python. It writes your image to a temp file, shells out to processing-java (Processing 4.3, a Java-based creative-coding environment), runs the sketch, and reads the result back. That means your ComfyUI install now depends on Java 17+, a Processing installation, and a virtual display. The requirements.txt is a ghost - torch, numpy, Pillow - all already in ComfyUI. The real dependencies live outside pip.
What the node does
Wire it the obvious way: LoadImage → Pixel Sort (ASDF) → SaveImage. It takes one IMAGE in and hands one IMAGE back, so it slots anywhere in a post-processing chain - sort first, then upscale or color-grade the result.
The mode enum is the main switch, and it decides which pixels act as the boundaries that sorting runs stop at:
- white - runs stop at white-ish pixels (threshold as an absolute RGB value,
0= pure white) - black - runs stop at black-ish pixels (the same absolute-RGB scale, negative)
- bright - uses a 0–255 brightness threshold
- dark - uses a 0–255 darkness threshold
For each row and then each column, the sketch scans for a run of pixels inside the threshold window, grabs that slice, sorts it, and writes it back. That's why you get those directional smears instead of just noise.
Here's the odd part about this "basic" node: all four thresholds are required inputs, so the UI forces you to set them even if you only care about one mode. The defaults (white_threshold −12345678, black_threshold −3456789, bright_threshold 127, dark_threshold 223) are the values from the original sketch and are a fine place to start. Think of the white/black pair as one scale (absolute RGB, −16777216 to 0) and bright/dark as another (0–255), and only bother with the ones matching your mode.
Installing it
Via ComfyUI Manager, search "ASDF Pixel Sort" and install. Or:
cd ComfyUI/custom_nodes
git clone https://github.com/A043-studios/ComfyUI-ASDF-Pixel-Sort-Nodes
Then restart ComfyUI. But cloning is the easy 5% - you also need Processing itself:
- Java 17+ (
sudo apt install openjdk-17-jdkon Debian/Ubuntu) - Processing 4.3, with
processing-javaavailable - The node hardcodes paths at
/root/Processing/processing-4.3/processing-javaand/root/Processing/ASDFPixelSort, so either install it exactly there or editpixel_sort_node.py - A virtual display on
:99for headless runs:Xvfb :99 -screen 0 1280x1024x24 &
The README tells you to run sudo ./scripts/install.sh to automate all this - but no scripts/ directory ships in the repo. That step does not exist as written, which tells you a lot about how tested this pack is.
The honest troubleshooting
This is a one-commit pack (changelog: "Initial release," June 2025) with essentially zero community footprint, so the failure modes below come from reading the code, not from a forum full of war stories.
- It fails out of the box with the stock sketch. The shipped
ASDFPixelSort.pdeis the unmodified 2010 original: it ignores every argument the node passes, hardcodesmountains.jpgas its input, saves to its own folder, and waits for a mouse click to exit. The node passes a temp-file path, then checks that exact path for output and raises "Output image was not created" - or hangs into the 120-second timeout. To make it work you must patch the sketch to read the input/output args and exit after saving. Anyone who tells you it "just works" has already fixed it themselves. - "Pixel sort timed out." The stock sketch only exits on click or keypress; headless, that's the timeout.
- Single image only. The node takes
image[0]and drops the batch, so feeding it frames will process one and discard the rest.
My honest take: if the glitchy streak look is the goal and you don't already live in a Java/Processing world, a pure-Python pixel sorter gives you the same aesthetic without a JVM and Xvfb parked inside your graph. If you're set on this pack, grab the Advanced sibling instead - it lets you point at a fixed sketch path without editing Python, which you'll need anyway.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| mode | COMBO | white | 4 options: white, black, bright, dark |
| white_threshold | INT | -12345678-16777216–0 | — |
| black_threshold | INT | -3456789-16777216–0 | — |
| bright_threshold | INT | 1270–255 | — |
| dark_threshold | INT | 2230–255 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |