Pixel Sorting Explained: The Glitch Algorithm and the Settings That Read as Intentional

<!-- Body starts at H2. Title above is the page H1, rendered by the front-end. -->

What Is Pixel Sorting?

Pixel sorting is a glitch technique that rearranges runs of pixels along a row or column by a chosen property: brightness, hue, or saturation. The result is the melted, streaked look you've probably seen on glitch-art feeds. The technique dates to 2010, when Kim Asendorf published ASDFPixelSort, a Processing script that sorts portions of pixels in an image with threshold control. Nearly every later implementation cites that script as the origin, from Python ports to GLSL shaders to After Effects plugins.

Below: the actual mechanism (intervals and sort criteria), the settings that give you real control (threshold windows, sort direction, start/stop modes), and what separates a pixel sort that reads as a deliberate choice from one that just reads as broken.

How Does the Pixel Sorting Algorithm Actually Work?

Intervals: how the image gets split into sortable runs

A pixel sort doesn't touch a whole row or column at once. The row or column first gets split into "intervals," runs of pixels bounded by regions that are too light or too dark relative to a threshold window. Only the pixels inside an interval get rearranged. Everything outside it stays put. Interval boundaries are luminance-driven: the edge of a light-or-dark region is the edge of the interval that gets sorted.

Once an interval is defined, the pixels inside it get sorted against a chosen property: brightness, hue, or saturation. More on that next.

Why classic pixel-sort output looks like a grid, not one smear

Asendorf's original implementation applies this pass twice, first vertically, then horizontally. That's why the archetypal pixel-sort look reads as overlapping streak directions rather than a single smear along one axis. If you've only ever seen the "default" look, that two-pass structure is why.

Newer implementations generalize the interval step past a simple threshold. Some define intervals by edge detection, some by fixed row spans, some by random splits, then apply the same sort-by-property step inside each one. Want the same exact-settings comparison treatment applied to a different algorithm? Floyd-Steinberg vs ordered dithering walks through the same "which exact rule changes the output" problem for dithering.

What Are the Pixel Sort Criteria: Brightness vs Hue vs Saturation?

The sort criteria is the property pixels get compared on once they're inside an interval. Brightness is the default in most implementations. Hue and saturation are the other two you'll usually find exposed as options.

Direction doubles your options for free. Sorting each criterion ascending or descending flips which end of the value range leads the streak, so three criteria times two directions gives you six distinct looks from the same interval settings.

How Do Threshold Settings Control the Glitch?

Threshold is a lower/upper window on the active sort parameter's value range. Only pixels whose value falls inside that window qualify for sorting. With brightness active, a pixel needs a value above the lower threshold and below the upper threshold to be included. Pixels outside the window are left alone.

The width of that window is your main creative lever. A tight window produces small, fragmented glitches, because few pixels qualify and interval runs stay short. A loose window produces long, smeared streaks, because most of the tonal range qualifies and intervals run long. Treat the threshold window as the effect's brush size. It isn't an afterthought.

Asendorf's original script also exposes three start/stop modes that change what triggers the beginning and end of a sorted run along a row or column:

• Black mode: a run starts at a non-black pixel and stops at a black pixel.
• Brightness mode: a run starts at a bright pixel and stops at a dark pixel.
• White mode: a run starts at a non-white pixel and stops at a white pixel.

These modes matter most on images with large flat-color regions: skies, walls, backdrops. They decide whether that region becomes one long interval or breaks into several shorter ones. Verify exact threshold values against your own source image before you publish them as settings. A threshold that just fragments on one photo can already look like noise on another with a different tonal range.

What Settings Make a Pixel Sort Look Intentional Instead of Broken?

The most common failure: running a sort edge-to-edge on a low-contrast source with a threshold window wide enough to catch nearly the whole tonal range. The result reads as random corruption, not a choice. There's no untouched reference area left for the eye to compare against.

Three fixes work every time:

