Non-Destructive Image Editing and Git

One of the hot topics at the Lbire Graphics Research Unit Co-Position meeting came from the Visual Versioning work session. The work session focused on creating mockups for ways to improve their Visual Culture Git Viewer.

OSP Visual Culture Git Viewer

This tool goes some way to addressing the issue of not being able to visualise the contents of a repository by providing thumbnails of the contents. One of the functions missing from this tool is the ability to compare and merge different versions images. Github already provides the ability to compare still images (.jpg .png etc) in various different ways:

Image view modes

However, this is only a way to compare the output of the program. How could revision tools work with PSD/XCF, SVG or SLA files that contain more information such as layers and tools used to complete tasks?

Non-Liner Version Control in GIMP

A team of researchers has attempted to address this problem, at least in GIMP. Their work demonstrates an extremely effective way of doing version control from within GIMP

The research surrounding this tool is available to view and hopefully it’ll one day be implemented into GIMP. Whilst this solution is very effective and address every problem mentioned so far, it creates another problem: It is tied to GIMP and is not easily transferable to other programs. Trying to apply this to other programs such as Scribus or Inkscape would require extra resources, which are in scarce supply. Essentially what is needed is a program-neutral solution that would require few additionaly resources to implement.


Almost all modern programs allow you to undo your actions. When you look at this with more detail you begin to see that undo is a (highly unsafe) method of revision control. By using Ctrl + Z and Ctrl+Y/Ctrl+Shift+Z you can scroll through previous states of a file. All of the data surrounding your use of the program, such as what tools you have used, what files you have opened and possibly even the time each action was executed, are being recorded in the undo history. One solution proposed in the work session was to devise a way to capture and record this data. By doing so you could “play back” the file through each of its stages. Once you have this data you could then begin to build a standalone tool that operates in a similar way to the GIMP revision control tool

Edit Decision List

A very common way in which people implement their own version control system is to create numbered revisions of their files. For plain text files this presents few problems, but for binary files (PSD/XCF etc) it could mean that you have many large files which present a whole host of problems around bandwidth and storage space. Ana Carvalho and Ricardo Lafuente, who produce Libre Graphics Magazine with ginger coons, revealed that the repository for the magazine – including previous issues – has reached 8GB.

The solution proposed at the work session would address this issue as you would only need one copy of the original files that you work from. The “undo data” would be captured to a separate file that would then simply apply those actions to the file.


GEGL, which is the new core powering future versions of GIMP is, to my knowledge, already working in a non-destructive way. Peter Sikking, the lead interaction and UI designer for GIMP, has more to say on this topic.

Blender node editor by Dykam

Users of Blender and other node-based compositors will already be familiar with this approach. Effects are chained together in a non-destructive and then sent to an output file. As Pete Sikking describes:

If the structure of [the] graph is written to a file—apart from the input images, all other boxes are just snippets of XML—and a year later it is re‑opened in GIMP, then each of the operations and their parameters; each of the vector shapes or text can be freely changed

If the time can also be recorded then you could essentially reconstruct an image using nothing but the input files and this XML file.

Next steps

Of course, at the moment, all of this is theory and ideas which, in some ways, was the purpose of the work session. For this to be taken further what needs to be done is to first find a way to expose the data that is saved in the undo states. If this data is useful then the next steps can begin. Then, if it looks like a viable solution, all that is needed is developers willing to take on the task.


My thanks go to Constant and its many partners for organising for Libre Graphics Research Unit and to those in the work session – Ana Carvalho, Eric Schrijver, Ale Rimoldi, Gijs de Heij, Thomas Laureyssens and Camille Bissuel – whose ideas this blog post contains, along with some of my own.

Notes on Notes on Glitch

Hugh S. Manon and Daniel Temkin recently published a great paper on glitch art called “Notes on Glitch“. It reads more like a collection of thoughts than one concise paper, but it’s still an awesome read.

Glitch Safari (from myself and noteNdo) and Dataface both receive a mention in the gallery, along with other awesome works.

Out of all of the notes there were a couple of points that stood out to me, which I’d like to add my own thoughts to.

24. At the same time, because glitch artists may optionally “save a copy” before making alterations, there is something disturbingly low-stakes about any particular attempt at glitching. One wishes this were not so, since the appearance of glitch is highly untame. Driven as it is by limitations of all sorts, many of the most agitating examples of Modernist art—works which, in Susan Sontag’s terms, “overstrain” the medium7—would never have existed with an undo button at their creators’ disposal. Indeed the art historian of the future will recognize the rise of unlimited, one-click “undo” as being on par with the most major technological and phenomenological changes in the history of representation.

At GLI.TC/H 2010 Riley Harmon introduced me to the game lose/lose from Zach Gage. In this game destroying an alien results in a random file being deleted from your computer.

lose/lose from zach gage on Vimeo.

Insectoid recording session

My intention with this shot was to document the day accurately but instead I got a glitched photograph (the error occurred within the camera). Luckily, I received a positive response from AAS and others, so I decided to keep it. Had the photo been of more importance – for example, a picture of a wedding – then greater emphasis would be placed on producing clear, error-free photographs, and there would be greater disappointment and distress if any errors did occur.

So, intention comes into it quite a bit…

49. Glitch has embraced the open-source mentality of sharing knowledge, which is rooted in the DIY tradition of punk. When a glitch artist refuses to reveal how work was made, it not only raises a question of whether it is “really” glitch—as opposed to a Photoshopped simulation—but also whether the artist is selfishly hiding their technique in a refusal to contribute to the collective knowledge. This all reflects an anxiety over authenticity and the underlying politics of glitch—something not strictly defined, but which favors cooperation and community over the proprietary motivations of any individual auteur.

My practice is deeply rooted in open source software and collaborative practices. As such I always endeavour to share the source-code to all of my work. This doesn’t always happen immediately, but I eventually often write a tutorial, explain the process behind the artwork, or package the code that created the artwork into something reusable. As a result, I don’t look favourably upon (glitch) artists that are very secretive about their methods.

With that said, I do not want to become a help-desk for those wanting to do glitch art, which unfortunately has happened a lot in the past. Circuit bending and glitch art are very much about discovery, and I feel that holding someone’s hand and taking them through the A-Z of glitch wont result in an artist discovering their own style or reasons for doing glitch art. Tutorials that I write on my site aren’t meant to be a definitive guide on how to glitch, more of a starting point for the artist’s own personal discovery.

There’s more I could say about many of the other notes in that paper, but I’ll save that for discussions over dinner 😉

Where does it all go wrong?

I recently turned on the TV to find that the channel it was last on was totally glitching!

What I kept trying to figure out was where the glitch was occurring. Sure, it’s on screen, but what part of the signal is getting errors? I imagine that there’s three places it could’ve gone wrong: at Virgin Media headquaters, on the receiver at home or from the HDMI cable connecting the receiver to the TV. I turned the channel over and the glitch was gone, but that still doesn’t rule out where it could’ve been happening.

I think approach is one less seen in the glitch art world, but one that I’d really like to explore. It’s one thing to glitch an image or video on screen, but I have come across few examples that modify the screen itself, or the signal being sent to the screen. It might be a case of analogue versus digital.

One artist/hacker/tinkerer that I’ve come across recently is Karl Klomps, who appears to like to mess around with video signals:

failter 4 from karl klomp on Vimeo.

(thanks for the recommendation Rosa!)

Whilst I don’t yet have the technical skills to do something like that I think there are other ways that I can explore analogue glitches, even if it doesn’t actually involve computers or anything electrical.