I came up with a goofy idea that I thought could make a decent app. In furtherance of a typical modern, webby, agile agenda, I decided to “fail fast” and put together some barebones proof-of-concept to decide whether the idea was viable.
The idea: ASCIIgram
Think “Instagram” meets ASCII art. Take photos, convert them into ASCIIfied versions, and share them on Facebook. This meets my first test: I can describe the idea in one sentence.
My Secret Plan
I had no monetization plan for this app. It met all of my needs for a test project:
- Self-contained — the scope is small and manageable.
- Easy feature roadmap that could be instrumented for metrics (I was thinking “colorization”).
- Niche market — users who liked it would probably be fairly invested, but there wouldn’t be so many that maintenance would be a nightmare.
I decided that the minimum viable first prototype would be a web page that could accept a raw image and convert it to ASCII art. Why do the conversion on the web? If I made it to the mobile app step, I was hoping to leverage the Lua-based Corona SDK, as I’m a pretty hot hand with Lua and could stand up an app faster that way. I spent 3 days on a handful of prototypes, starting with a hard-coded little beast and moving up to the aforementioned upload-and-convert page.
I entered this project with only the barest minimum of previous experience with PHP, and none at all with Image Magick. Of course, I selected both of these technologies after a lengthy research session on Google, which I am completely exaggerating for artistic value, and the real reason is that my existing web host supports PHP easily. I managed to install and build Imagick and get it running happily under PHP. I got some basic image uploading / temp file pipelining and the like working, which was significant PHP learning for me. I even came up with a short, scripted series of actions that could transform an image into some kind of ASCII art. And here’s where my wonderful plans fell down.
The performance of my methods for converting to ASCII were miserable. In order to complete within a 30-second window, I had to cut the sizes of images I was working with enormously. Too much detail was lost at that point to get clean output images. I lost a whole day’s work to a math mistake, as I was accidentally matching to double-width tiles instead of single characters. In the end, I concluded that the PHP-based approach itself was fundamentally flawed; I’d either need to rely a lot less on Imagick and do a lot more full custom encoding/decoding/pattern-matching, or abandon my hopes of using Lua and instead learn Objective-C and do my own image processing on the mobile device. I’m not saying this wouldn’t, in the end, be a better plan, but it completely whiffed on my actual goals for the project.
Here are some samples of a source image and three types of manipulation: preprocessing with some edge enhancement, a “per-cell match” that attempts to match each 9×8 image “cell” to the best match from the adjacent 25 or so glyphs ordered by approximate brightness, and a “hybrid” approach that used a faster “randomized nearest brightness match” 80% of the time and only attempted to per-pixel image match 20% of the time. As you can see, while general shapes are recognizable, too much detail was lost in the downsizing of the source image to produce the quality output that would be necessary to get anyone using the app.
In the end, I still think the idea was entertaining. If I had a goal of doing some lower-level coding for this project, it could still have been viable — I bet another week would conclusive determine that one way or the other. But in the end, the project clearly wasn’t going to meet my goals, and now I’m setting the idea free. Ideas are easy; I have a half-dozen more I’m ready to start experiments with. Onward to more fast failing!