1. Start from a high-contrast source. Bright highlights and deep shadows create more interesting, more numerous intervals than a flat, evenly lit photo.
2. Mask the sort to one region (a sky, a garment, a single subject) instead of running it across the whole frame. A partially sorted image reads as intentional because the untouched area proves the effect is a choice, not a rendering failure.
3. Log the exact threshold and criteria you used. Reproducibility is what turns a one-off experiment into a technique you can apply consistently across a series.

The same intentional-vs-fake problem shows up in how to make pixel art from a photo without it reading as fake. Different effect, same underlying rule: constraint reads as choice, and lack of constraint reads as accident.

Is Pixel Sorting in Photoshop or TouchDesigner the Same as a Real Sort?

No, and it's worth being direct about that. Photoshop tutorials that teach "pixel sorting" are filter-stack simulations of the look: streak and motion-blur tricks stacked to approximate the visual, not a threshold-driven sort running against real pixel values. That's a fine approach if you're already in Photoshop and don't want to touch code. It just isn't the algorithm.

The same honesty applies live. TouchDesigner "pixel sort" builds for VJ sets are typically feedback-loop pseudo-sorts built from texture operators, because the true per-pixel algorithm evaluates and reorders whole runs of pixels. That's a still-image operation, and it isn't realtime-friendly at 60fps. Need the look live? A feedback-loop approximation or a pre-rendered sorted clip is the practical answer, not a real-time true sort.

A real threshold-driven sort belongs on stills and pre-rendered clips, where you can dial in criteria and threshold exactly and see the result before it ships. Reverse-engineering the Obra Dinn look applies the same real-algorithm-vs-approximation honesty to a different aesthetic, if you want the comparison in another context.

Frequently Asked Questions

Who invented pixel sorting?

Kim Asendorf published the original pixel-sorting technique in 2010 as ASDFPixelSort, a Processing script that sorts runs of pixels along a row or column with threshold control. Nearly every later implementation, from Python ports to GLSL shaders to After Effects plugins, traces back to that script. That's why it's the standard attribution point for the effect.

What's the difference between pixel sort brightness, hue, and saturation modes?

The sort parameter decides which pixel property gets compared when a run is rearranged. Brightness produces the classic melting drips and soft tonal gradients. Hue produces rainbow-like color streaks. Saturation pulls vivid color out from a muted background. All three use the same interval and threshold mechanism underneath; only the comparison value changes.

Why does my pixel sort look like random noise instead of an intentional effect?

Usually one of three things: the source image lacks contrast, the sort is running edge-to-edge instead of masked to one region, or the threshold window is too wide to leave any untouched reference area. Start from a high-contrast source, mask the sort to a sky, garment, or single subject, and log the exact threshold and criteria you used. That's what separates a deliberate look from broken output.

Does the threshold value matter more than the sort criteria?

For visual character, yes. The sort criteria (brightness, hue, or saturation) decides what streaks form. The threshold's lower/upper window decides how much of the image participates and how large each streak is. A tight window yields small fragmented glitches; a loose one yields long smeared runs. Most reproducible looks are threshold-first, criteria-second decisions.

Can I run pixel sorting live, like in a VJ set?

Not the true per-pixel algorithm. It's a still-image process that evaluates and reorders whole runs of pixels, which isn't realtime-friendly at 60fps. Live setups like TouchDesigner fake the look with feedback loops or displacement instead, or pre-render sorted clips offline and play them back on stage.

Conclusion

Pixel sorting is one algorithm, Asendorf's 2010 interval-and-threshold approach, with two real creative levers. Sort criteria decides what kind of streak forms. Threshold decides how much of the image it touches. Everything else, from Photoshop simulations to live VJ feedback loops, is a workaround for a context where the real algorithm doesn't fit. Pick criteria for the character you want. Pick a threshold window for how much you want to touch. Mask instead of running edge-to-edge if you want the result to read as a choice, not an accident.

Try it yourself: open pixel sort in kott® with the effect already loaded, and test criteria and threshold on your own image.