Sol LeWitt never used a computer but the loose idea of a program is inherent in his approach and it was this that inspired our initial thoughts for a very special project we had been asked to work on. Back in September, Team Spam had been approached by the Centre Pompidou in Paris to propose an installation for their second edition of La Fête du Code. A family event aimed at demystifying the art of computer programming as well as showing how artists are working with code as an expressive medium in their practice today. This is a two/three part article revealing a little of our process.

Our main objectives for this project were the following. Engage the public in a fun activity that would enable them to understand a little about how a computer program works. The challenge was in getting to the essentials of that question of what a program is and does, all the while keeping the participants active in a simple process that all ages could associate with. Our initial ideas revolved around LeWitt’s work. It seemed an ideal reference point from which to develop our proposition. LeWitt’s formal descriptions of an artistic process makes for a strong link with the logical aspects of writing computer programs and their use as a medium for visual expression.

“The artist conceives and plans the wall drawing. It is realized by draftsmen ; the plan is interpreted by the draftsman... The artist must allow various interpretations of his plan. The draftsman perceives the artist’s plan, then reorders it to his experience and understanding... The artist and the draftsman become collaborators in making the art.”

Sol LeWitt. Doing Wall Drawings. 1971

This text served as a point of departure for our research. What LeWitt calls the ‘plan’, we call the program. That is perhaps clear, however we wanted to turn things around a little and question the role of the artist and the draftsman from the opposite perspective. Our proposition revolved around giving the role of the artist to the public and the role of the draftsman to SAM the machine. That was our little twist to the SOL n’ SAM episode in thinking. In the end, we didn’t push for making that an explicit part of the installation. It was however an underlying axe of thought and one for which a number of adults made comment during the event. We were happy to see in the end that our proposal could have different levels of interpretation and provoked some thoughts around the man vs machine debate even if it wasn’t the main proposal.

So, we had our intentions laid down and an interesting set of ideas to evolve from. It was important for us to propose something that made sense and at the same time was a pleasurable experience for all. On a practical level though, what the hell were we going to be showing and proposing to the public ? The answer to that came through a slow iterative process of testing, experimenting and sharing in good ol’ conversation. The crux of the matter was this. A computer program is a formal set of instructions, written by the human for the computer to execute. You can see it as a game, with a set of rules or a puzzle with a set of plausible solutions. We had to imagine something that brought all those together and it happened in quite a wonderful manner. That is to say, when you are searching for ideas, share them amongst those who are attentive and there will always be something that emerges from that process of exchange if you are listening. For us, it was a remark on a set of visuals we were showing in a presentation. “That’s nice, reminds me of those join the dot pictures I did when I was a kid.” We flinched, there it was in a nutshell, a flash of inspiration for an idea to be developed.

Research doc - Team SPAM

How do you make join the dot diagrams? Why d’ya ask? Well, for us, this is a really simple, visual and fun means of getting across the idea of a program. It is a program, a plan, with a formal set of instructions that can be understood by anyone. This became the principal idea, further more it fittingly made sense with how SAM works - receiving a list of points and a set of instructions that tell it to join those points. The idea takes shape, yet the question remains; how do they make those damn things, furthermore how would one go about generating these on the fly with a dynamic computer vision system as the input?

Dot overkill ! Image on right is a detail - Team SPAM

Off down the long trail of meandering paths on the tinkerNet, we adamantly searched for any information about technically going about that task. Not exactly a well documented activity apparently. Two papers - yes, actual academic papers - surfaced from amidst the pages of ‘free printable dot to dot worksheets’. A master’s thesis, Connect The Closest Dot Puzzles’ written by Tim van Kapel, 2014. Which is perhaps the more technical of the two. We particularly liked the other paper, ‘The Connect-The-Dots family of puzzles: design and automatic generation’, written also by Kapel in collaboration with five other authors. These two papers were little gems for elucidating a number of issues, one of which was the ‘Polygonal Line Simplification’ 1 algorithm which enabled us to reduce the number of dots for generating the final diagram. There were also some clever insights in how to graphically represent such lines, not necessarily relying on a sequence of numbers either. That was a vital nugget of information in the end, because we dropped the numbers for the installation. They were visually too dense in places and just added noise.

Once we had some vision on this we had to quickly start prototyping some working programs. We also had to figure out how we were going to analyse the image. OpenCV was a possibility we looked into but only briefly. We actually ended up coding a canny edge detection program from scratch, using code from Robert Sedgewick’s Edge Detector in java and some help from this brief yet concise introduction. We got some sweet results from this and indeed we pushed the exploration right upto the last minute, before finally resting on Julien Gachadoat’s robust little blob detection library. A big shout out to the man from Bordeaux for giving us a guiding hand in that part of the technical development. A thank you also goes out to Sebastien Courvoisier who provided us with a nice implementation for the line simplification algorithm, for which we had explored three : Simple, pulled from Thomas Diewald’s blob library, a radial from a js implementation and the Ramer Douglas Peucker algorithm.

Test output. Counting dots with Duchamp's L.H.O.O.Q. - Team SPAM

The majority of the software development resided on getting all these aspects to work in a dynamic system whereby we could capture participant’s faces/portraits and generate from this a printed version of the join the dot diagrams. We did this in stages, working first of all with static images. Pompidou had asked us to generate some dot to dot diagrams for five of their masterpieces from the collection. Their idea being to present to children a fun means of talking about portraits within the museum. This fitted in nicely with our pedagogical intentions and made for a coherent link to our installation piece. So we set down to testing our little program on static images before moving onto incorporating a camera for live action. More about this and finer details on the actual installation setup to come in part 2.

Dot diagram generator prototype - Team SPAM

What have we learned ?

A shit load ! Far too much to mention here. A little advice could be shared though. Ideas come with active exchange with others. More to show and tell in the next episode of SAM@BoBo... to be continued.

Program interface for SAM - Team SPAM - 2017