December 30, 2012

365 of 366

Processing + JPGs

Cycling through values of bytes 0x37, 0x7E and 0x011D using sinusoidal functions.

December 29, 2012
364 of 366
Processing + JPGs
Randomly varying byte 0x37 and byte 0xCD.  Animating the usable frames.

364 of 366

Processing + JPGs

Randomly varying byte 0x37 and byte 0xCD.  Animating the usable frames.

December 28, 2012

363 of 366

Processing + JPGs

Combining manipulations on bytes 0x37 and 0x011D

December 27, 2012
362 of 366
Processing + JPGs
Cycling through values of byte 0xC7 gave the frames of the animation above, as well as loads of files that Processing refused to load.

362 of 366

Processing + JPGs

Cycling through values of byte 0xC7 gave the frames of the animation above, as well as loads of files that Processing refused to load.

December 26, 2012
361 of 366
Processing + JPGs
Byte number 55 or 0x37 of a 640x480 JPG encoded at the highest quality using GIMP was sequentially stepped through all possible values.  This is a snip of 25 of those values.
Thanks to Ted Davis for insight into the technique of tinkering with JPG Huffman encoding tables.  This manipulation is performed on the first byte in the luminance tables.

361 of 366

Processing + JPGs

Byte number 55 or 0x37 of a 640x480 JPG encoded at the highest quality using GIMP was sequentially stepped through all possible values.  This is a snip of 25 of those values.

Thanks to Ted Davis for insight into the technique of tinkering with JPG Huffman encoding tables.  This manipulation is performed on the first byte in the luminance tables.

December 25, 2012
360 of 366
Processing + JPGs
After meeting Ted Davis (FFD8) and attending his panel with Paul Hertz at Gli.tc/h in Chicago earlier this month, I decided that I should get over my personal aversion to programming.
Using Processing, I’ve written a primitive (and probably poorly structured) program that will enable me to go through a file byte by byte and sequentially change the value of a particular byte.
The GIF above started as a JPG.  By stepping byte number 0xC4 (or the 196th byte in the file) through values 128 through 220, the alignment of the image raster was thrown askew.
Writing a program to proceduralize the restructuring of data doesn’t seem antithetical to the glitch ethos.  Though, somehow there’s a line that is crossed once that code becomes packaged and sold, used only for a particular effect, rather than extended further.  At that point, the process seems little different from the ritualized produce/consume (prosume) paradigm established by large “productivity” software firms.  For me, anyways, glitch has been about skirting the usual channels of productivity.  Creating your own tools is part of that.
Processing code

360 of 366

Processing + JPGs

After meeting Ted Davis (FFD8) and attending his panel with Paul Hertz at Gli.tc/h in Chicago earlier this month, I decided that I should get over my personal aversion to programming.

Using Processing, I’ve written a primitive (and probably poorly structured) program that will enable me to go through a file byte by byte and sequentially change the value of a particular byte.

The GIF above started as a JPG. By stepping byte number 0xC4 (or the 196th byte in the file) through values 128 through 220, the alignment of the image raster was thrown askew.

Writing a program to proceduralize the restructuring of data doesn’t seem antithetical to the glitch ethos. Though, somehow there’s a line that is crossed once that code becomes packaged and sold, used only for a particular effect, rather than extended further. At that point, the process seems little different from the ritualized produce/consume (prosume) paradigm established by large “productivity” software firms. For me, anyways, glitch has been about skirting the usual channels of productivity. Creating your own tools is part of that.

Processing code

December 22, 2012

357 of 366
Processing RAM Barf
A bug/glitch causes Processing to dump the contents of RAM into the window.  The appearance of my dock icons lead me to believe that this has something to do with the OS video ram buffer.

357 of 366

Processing RAM Barf

A bug/glitch causes Processing to dump the contents of RAM into the window.  The appearance of my dock icons lead me to believe that this has something to do with the OS video ram buffer.

December 21, 2012
356 of 366
Processing RAM Barf
When you make your output window as many pixels wide as your 2MB jpeg is bytes long, your computer might go nuts trying to keep up.  A nice bug/glitch in Processing caused my computer to dump its RAM into the output window.  This is a nice minimal abstraction of that data cropped out and enlarged.

356 of 366

Processing RAM Barf

When you make your output window as many pixels wide as your 2MB jpeg is bytes long, your computer might go nuts trying to keep up.  A nice bug/glitch in Processing caused my computer to dump its RAM into the output window.  This is a nice minimal abstraction of that data cropped out and enlarged.

December 20, 2012
355 of 366
Processing RAM Barf
A bug/glitch causes Processing to dump the contents of RAM into the window.

355 of 366

Processing RAM Barf

A bug/glitch causes Processing to dump the contents of RAM into the window.