GlitchSort2 is a Processing application that uses interrupted pixel-sorting to create glitchy images. Since it has found an audience among glitch artists, I’m setting up this page as a point from which to download a current version and reference materials, as these become available. I’ll also post news or links to news about GlitchSort2 here.
In version 1.0b4, released on August 1, 2012, there are four different sorting algorithms, each of which has a different behavior that can be used to affect images in different ways. Images larger than your screen can be panned by dragging with the mouse or fit to the screen dimensions for display. I’ve added a “munge” feature that does glitchy compositing, and a “degrade” command that uses JPEG compression to degrade an image. See the reference for details.
I released an update, GlitchSort version 01b5, on August 23, 2012 and renamed the app to “GlitchSort.” Version 01b5 provided a new sorting tool that operates on zigzag-scanned blocks of pixels using any of the available algorithms, and a color quantizing tool, but did not update the manual.
GlitchSort 1.0b9, for Processing 1.5.1, is now available: GlitchSort_v01b9. There are bundled applications for Windows, MacOSX, and Linux: YMMV as far as running these. If you have Java installed, they should run, but I have only tested them on MacOS. The bundled documentation is for version 0.1b8, but I describe new features below and in the source code. Here is a higher resolution version of the manual (33M PDF) with much better image quality. The print version (60M PDF) offers the highest resolution, for printing. Note that GlitchSort requires ControlP5 1.5.2, which is not bundled with the Processing application (it is bundled with the standalone applications).
Version 1.0b8a fixed the denoise command to handle edge and corner pixels correctly, and changed the ‘_’ (underscore) hack to repeat the last command four times, with a 90 degree rotation between executions, when last command is in “gl<>9kjdGLKJD”.
Version 1.0b9 revises the zigzag sorting by providing check boxes to set zigzag sorting to random angles, aligned angles, or angles permuted in blocks of four. Formerly, the diagonals were always aligned. The default now is random angles (much better, I think!). This version also adds the scaledLowPass method, a low pass filter each RGB channel with a different FFT block size (64, 32, 16) for each channel. The component order depends on current Component Sorting Order setting, when the RGB channels are used. If you are using HSB channels, a random RGB order will be selected. Currently this command is only triggered by the ‘)’ (right parenthesis) key command. It works best when pixel dimension are multiples of 64. After it executes, you can immediately use the statistical FFT command (‘k’) to sharpen the image. Amazingly, most of the detail that was lost with the low pass filtering will be restored by the default statistical FFT setting (set by the command to operate on 16 x 16 pixel blocks). The command takes time to execute because it’s really a long series of commands bundled together. It was an experiment that proved very rich in the variety of images it could create. Here’s an example. There are also many minor fixes, the most obvious one of which is that you can now drag images bigger than the window without using the shift key.
Since version 1.0b7, a substantial update, GlitchSort has supported Fast Fourier Transforms on images. It also saves JPEGs using current Java libraries, instead of the deprecated com.sun.image.codec.jpeg. Version 1.0b8 fixes a bug in the audify command, and adds a “denoise” filter and spatial shifting of color channels: that was enough to justify the new version number.
Because of an unresolved memory leak in the PImage image cache in Processing 2.0b7, I released GlitchSort for Processing 1.5.1. Apparently the problem persists in Processing 2.0b8, so GlitchSort still works in Processing 1.5.1.
My own images created with GlitchSort2 can be found at http://www.flickr.com/photos/ignotus/sets/72157629445337238/.