Making GEGL useful for applications beyond GIMP

The Generic Graphics Library (GEGL) is a non-destructive image processing framework built for raster image editing. Most people are probably familiar with it through its role as the GIMP's next-generation core editing layer, or else through critics who claim that it is taking too long to integrate. However one feels about the GIMP's pacing, though, a new branch of GEGL was just created that will allow easier use of the library by other applications — including, eventually, by non-GTK+ applications.

GEGL, graphs, and GIMP

To the casual observer, the "big news" about GEGL is generally reported to be enabling all GIMP functionality on 16-bit-per-channel and 32-bit-per-channel images. The real innovation, however, is that GEGL is non-destructive — which allows for lossless editing, rollback, and even reordering of operations. GEGL accomplishes this by storing the image as a directed acyclic graph of nodes, rather than transforming image buffers directly. Each node in the graph typically represents an operation, which can be anything from loading a buffer from a file, to applying a filter, to a matrix transform. But nodes can also be parents of sub-graphs, which enables GEGL to create nested image processing pipelines.

Ultimately, however, the "file" is simply the graph in question, so it can be stored along with any raster samples and/or vector path objects (such as selection regions) as a complete representation of the editing session — without destructively modifying the original source images. Because each node is either an operation or a sub-graph of operations, each edge in the graph represents the image that would be generated by walking the graph. GEGL's C API allows code to re-parent and rearrange nodes in the graph, so that the chain of operations can be manipulated.

The current stable branch of GIMP (2.6.x) uses GEGL for internal color operations, and allows the user to selectively use a GEGL Operation tool to apply any of two dozen or so GEGL operations to the current image. Nevertheless, the fact that GEGL has been in development since 2000 and has yet to completely replace GIMP's editing core has led a few to dismiss it as vaporware that is not ready for prime time.

There is rarely a single, simple answer as to why a particular coding task hasn't taken place, but in this case, those familiar with the code do not regard GEGL itself as incomplete. Rather, the lengthy transition period seems largely to be the result of GIMP's enormous size and relative paucity of full-time developers. Replacing the core of a large, multi-faceted application — particularly when the new core uses an entirely different model — is simply a labor-intensive task, and there seem to be too few volunteers given GIMP's size and users' expectations that it will remain stable during that kind of transition.

GTK and truly generic graphics

Reality is that any open source project could start using GEGL as an image processing library, of course, but it has not always been simple to do so. That is where this month's new branch comes into play. Jon Nordby of the MyPaint and OpenRaster projects started the GEGL-GTK branch in order to separate out some GTK+ functionality and turn GEGL into a more general library for use by other (that is, non-GIMP) applications. MyPaint is considering adopting GEGL as its own image processing system further out on its roadmap and Nordby saw this as the first step in making a hard assessment of the option, as well as being beneficial to other projects.

The first objective was the removal of a pair of GTK dependencies from within the GEGL codebase. One was gtk-display, a GEGL operation to display a graph's rendered output inside a GTK window — certainly useful for GIMP, but not a core operation. The other was the GeglView GTK widget that resided only in the examples directory; it was meant to show developers how to integrate GEGL and GTK. Both have now been pulled out and into the nascent GEGL-GTK utility library. That move immediately removes the GTK dependency from GEGL itself, but it has additional implications for application developers interested in adding GEGL support to their code.

The GeglView widget allows a GTK application to embed a live-updating view on a GEGL graph, complete with basic view operations such as zooming in and panning in any direction. The revamped gtk-display operation allows a GEGL graph to render itself onscreen, using the aforementioned GeglView widget. Nordby also added GObject introspection to GeglView (having added it to GEGL itself earlier in the year), and updated both the widget and the operation to support GTK2 and GTK3.

The result is a cleaner separation between the GEGL image processing core and the GUI toolkit, which, as Nordby explained on the GEGL mailing list, is a prerequisite for wider adoption of the library by application developers. There was some discussion in the thread about adding Qt or other toolkit-specific utilities in separate libraries in the future. For his part, GEGL maintainer Øyvind Kolås describes the changes as things that make sense to do from a GEGL point of view, too, and noted that he had created a Clutter integration library with similar hopes for making GEGL more accessible to other projects. "Having such widgets, and having them exposed should make it a lot easier for people to test getting going with interactive applications built on top of GEGL," he said.

The GTK-specific bits that seeded Nordby's GEGL-GTK have already been taken out of the mainline GEGL code, although a new release has not been rolled. Kolås also pointed out that Nordby had been actively contributing to the GEGL project in other areas, such as gardening the issue tracker and cutting into the "unhandled/lingering/patch-waiting/obsolete" bug count. The result is a bug tracker that proves more useful to project management.

Nordby says there is still a lot to be done in GEGL-GTK, starting with adding support for rotation to the GeglView widget, and adding signals to draw widget backgrounds and overlays. The latter feature is necessary to make GeglView functional as an editing component and not simply a live display — by overlaying editing tools and interface elements, for example. He would also like to add a widget property to support changing the scaling or cropping behavior, and an API to access the transformation matrix of the GEGL graph.

Further out, making the GeglView widget usable from languages other than C may be important to other developers. It is also possible that additional widgets would prove useful, such as an editable tree-view of the entire GEGL graph, or a widget that allows manipulating a node's properties. Ultimately, however, adding those features depends on developer demand. Although they would allow for low-level editing of the graph, such functionality is not how most creative graphics applications function.

GEGL all the way

One should not expect the GEGL-GTK separation to affect a large number of projects in the near term. MyPaint, like GIMP, is a GTK+ application, so it does not gain directly from separating out the GTK integration features into a distinct library (although it would benefit from the GObject introspection, GTK3 support, and new features). The other major project currently working with GEGL is the raw photo editor Darktable, which is also GTK+-based.

In the medium-to-long term, however, there is more hope. OpenRaster, the graphics interchange file format, already supports GEGL graph data. GIMP continues to migrate features to GEGL internally, with "projection" (the feature that composites selections and image layers on top of each other), scaling, the cage transform tool, and a large number of filters on the roadmap for the next stable release, 2.8.

Because raw photo editors are already expected to operate in non-destructive editing mode (the large file sizes and irreplaceable nature of the original images dictate it), they would seem to be a natural fit for GEGL. But the quickest path to increased GEGL adoption might actually come from the video realm. In May, Nordby wrote a GStreamer element called geglfilter that allows an editor to apply a GEGL filter to a GStreamer video processing pipeline.

It has not been accepted into the GStreamer plug-ins packages yet, pending some changes, but it sounds like it will eventually work its way into the upstream repository. Video, like raw photo conversion, defaults to a non-destructive editing paradigm. GStreamer-based editors such as PiTiVi could incorporate simple GEGL filters as effects, although adding a complex GEGL graph editor would be considerably more work.

As for KDE, Qt, and other GUI environments, only time will tell. Still, for a library project that has been under the purview of a single application for this long, the increased activity over the past few months is a promising turn of events. However long GEGL may have been in development (or more accurately, however long its GIMP migration may have taken), it remains the premiere, if not the only, non-destructive image editing library available in open source software. When it becomes easily accessible to other projects, the benefits could be inspiring to a wide range of creative users.