xagglut
=======

Apology
-------

Well, I could have picked an uglier name, but I couldn't think of one.

This program agglutinates globs of pixels on your screen in order to
draw a scatterplot with more spatial resolution than the input data.

The scatterplot plots pairs of characters from standard input.  This
generates an image dependent on the kind of data you feed it; I can tell
apart the following kinds of files from looking at the image:
- Word documents
- plain text files
	- Unix email folders
		- base64 MIME-encoded messages
		- uuencoded messages
		- ordinary mail
	- with blank lines or not
	- with uppercase letters or not
	- consisting mostly of numbers
	- strace output
- MIDI files
- PDF files
- x86 binary code
- mulaw audio (.au files)
- digitized CD tracks (you can even see the beat of the music!)
- random noise, such as gzip output
- and the one large .gif file I have doesn't look like *anything* else,
  but I don't know if all large .gif files look that way

In addition, the scatterplot decays as time goes by, so differences
between parts of the file will manifest as animation as the program goes
from one part of the file to the next.  On my machine, this program
ingests data at something like 130-180 kilobytes per second, about as
fast as a CD player.  (It took 203.34 CPU seconds over 276.99 wall-time
seconds to run through a 37768460-byte file and then wait for me to tell
it to exit.)  

To build
--------

You may have to change the XLIBS line in the Makefile to point to where
your X libraries live --- /usr/openwin/lib or /usr/X11/lib is likely if
it's not /usr/X11R6/lib as the Makefile assumes.  You may have to change
the CC line to point to your compiler if you don't have gcc.  If you
don't have X libraries and a C compiler, you're out of luck.  Sorry.

Then type 'make'.

To run
------

./xagglut < some-interesting-file

See the Apology for examples of interesting files.  You can learn to
pick out particular features of files rather quickly, I think.

Details
-------

It reads data from standard input, two bytes at a time.  The first byte
in each pair is treated as a row number from 0 to 255; the second byte
in each pair is a column number from 0 to 255.  The program tries to
turn the pixel in the specified location black; if it's already black,
it randomly looks around nearby until it finds a white location to turn
black, or gets tired and gives up after looking around for 30 pixels.

The actual data window is 610 by 610, which is noticeably larger than
255 by 255.  This yields some graininess.

After it tries to find a pixel to turn black, it turns three randomly-
selected pixels white.  (They may already be white.)  This means that
areas that are no longer being painted black will decay to white
eventually.

Internally, the code is pretty ugly.  It started out as a program to do
essentially the same thing on an ASCII terminal, which was exceedingly
slow.  I hacked on its various parameters until I had something I liked,
and then released it.

It uses a tiny library called 'xiafpos', included here, to make Xlib
less maddening.  xiafpos version 1 is included here; I added a couple of
features to it specifically for this program.  I released version 0 of
xiafpos earlier today with another program.