Tuesday 29 May 2012

On the preservation of digital art

Preservation and archiving of digital assets - data and software - is a relatively straightforward process that we all regularly partake in, backing up onto some kind of persistent media such as DVD's, USB drives, hard drives, tape, et al.

Alex May. Photo by courtesy of Alex May

Unfortunately, these mediums will all degrade over time, requiring either regular refreshing by copying from the old media to a new set of media, or generating of new, updated versions. Should we want to preserve these assets for a much longer period, say centuries - and this is can be an important concern for curators and collectors of digital art - we might need to look at more durable mediums.

A common suggestion is to write it out on traditional media such as paper, or clay tablets, or even carved into stone. Artist Marina Abramovic is creating an institute for the preservation of performance art in Hudson, New York. Part of the institute is the Digital Temple, which will have spaces for the preservation of digital data to be engraved onto the marble walls, anticipating an explosion that could potentially wipe out all data on the planet. There doesn't seem to be any specific agreed method for how the data should be represented, however. Just writing a stream of binary values (or decimal, or hexadecimal) is too abstract in that it doesn't inherently contain enough information of how to go about decoding what it represents.

One of my favourite responses (albeit oblique) to this question was from a thread on Slashdot that made the suggestion that if someone (an artist) is concerned with longevity, they should perhaps work in a less ephemeral medium; you don't see ice-sculptors requiring buyers to have refrigerated galleries.

As an artist working with light and code, I have long come to terms with the fact that my art doesn't physically exist. For my own work to be preserved, I have to be fastidious about the delivery and physical relationship of the artwork to the viewer. While archiving and preserving data is relatively straightforward, should you want to access the data or execute the software, the requirements suddenly skyrocket. We need knowledge of the format of the data, which makes it possible to directly access or migrate the important information contained within the data to a contemporary format, and some kind of compatible hardware or software for execution of software.

Emulation of digital systems is seen as the current best practice for digital art preservation. The virtualisation of operating systems can be seen as emulation of contemporary hardware. There are some attractive aspects of wholly developing under a virtualised system: your system has emulation support baked-in. The downside is that virtualization works by presenting the operating system with a simplified or lowest-common-denominator version of the hardware. You can access external devices via USB, but you will often lose out on the advanced features of your graphics card and/or audio card.

I spent many years writing code on the Commodore Amiga in the late 1980's and early 1990's. The most adventurous project that I undertook was writing (what I a friend and I had considered to be) the ultimate in bulletin board software. If you've never used a BBS (they were mostly killed off by the introduction of the Internet to the home), or indeed an Amiga, you will understand that having spent over three years of hard work that was ultimately useless, resulted in a somewhat militant attitude against closed computer systems.

Take Apple. You're not legally allowed to virtualise OS X, or run it on any hardware that isn't made by Apple (although both can be done to a useable level thanks to some clever programmers). However, you can legally virtualise and store away copies of most editions of Microsoft Windows or any (all?) of the flavours of Linux. Both operate brilliantly under virtualization. If I want my code to run under emulation far into the future, and stay legal, I shall be choosing either Windows or Linux.

There is one aspect of emulation that still remains challenging: the physical experience of the software. While the amazing MAME can present you with a pixel, colour, and timing-perfect rendition of Space Invaders, it is being presented to you in a different format and context than its original. Most arcade games lose a great deal of urgency and reward when you remove the element of a financial transaction. Knowing you can play for as long as you like from the comfort of your armchair quickly diminishes the enjoyment of the game itself. Short of buying an original arcade machine, it is possible that you could build your own replica Space Invaders cabinet with a computer running the emulator inside, thanks to a considerable effort of documentation.

This additional dimension of incorporating some kind of physical and/or spatial presentation is an often overlooked element in the preservation of digital assets. While it is possible to store a working version of the software, the presentation of the output of that software also needs to be done correctly in order to truly represent what the artist wants to convey. If the work cannot be shown correctly (whether for site-specificity, or for technical reasons) then you're going to be better off focussing on doing an excellent job of documenting the experience using easier-to-store media such as photo/video/audio, rather than trying to recreate it.

David Lynch was famously asked what he thought about people watching movies, especially his, on their mobile phone. He starts with "You will never, in a trillion years, experience the film. You'll think you have experienced it, but you'll be cheated." and then he gets rapidly angrier from there. Art that is able to be accurately disseminated digitally has a powerful capability of sidestepping the traditional gallery and museum controls, and make itself available in a version that can be experienced by anyone with an Internet connection. This has fostered a whole arm of art: Net Art.





