Hi all,

Recently we have published a paper on SIGGRAPH 2011 about nonlinear revision control system for images. You can find the abstract and videos at

https://sites.google.com/site/httimchen/2011_imagesvn

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 hack.

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

and

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 program :D

Regards, -Tim

On May 3, 2011, at 12:49 AM, Martin Nordholts wrote:

I'm convinced (others are not) we should use the proven http://en.wikipedia.org/wiki/Command_pattern and http://en.wikipedia.org/wiki/Composite_pattern for macro recording and wrote some patches a while ago that introduced a GimpCommand and a GimpGroupCommand class. I didn't have time to even turn it into a working prototype however.

Hi Martin,

It sounds like that there are other thoughts about how to implement the macro system? During my GIMP hack last year, my impression was that macro recording should be done in PDB. And I did not do so because not every functions went through PDB, e.g. those stroke functions (please correct me if my memory did not serve me right).

This is not a trivial refactoring, but we need to do it eventually.

Yes, this is non-trivial and I am certainly not the best one to do such heavy duty stuff. And I still don't feel too comfortable seeing all those GObject and Glib stuffs...I guess I will first release my hacked and messy GIMP version for researchers first...

In any case, the GIMP community helps me a lot and I do like to contribute something back, i.e. integrate my system into GIMP core.

Regards, -Tim