Apple made news after sources said there was a shift from the plan for electric cars this month. Executives confirmed hundreds would be cut…
If you’re used to working with version control systems like CVS, Subversion or Git in order to keep track of changes to your code, then you will be well aware that changes to binary files such as images, just can’t be tracked in the same way.
Sure, there is no problem storing your binary data within any of these version control systems, but existing strategies either simply store the whole binary file in a single chunk, or store binary deltas. Both approaches consume significant amounts of disk space, and obscure the actual changes that have been performed within the file, defeating the real advantage of using any revision control system.
That’s why I was really excited to see the Microsoft Research group hard at work on the problem. Actually, probably the most refreshing thing about their research is that they are using the open-source graphics editor, GIMP, as their tool of choice in order to perform their research.
The Microsoft team set about tracking changes made to an image within a DAG (directed acyclic graph). This allowed them to track the individual editing operations, as well as the spatial and temporal relationships between each operation. These graphs could then be converted to standard RevG (revision graph) format.
This provides an intuitive interface to perform all of the common revision control operations including things like ‘review’, ‘replay’, ‘diff’, ‘branch’ and ‘merge’. It also provides a neat way to track creative processes within digital artwork.
The general approach that the team took involved developing a plugin for GIMP that could keep track of operations on-the-fly and built the DAG as different actions were performed. This, in itself, is not so exciting. After all, nearly every image editing application these days records your session history, making it possible to undo and redo actions.
Exporting this information as a graph that can be integrated into a functioning revision control application so that it is possible to open a version of the image at any point during its development, however, is definitely new. What is significant here is that the DAG only contains a faithful history of the operations performed by the user, and not any of the binary data itself.
While the DAG file itself can grow quite large and complex, so that it may not make sense to anybody reviewing the version history of a particular image, the team have worked out a way to represent the information within a revision graph which can be exposed to the user with a thumbnail of the image during each phase of its history.
The revision graph is capable of presenting non-linear information such as revision branching in a coherent and unified display. This means that by using the revision graph, you are able to perform all of the major functions that are available to you through any normal revision control system.
The RevG representation of the image data has been built into a very user friendly and intuitive interface that allows an end-user to quickly navigate through the entire revision history of an image, with the option of exploring different levels of detail in terms of the different operations performed at any point within the history. This UI has been built tightly integrated into GIMP so that when you click on any revision node within the graph, it highlights the areas of the image that were affected by that revision.
In order to display differences between revisions, you can either rely on this mechanism itself, or you can take advantage of a separate diff tool that actually play through both revisions in order to see the different changes that were made in each image. This will certainly help in collaborative environments where it is possible that you may need to perform merges and conflict resolution.
In fact the team have also developed a ‘merge UI’ that allows you to see each of the images that you intend to merge, and a preview of the resulting merged image. This really opens up the possibility of proper collaborative image editing, so that two artists can work on different portions of the same image at the same time and then simply merge their changes.
Unfortunately, the work that has been done so far has been so deeply integrated with GIMP that it does not provide a universal mechanism that can be used by any arbitrary image editing software. Nonetheless, the groundwork has been done, and certainly if the major software vendors can get it together to agree on a standard based on this research, the way is paved to finally bring realistic revision control to image editing software and this will transform the way that designers work within any commercial studio.
If you want to read the actual research paper, you can pick it up at Microsoft Research. That reminds me, the next time I hear any geeks openly bashing Microsoft, this is the paper I will point them to.