Interesting CMYK instead of RGB....

Yep, since we are looking at subtractive color (starting with a white surface, and coloring certain areas to reduce the visible spectrum in those areas), CMYK is the relevant model. Of course, we could also assume a black canvas, where we "turn on" colors in certain areas; in that case, RGB additive color would be more appropriate.

The process is currently several steps:

1. Tweak the image, to make it grayscale (if it isn't already), and sometimes to increase the lightness and contrast.


2. Execute an algorithm which places a certain number of individual points on a new (initially blank) image, so that the points capture the essential elements of the original image. For insight into what is happening in this step, imagine that each pixel in the original image has a weight, and a darker pixel weighs more than a lighter pixel (a white pixel has no weight at all). Now, imagine that you are going to lay the original image out horizontally, but instead of laying it on a flat surface, you are going to support it with thousands of pins. You want to place these pins so that the total weight is very evenly distributed among the pins. The placement of these pins is analogous to the placement of the points in the second image. (I used 7,500 points for the image of Kent, and 25,000 for Matt's image.) Right now, I have implemented this part as an ImageJ plug-in (ImageJ is an open source, Java-based image processing program), which can take several minutes to execute, for best results. (In the case of Matt's pic, it took about 20 minutes to run this step; Kent's pic only took about 5 minutes.)


3. Run the output through a program called Concorde, which finds a nearly-optimal solution to the Traveling Salesman Problem defined by the set of points produced in the previous step. This also takes several minutes. (For the image of Matt, this took 20 minutes or so.)


4. Convert the Concorde output into a Structured Vector Graphics (SVG) file, which can be viewed in browsers, opened in Visio, etc. This part is currently automated by a program I have written. (Bob has also written a converter for this step, which spits out EPS.)


5. If a raster format is needed, render the SVG at the desired resolution (which might be larger or smaller than the original image), and convert as appropriate.

For a computer with Concorde installed, pretty much all of the above could be packaged into a PhotoShop (or ImageJ, for that matter) filter. Without Concorde, the algorithm that does step #3 could be rewritten in a filter, but it wouldn't run as fast (Concorde is the end result of some pretty heavy-duty thinking). In the end, a lot of the work is iterative. You might repeat steps 1 & 2 several times before you are satisfied with the set of points produced; even then, you might get to step 4, and not like the result, and go back to step 1 or 2.

Post edited by: nickbenn, at: 2006/05/25 01:57

Tony, do you have a high-res version of T20.jpg? That's one in the gallery where you are playing Zendrum, with your head bent down slightly, against a light wall background; I think that one would work well.

Here is what I was able to do with the version of T20.jpg that you have in the gallery. As you can see, cropping to the small piece that works best with this method means there isn't much resolution to work with, to guide the process of selecting the best set of points to represent the image.

How would a high resolution version of this one (tony.gif) turn out?

http://www.zentherstick.com/index.php?option=com_gallery2&Itemid=26&g2_view=core.ShowItem&g2_itemId=140

That would probably work pretty well, but people who don't know what a zendrum is won't have the faintest idea what you are looking over (I guess that would happen even with a photo, though). If the the cropped area is 250 X 250 or larger, we should be fine.