For video-based work, the Internet has given rise to powerful new distribution channels such as YouTube and Vimeo that host a great deal of new art, but at the same time, the presentation of the video is out of the control of the artist. Neither site has an option to force a viewer to watch it on a professional projector with certain technical requirements, projected to a specific size on a quality screen. Watching it on your laptop in a busy cafe, or Lynch forbid, your phone, cannot possibly have the same experience for the viewer. Artists must be conscious of the choice they are making when allowing their work to be viewed outside of their control.

There is a parallel between how the formatting of written content was very controlled in traditional print, but when delivered online required a trade-off of limited control over layout, pagination, and formatting in order to maximise its reach to a worldwide audience. If you want to use the Internet to disseminate your work, you have to give up any control over its presentation. The world wide web was not designed by artists.


Successful access

It becomes apparent that should we want to preserve digital art, we require all of the complication that arises from general digital archiving: storage, data readability, system emulation, and also details of how the work is to be presented, preferably with photo/video/audio recordings of the piece in situ at some previous time. It is surprising how few digital artists are actually programmers, although one might argue where to draw the line if they did some or all programming for a certain project. The popularisation of higher level languages such as Python and Java, coupled with a wide range of high-level libraries and development environments designed specifically for artists, allows anyone who has some concept to start playing around with digital concepts.

From an archival point of view, the high-level nature of these systems requires a great deal of support code, usually from a variety of different sources, that the artist might not be aware of. In order to successfully archive a work, these libraries all need storing along with the host software and the code of the piece itself.

Artists also like using external peripherals as part of their digital art. Hardware such as video projectors, Kinect, Arduino, and most recently the Raspberry Pi, open exciting new conduits for artistic exploration. An artistic project might use one of these, perhaps several, or even perhaps an unwieldy combination of all of them. They need to be archived as part of the artwork for it to be preserved.

There are various techniques that, as a programmer-artist, I have developed over my career which have helped me out. If possible, create your artwork in a virtualized environment. I use Oracle's VirtualBox to create installations of Windows or Linux that I deploy my art into. If it works then I have a single, replicable system image that I can put on any PC (as long as it's of minimum requirements) and it should work.

Deploy your art onto a clean system, then record all the dependencies you have to install. Don't upgrade this system if you want your art to continue to work.

Use a software versioning system for all your digital assets. I used to use Subversion, now I use Mercurial. Many people use Git, and there are others. Don't get drawn into the rampant online arguments of which is better - use what works for you. When I'm working on a new piece, I will often save a new version every time I create an aesthetic effect I like, even if it's not the one I'm looking for. I didn't used to do that, and I lost some pieces that never got to see the light of day. Save a new version at least once per day.

When programming, disconnect the stages of your software as much as possible. For instance, there are several API's for the Kinect, and there are lesser-known hardware alternatives. If you hardwire the use of a particular Kinect API too deeply into your code, you will end up having to rewrite your code to support a new API or device the future. Think of it as a stage that delivers an RGB and Depth image (and sound, if you use that), and pass those buffers to the next stage in your code. With some luck, you won't have to make major changes to your code that processes these buffers should you decide to use a new interface.

And obviously: document your work. If you're not spending at least as much time and effort on documentation as you are creating your digital artwork, then you're just not doing it right. Wish I could follow that one...

I used to write code with the primary aim of actually working; the secondary aim of being extensible and flexible; and the tertiary aim that it would work and be relevant for at least five years before needing to be replaced. As a digital artist, I now try to write code that should last for a hundred years or more. I don't think of it as egotistical. I see it as a technical challenge.


Alex May is an international digital artist working with light emitting technologies, computer programming, math, power tools, and physical objects as a canvas to create hybrid collisions of images and unexpected context. His work uncovers and explores new artistic mediums that offer joyful extensions of the human experiences at best, and darkly invasive and upsetting self-reflection as its shadow. Alex is a visiting research fellow: artist in residence at Hertfordshire University and head of Projective Geometry at The Institute of Unnecessary Research. His first computer was a Sinclair ZX81 that didn't work properly. www.bigfug.com

Twitter, Facebook
Terms & Conditions, Privacy, Cookies