

Waaaaaaaaaaay back I wrote this java command line application that generated imagery from text. The idea is very resemblant of traditional ASCII-art but instead of representing tones by one character per value, it use elaborate transformations to transfer a tone mapping onto arbitrary text. Like poems, entire novels or even its own source code. Think of something like the binary rain that slowly resolve into images in the matrix movies, but still legible if you look really close. The matrix effect is actually made up by different shades of green which is easy to reproduce with adjustment layers in Photoshop. That was not really what I was looking for. I wanted solid text so I rolled up my sleeves and dug in. In a fit of poor imagination I dubbed the class Kwords, reflecting the old saying that one image is more than a thousand words. Not that cool, in retrospect.
At the heart of my application is an algorithm that apply scaling to vector glyphs based on the average greyscale saturation of a set of pixels in a reference image. Initial results were very promising, but some interesting problems arose. High-resolution images—that is images with very small text—were pretty impressive, but with increasing character size came declining clarity. The reason was obvious: an x carry more ink than a period, and scaling both to the same percentage will not change this relationship. So began an ambitious venture into the magical land of platform-independent computer typography. I had a vague conception that some sort of normalization had to be implemented and this involved examining every glyph of the typeface and compare it’s coverage to some reference area. The choice of reference is not trivial and must be weighted to desired maximum coverage, maximum achievable coverage and a bunch of other terminology I dreamt up just for the occasion. I was pondering all sorts of exciting issues like how to relate line height to aspect ratio; implementing a file format to store typeface data; how to negotiate line breaks and deal with white space; whether to apply statistical analysis to the input text; if optimal contrast could be determined from the image and if so, how available image processing algorithms are different from applying transformations to the spatial coordinates of the characters; if bipolar interpolation yield the same results as other methods of averaging multiple pixels over a glyph… Ultimately the big question was how does our mind make us perceive a continuous greyscale where there are only solid shapes? Perceptual psychology is an immense field. I needed to extract a working model.
Somewhere I lost track of all this and ended up with a monster of unsustainable mess. Classes instantiated at random to perform single operations that were already in the name space, other methods reiterating complex calculations with identical results, objects created en masse just to entertain the garbage collector. A virtual forest of circular coordinate transformations made predicting where individual characters were actually drawn a subject worthy of a master thesis and the application would crash unless passed the -Xmsn parameter and given access to the entire working memory, bringing the operating system to its knees and begging for mercy. Execution times were around 15 minutes to produce 40 mb .png files on my 2 GHz machine. It is inconceivable that this labyrinth of code is valid, and even more baffling that the results actually has some resemblance to specifications.

A new cup of coffee
Looking back at the source the only part I am really satisfied with is the textbook implementation of file access and image rendering. I’ve never managed to get over this feeling that if I can figure out the exact parameters that can make masses of text into shapes and write this program lean and mean it would be truly awesome.
I’m totally giving this another shot some day.
¶
Aeon: March 2, 2010
Dismissed as: Technorant
Tags: graphics, programming, projects
Comments: No Comments



















