Recently we have published a paper on SIGGRAPH 2011 about nonlinear revision
control system for images. You can find the abstract and videos at
As described in the abstract, the core idea is to record users' actions and
transform it into a DAG representation where nodes are actions and edges there
dependency. With the DAG, we are able to implement all important revision
control functions, including add, branch, diff, merge.
Although our prototype is tightly coupled with GIMP, we design our system for
easy porting between different image editing systems. There are three main
independent components in our system, image editing software (GIMP), revision
control system (GIMP plugin) and renderer (GTK+). And ideally, we can replace
any of them if necessary.
For now, the most messy part is on the image editing software, i.e. GIMP, in
this case. To achieve all fancy functions you saw on the video, the image
editing software basically does two things: log user actions (action name,
selected region and parameters) and replay the actions. The replay part is
simple with libgimp, but the log part is missing in current GIMP.
In this project, I implement all these stuffs on my own. And to meet the
SIGGRAPH submission deadline, I simply hack the GIMP core by inserting
functions that would output the corresponding logs in text into corresponding
functions (for example, inserting the output function into the
color_balance_config_notify() at app/tools/gimpcolorbalancetool.c to record
users' action of applying color balance...etc). And obviously, this is an ugly
I would really love to put our system upstream so that everyone can enjoy it
and the ultimate goal here is to replace the current backend completely with
GEGL. But a much simpler and faster way to do so is probably by implementing
some sort of macro system in the GIMP first?
So, I am wondering
1) is there anyone implementing the macro/script system
2) can anyone give me a head start on how should I modify my hack so that it is
more readable to others? Spreading the log function into tens of files
certainly breaks most guideline one should follow when writing object-oriented
Gimp-developer mailing list