Glitch Art
A glitch is an error or a bug and Glitch Art is about finding pleasing or challenging images due to those errors. Deliberately creating these images is often referred to as databending and is usually the result of opening media in an inappropriate application or editing the file incorrectly.
This site has a brief introduction to creating Glitch Art in Linux by manually editing the image as a hex file, as well as galleries of my attempts to create Glitch Art.
More About Glitch Art
Originally, Glitch Art was simply the discovery of random errors or bugs that happened to create images of interest. Latterly, deliberate attempts to produce this art, either with the appearance of a random result or with a specific end in mind, have produced more Glitch Art.
Over on the StAllio's Way blog, you'll find a great introduction to Glitch Art including a primer and details of The Wordpad Effect. In brief, The Wordpad Effect is the result of opening a .bmp image file in Windows Wordpad, re-saving it and then viewing it as an image. Wordpad's attempts to convert the image data in to .rtf format create the sort of results seen in the header for this web site.
| ORIGINAL |
GLITCH |
 |
 |
Though you can run Wordpad in Linux (with WINE or running Windows in a virtual machine), you can't get the same effect with Linux editors/viewers. Given the explanation provided on the site, I decided to skip the actual Wordpad bit and do the work in a hex editor. You can see my early attempts in the first gallery on this site.
Hex Editing Images
Computers don't work in decimal, they work in hex. Hex uses the numerals 0-9 and then the letters A-F (the hex equivalent of 10-15). Two hex digits make one byte, from 00-FF (decimal 0-255).
Put simply, this is what The Wordpad Effect does to an image:
- Replaces 07 with 20 (a space)
- Replaces 0A, 0B and 0D with 0D 0A
(The extra bytes are what skews the image to the right.)
This only works (consistently) with .bmp and .tif files; other image formats use compression, which makes the files less robust when messing with their bytes.
All image files (indeed, all files) have header information that states the file format/image size/etc so that's the first information you'll see. The first two bytes are the image format (42 4D for bitmaps).
Some files, including bitmaps, store the image as a series of RGB (RedGreenBlue) values for each pixel, this information is usually stored in order from top-left down. Adding extra bytes after the header will push the colour values off and produce colour shifts (see the Tardis images in the Early Attempts gallery). To keep things nice and simple, .bmp colour values are actually stored BGR, from the bottom-right up and after a much longer header than most image formats.
Other files, including some .tif images, store the image data as three separate channels, one for each of the colours (red, green, blue). So not only do you need to know where the header finishes, you also need to know where each channel begins. This also means that each channel will get its own glitches if each colour is independently out of alignment. Tinkering with this will give you the sort of trippy results shown in the image at the top of this page.
Find/Replacing 0A, 0B and 0D with 0D 0A will glitch the image as above but, if you want to control the effect, you need to calculate the range of bytes that you want to alter and make the necessary changes there only. You need to ensure that you maintain the same number of bytes so the image doesn't skew and, if it uses colour channels, you need to make exactly the same changes to each channel.
More...
| 
