Archive for the 'processing' Category

Processing Time May 2nd

Friday, April 3rd, 2009

In May 2nd, Nick Montfort is organizing a coding event called Processing Time as part of the Boston Cyberarts Festival 2009. The idea is for people to gather in the MIT Center for Advanced Visual Studies and join a competition to write programs that display clocks onscreen using Processing. The event is open for participants and spectators alike. Nick commissioned me to make a poster for the event, which I mysteriously envisioned in a nifty Watchmenesque style.


No code was written to design this poster.

Tiny.magnify(11,7) + Line

Sunday, September 10th, 2006

You don’t move your mouse across the screen even if it feels like you do. You move your mouse across the table, or your desk, or something equally flat. The computer translates the mouse positions into integer coordinates that best fit the screen. Some positions might not be read, and gaps will manifest as the computer screen renders the path you scribbled. What your perception feels like the continuous motion of your hand will be translated into a scattered rain of tiny squares. I have recently been working on a prototype application for making short animations spawned by the Tiny icon drawing application. It immediately became evident that a 13×13 pixel canvas will never give me enough of a surface to reach the basic functionality I am looking for. I want my animation application to be as limited as possible, but I must deliver enough flexibility to let an experienced animator illustrate the basic principles of animation with ease. 13×13 pixels are just not enough. Something like 143×91 would be fine, if Tiny’s rudimentary drawing tool was to survive the resolution increase. But it didn’t. It felt like a pen that was running out of ink. As much as I dragged my mouse all over the canvas, it would spit a sequence of dashes instead of a line. I would have to squiggle really slow to get a continuos flow of pixels. An easy solution to the problem would be to catch all pairs of consecutive mouse positions, and device a procedure to approximate the line between them with new pixels. A couple of years ago John recommended me an excellent technical book written by dutch professor Leen Ammeraal entitled Computer Graphics for Java Programmers, and I remember the description of a pixel line algorithm at the end of chapter two. I told Brent about it and we engaged in the task of recreating it from scratch. It was a perfect activity for what we call PLW Basic Research, an initiative that aims at discovering (or rediscovering) basic non trivial things. An important constraint we forced on our design was to solve it with integer arithmetics. Some interesting ideas were found in the process. One of them is here. It features our working algorithm, scalable pixel resolution on the fly, and a random color switcher. The principal obstruction of this experiment is the lack of control, because it is impossible to guess what color to expect next. Our algorithm was very close in spirit to the classic Bresenham’s Line Algorithm from 1962, one of the first computer graphics algorithms of history, and the main difference between them is that our version doesn’t work as well as Bresenham’s.

bersenhamgray2.gifbersenhamcolor.gif

Obstructions 101

Tuesday, August 29th, 2006

Is there a better obstruction for drawing than a 13 pixel canvas and a black and white binary/boolean color palette? I guess not. While working on our collection of smaller than life icons, Brent and I realized Photoshop was not giving us what we wanted and both ventured on building our own Tiny drawing application. Brent’s version is written in Ajax and embedded in a Rails application that already lets you load and save icons online. Mine is a functionality rich Applet that will eventually talk to Brent’s Rails repository for saving. It features an invert function, several previews in different scales, and an optional grid, all meant to enhance your understanding of such a meaningful art form. Our custom data format is a 169 character string of 0s and 1s. Longer than my attention span in a very good day, it will not fit my layout (or your browser) unless I shrink it or break it. After breaking it 13 times, the source of a typical Tiny drawing looks like this:

0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 1 1 1 1 0
0 0 0 0 0 1 1 0 0 0 0 0 1
0 1 0 0 1 1 1 1 1 1 1 0 0
0 1 0 0 1 1 0 0 0 0 1 1 0
0 1 1 0 1 1 0 0 0 0 0 1 0
0 0 1 0 1 0 0 0 0 0 0 0 1
0 0 1 0 1 0 0 0 0 0 0 0 1
0 0 0 1 1 0 0 1 0 0 1 0 1
0 0 0 0 1 0 0 0 0 0 0 0 1
0 0 0 0 1 1 0 0 0 0 0 1 0
0 0 0 0 0 1 1 1 1 1 1 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0

