Glitch Art

While working on icodec I learned how to read an write .bmp files by hand. I then decided to try creating some glitch art — and data manipulation more specifically.

I started with the following .bmp file:

A green field with blue sky and clouds
β€œBliss” by Charles O'Rear (1996)

Here are some of it’s first bytes:

bliss.bmp

00000000: 424d 7a78 6900 0000 0000 7a00 0000 6c00  BMzxi.....z...l.
00000010: 0000 8007 0000 b004 0000 0100 1800 0000  ................
00000020: 0000 0078 6900 703d 0000 232e 0000 0000  ...xi.p=..#.....
00000030: 0000 0000 0000 4247 5273 0000 0000 0000  ......BGRs......

The width and height of the image are stored in offsets 0x12 and 0x16. By changing this values one changes how the pixel information in the data buffer is interpreted. Let’s try playing with it:

glitched.bliss.bmp

00000000: 424d 7a78 6900 4741 524b 7a00 0000 6c00  BMzxi.GARKz...l.
00000010: 0000 e005 0000 e005 0000 0100 1800 0000  ................
00000020: 0000 0078 6900 703d 0000 232e 0000 0000  ...xi.p=..#.....
00000030: 0000 0000 0000 4247 5273 0000 0000 0000  ......BGRs......
A hazy mess of horizontal strips forms a color gradiant ranging from vibrant cyan to white and then to lush green

The pixels of the glitched image are the same as the ones from the original picture, but they are misplaced due the manipulation we did.

Note that I placed my signature — GARK — at offset 0x06-0x0A. Those bytes are unused and can be set to anything.

One important detail is that the dimensions I used — 1504x1504, or e005 0000 e005 0000 in hex — are multiples of 4 whose product does not exceed the number of pixels in the original image.

If the product of the dimensions of the glitched image is greater than the number of pixels in the original picture the result will most likely be corrupt: there’s just not enough information in the pixel buffer for any program to read the image.