michael lascarides

The images that I have been posting lately are screenshots of vector art images that are drawn by a program I created in the Ruby programming language. Ruby’s not a graphics language per se, but I love its syntax and its potential for creative code. To do the heavy lifting, I use two Ruby libraries to talk to other graphic formats: RMagick ties Ruby to the ImageMagick graphics program, and Ruby-svg does likewise for the SVG format. ImageMagick does basically most of what Adobe Photoshop can to bitmap images but from a command line so us programmers can have at it. And SVG is a vector format like Illustrator, but open source and in plain text, which lends itself nicely to hacking.

I have done my time with Flash, Lingo, and ActionScripting, and still like them for animation. But I’ve always been sort of a minimalist in my tools, and being able to do everything from a text editor is very appealing to me– I’ve been around long enough that I’m having trouble opening my Illustrator art files from a decade ago, but plain text never expires.

Ruby appeals to the minimalist in me too. I like the way Ruby code looks. There’s no need to end each line with a semicolon, parentheses can be omitted in certain contexts, curly brackets can be replaced by the words “do” and “end” (which I would have hated a few years ago because of the extra keystrokes, but today I dig for the readability). Eliminating all those extra bits and pieces leaves you with something that looks more like a language. Also, EVERYTHING in Ruby is an object, so things like numbers have their own properties out of the box. This means you can write something like

5.times do
(something or other)
end

So “times” is a loop built into “5″. Nice and clean.

All this means when I finally got Ruby talking to both bitmap and vector art, I was off to the races. I am working on a set of tools for analyzing bitmap files and creating vector files. In time, I plan to open their source and share them with anyone who cares to play, but for now they are just messy experiments.

I have been taking pictures for 15 years, and digital pix exclusively since 1998. For the last three or four years, I have developed somewhat of an obsession with a formal approach to surfaces, and have treated photography as a source for color palettes and textures, rather than a representational medium. As such, my experiments right now are taking photographs (both my own and those of others) and using them as the input to my programs. The current batch of images shown below can be thought of as heavily filtered photos turned into line art. I’m working on a bunch of variations, but the underlying theme is this: move to a point over the bitmap, see what color’s underneath, draw a shape (usually a circle) based on that color (but possibly making a variation of some sort), then move to the next point on the grid. When the whole surface has been done, change the size of the step between grid points, and repeat again. And possibly again. And again…

Some interesting things start to happen in this process. First of all, a smudge of pixels now becomes a laser-precise circle of color. Second, the new shapes are described as vectors, so I can print them or blow them up to any size without distortion; they are meant to be printed. And finally, the shapes have their own characteristics: a circle can have an outline, the outline can have a thickness, it can be opaque or translucent, maybe it’s a square, not a circle, it can be big, it can be small… you get the point. Lots of VARIABLES.

With the variables in hand, the fun part is just to repeat. And repeat. The image below contains 29,906 perfect circles of various diameters, thicknesses and colors. If I showed you the photograph from whence it came, you’d see the relationship, but that’s not my intention (in fact I see resemblance to the orginal as something to be avoided– more on that some other time). Together, all those little perfect circles start generating a weird mathematical resonance that teeters on the edge of, but never falls into, chaos.

#162

#162, detail