If you stare at it long enough, you will get a headache, and you will almost see the drawing:

tiny1.png

I Draw Too

Sunday, August 27th, 2006

the journey is the destination. dan eldon

I have been experimenting with ideas on how to build a simple drawing application. I am putting aside my technical limitations by concentrating on the pure action of drawing and it’s relation with the computer. I am looking at two components of the drawing activity that i find equally important: the process or experience of drawing, and the product or final image. I am adopting a methodology based in the setting of obstructions, inspired by the Danish filmmakers Jørgen Leth and Lars von Trier on their 2003 therapy-documentary film De Fem benspænd (the five obstructions). Based on a short film directed by Leth in 1967 called Det Perfekte Menneske (the perfect human), Lars suggested him to recreate the same film five more times, giving him a set of different technical/conceptual restrictions each time. Obstructions would provide a framework for the artist, defining what he could do in terms of what he couldn’t. It is a well known procedure in philosophy to define the space of a concept by measuring the boundaries of its negative space: I don’t know what this is, but I am certain it’s not that, or that or that. This is the reason why Jørgen found it really disturbing when Lars gave him the obstruction of ultimate freedom on his third assignment. It was too much freedom! Commercial graphics applications try to deliver the illusion of freedom in a very odd way. First, they almost remove the potential confrontation of the user with the act of drawing through a series of predefined objects and procedures, and second, they pretend to eliminate errors by delivering the famous undo command (probably the most used computer-only action added to the creation of graphics, an action that actually removes the effects of an undesired action from happening at all). The undo, although a very practical feature all of us have made profit from so many times over the years, might not have much of a place in the realms of experimentation and learning. Sometimes it is by fixing a mistake with the same tool that caused it what leads to a new form. Graphics applications make it possible to standardize graphics into a purely manufactured realm where everything looks just neat, and just the same.

drawtoobeans.jpg

The first general obstruction will take the mouse for granted (or trackpad or pen-and-tablet if you want) as the standard device to input the human gesture of drawing into the computer. It makes sense, because it’s relation with space is very similar to that of the pencil, or any other traditional drawing tool. The selection of this devices immediately forces a first fundamental difference between virtual and real: the resulting shape will not be rendered in the same place where the drawing has been made. Your eyes will not be looking at your hand as you draw.

idrawtoo_0a.jpg

The second general obstruction is to forbid the existence of the undo command. An action shall be an action. Once you did it, you have to live with it, and try to fix it if you regret it. You can delete the object you don’t want, or splatter something else on top of it until it disappears from your sight, but you will not undo. The rest of the obstructions, all of them particular, lead to different simple prototype sketches, that I am using to test and filter potential ideas. I will call the set of these Obstructions ProtoDraw (from first, anterior, primitive, original… um, drawing). My first couple of examples for subsets of ProtoDraw can be tried online as Processing Java Applets. Processing is a graphics programming environment that makes it easier to prototype sketches for systems and applications that heavily rely on graphics and interaction. DrawToo explores the integration of the keyboard into the drawing tool, enhancing the expresive potential of the stroke and giving the remaining hand (left or right) an active role in the process of drawing, without compromising the centralized one point in motion nature of drawing. As an obstruction, it means you can’t use the mouse events for anything but drawing. The rest will be the keyboard’s realm. Ink is affected by the importance of time both as an influence on the perception of the materials and as a tool itself. In general, graphics applications respond inmediately to the user when an action is chosen, but the response to the user’s command could also be meant to happen over time, giving the user a chance to understand his requested changes in a deeper way. As an obstruction, Ink means to force action on the setting of parameters such as color, or stroke weigth. Instead of being one mouse click away as usual, the selection of a certain color will involve a process of figuring out how to build that color, and a process over time that cleans the tool so it can be filled with the recently built color.

DrawToo:

small.jpg

Ink:
ink_ready_1.jpg