SummerOfCode

GIMP got accepted for GSoC 2008!!!

This page contains a bit of information that may be helpful to students considering GIMP-related projects for the Google Summer of Code program, and also some ideas for possible projects. If you have ideas of your own that don't match anything here, please feel free to discuss them with us. The IRC channel #gimp on irc.gimp.org is a good place for informal discussions; most of the developers hang out there.

  1. GIMP development
    1. How is GIMP coded?
    2. How is the GIMP project organized?
  2. What categories of projects are available?
    1. Plug-ins
    2. Core
    3. GEGL
  3. What release(s) should SoC projects be based on?
  4. What your application should tell us
  5. Documents for GSoC 2008
  6. Projects finished during SoC 2006

GIMP development

This is a quick overview. You can get a lot more information at the GIMP developers web page, [WWW] http://developer.gimp.org .

How is GIMP coded?

GIMP is a cross-platform application, written in C, with some auxiliary code written in Perl. It uses the Gtk+ graphics toolkit, which forms the foundation of Gnome, but GIMP does not require Gnome in order to work. The code makes extensive use of the GObject system, which provides a framework for object-oriented programming using the C language. Code management is done using Subversion, with two main branches at any given time, a stable branch where changes are limited mostly to bug-fixes, and an unstable branch where most development occurs. The SVN archive is stored on the Gnome SVN server at svn.gnome.org.

The code is well-organized, and relatively easy to read, because it systematically follows the "GIMP coding style", which is similar to the default settings of Emacs C mode, and is documented in the "Hackordnung" on the GIMP Developers web page. Parts of the code are well-documented using the GtkDoc system (which generates documentation from comments inserted in the C files), but the logic of the large-scale organization is not so well documented, and a contributor who intends to work on core functionality must be willing to spend some time learning the architecture.

How is the GIMP project organized?

The official maintainer of GIMP is Sven Neumann, who took over leadership after having made numerous contributions for several years. He took over maintenance while a graduate student in Physics, and now works as a programmer in Berlin. Sven works closely with Michael ("Mitch") Natterer, who also lives and works in Berlin. Mitch has written or rewritten major parts of the core GIMP code, and understands the details best of anybody. In addition, several other people, from several countries, make regular contributions to the code base, and dozens more people have made small contributions. The general principle is that patches should be reviewed, or at least discussed, by Sven or Mitch before being committed. Developers are encouraged to keep as much of their code in SVN as possible, but it is forbidden to commit changes that "break the build" on any platform that GIMP supports.

There are three primary mechanisms for coordinating GIMP development. First, the GIMP project uses an [Irc IRC] channel, #gimp on irc.gimp.org, where Sven, Mitch, and other developers participate regularly and discuss ideas. Second, there is a mailing list, [MAILTO] gimp-devel@lists.xcf.berkeley.edu, for discussion of development-related issues. Archives of this list are maintained in several places. Third, GIMP uses the Gnome Bugzilla system to maintain an organized database of [WWW] bug reports and enhancement requests, as well as comments and discussion related to them.

What categories of projects are available?

In the past, there have been two major categories of projects: plug-ins and core. Now, we have one additional category: GEGL.

Plug-ins

Plug-ins are using an API to extend GIMP, e.g. by providing support for file formats (anything but the XCF format is implemented this way), algorithms (think blurring, sharpening), image structure (saving layers as images, ...). Many of the entries in the menus are in fact provided by plug-ins. To a lesser extent, one can also include Script-Fu scripts in this category, although we did not have any projects involving them yet.

Working on plug-ins does have the advantage of not having to change GIMP itself. So if you have GIMP and the development libraries installed, you're good to go. Also, people using older versions of GIMP than the one you're currently working on might also be able to use your work.

The disadvantage is that some things are simply not possible with the current plug-in API - for example drawing and effect on an image interactively (this is why the IWarp and GFig plug-ins force you to draw in their previews).

In 2006, support for the JPEG2000 file format was added as a plug-in during Google Summer of Code.

Core

GIMP itself. Any changes done here will require that you build GIMP yourself. THis is where you implement new tools (paint brush, selection tools, transforms tools, text tool...), work with the resources (brushes, patterns), extend the image structure (layers, channels, text layers, paths, ...) change the GIMP UI - in short, work on the "how GIMP works".

The advantage is that you got for more influence on the interactive work. You want to apply an effect by drawing? Or want to make editing text a lot easier. Then a new tool or a modification of an existing one is the way to go. Maybe you want to add more brush types - maybe the format of antoher popular program, or something entirely new like painting with SVG shapes? Then you'll add a new brush class. Or maybe you're looking for a change that isn't so much about image manipulation itself, but more focussed on the infrastructure - e.g. how things may be automated, how GIMP's performance may be tested, how resources are organized - all done in the core.

The disadvantage is that changes to the core may take more thought to get them right. For example, with the tools, it can take several iterations of getting things right. Be prepared and do not hesitate to ask a lot if you want to tackle such projects.

The Healing Brush and Vanishing Point Cloning have been added as new tools during Summer of Code 2006.

GEGL

GEGL is a graph-based image image processing framework which will eventually be entirely used by GIMP. It provides a set of image manipulation operations - called 'ops' - which can be combined to form any kind of manipulation tree you can imagine.

For example, think about loading two images, blurring one, sharpening the other, and arranging them as layers in a final image. You have used two load ops, one blur and one sharpen op, and an op called 'Over' to combine them (and this is proably not even complete). And, contrary to the way GIMP works now, you can go back to each of the operations and change the parameters as easy as you can move around layers in GIMP right now.

And, as an additional difference, these ops are comparable to current GIMP plug-ins. This means that if you want to add a new blurring algorithm, you can add it as a new op just like you'd add a new plug-in to GIMP.

What release(s) should SoC projects be based on?

During SoC 2008, we will be in the development cycle for GIMP 2.6. This release is supposed to see the first uses of GEGL inside GIMP. This means that a whole lot of things might become easier - filters will no longer have to be destructive, but can be changed afterwards, we will be able to introduce higher bitdepths, new color spaces and more.

In general, SoC projects will be organized in Subversion branches. This guarantees that changes to the trunk won't affect your project unless you want them to.

What your application should tell us

Some of applications we got in 2006 were a bit dissatisfying. You should include:

Just copying a line from our ideas or bug tracker won't get you in.

Documents for GSoC 2008

Projects finished during SoC 2006

last edited 2008-03-18 09:41:28 by MichaelSchumacher