Development‎ > ‎

Google Summer of Code (GSoC)

This page lists old/new ideas for GSoC for GIMP. It's based on the GIMP wiki GSoC page (The page is down, an archived version is available here), and on the offical GSoC pages for GIMP (2006, 2008, 2009, 2010)

In short, what is Google Summer of Code (GSoC)?

From the official site: "Google Summer of Code is a global program that offers student developers stipends to write code for various open source software projects." Practically, this means that each year google selects about 150 open-source projects, and pays students 5000$ (USD) for working on the project for 3 months, to implement a specific feature. Each student is assigned a mentor which will guide him through the process, but most of the work (if not all of it) will still be done by the student. Therefore, each open-source project decides on some requirements that students must fullfil in order to participate. Each year, the open-source applies for GSoC and when (and if) it's accepted then students may apply (students must fullfil the requirements of google and of the specific project). About 1000 students are accepted each year (since each open-source project may have several GSoC projects).

More information can be found at the GSoC site. Note that participation is only allowed for students who are older than 18.

Obviously, this page exists here since GIMP applies for GSoC almost every year =)

Projects being developed in GSoC 2010 (this summer!)

HDR and matting operators for GEGL

Mentor: Martin Nordholts
Student: Danny Robson

GEGL does not currently contain methods which assist in HDR workflows which have become quite popular. I propose to develop three native GEGL tone-mapping operations.

I also propose to target an image matting operator, allowing the straightforward decomposition of an image into foreground and background components. I will implement the `matting laplacian'.

Cage-based deformation tool

Mentor: Kaja Liiv
Student: Michael Mure

Green Coordinates is a method allowing deformation of an image, by deforming the inside of a polyhedral cage. The technique was exposed in Siggraph 2008. Unlike the other classical method (mean value coordinates, harmonic coordinates, ..), it allows high quality deformation by preserving the shape.

Basic behavior of the tool:
  • you "put" a closed polygon on the image (not limited to 4 handles)
  • you deform the cage, the image is deformed accordingly

Implement and add infrastructure for on-canvas tool drawing/options

Mentor: Joao Bueno
Student: Chen Yan

The project is to implement and add infrastructure for on-canvas tool drawing/options. Gimp has many dockable dialogs. If some commonly used and simple interactions, with values and settings, can be presented, tracked, and modified directly on the image canvas, it would be very useful. It would save clicks and users' time. Reducing the number of opened dockable dialogs is advantageous, especially for Windows users, for many simple editing, drawing and options.


Projects finished in GSoC 2009

Better nonlinear resampler with built-in antialiasing (GEGL)

Mentor: Nicolas Robidoux
Student: Adam Turcotte

Port improvements to Nohalo Level 1 and port Snohalo Level 1 from VIPS to GEGL. Program Nohalo and Snohalo Levels 2 and 3 in demand-driven mode for GEGL with Dr. Robidoux. Test for bugs and optimize for speed. Merge the various methods so that levels are automatically chosen depending on requested quality level, and so Nohalo is selected instead of Snohalo when additional antialiasing is set to zero. Sample output images can be seen at http://gsoc.rivetsforbreakfast.com/enlargements.html.

OpenGL GPU-based Buffer & Operations in GEGL

Mentor: Martin Nordholts
Student: Jerson Michael Perpetua

GEGL (Generic Graphics Library) is a new back-end to replace GIMP's old code for handling various image processing tasks.
GPUs nowadays are capable of massively accelerating graphics tasks, there is an ongoing movement to harness this power in general computing. However, because of the nature of GPU parallelization, not all code can be executed in the GPU. GEGL's architecture of pixel operations yields itself to GPU parallelization, making it a good candidate for GPU acceleration.

Fast Adaptive Resampler Tailored For Transformations Which Mostly Downsample (GEGL)

Mentor: Nicolas Robidoux
Student: Eric Daoust

I am proposing to implement better and faster downsampling and resampling in GEGL

Improve Foreground Selection Tool

Mentor: Gerald Friedland
Student: Jie Ding

SIOX is the algorithm underlying GIMP's foreground selection. In current version, a pixel is either foreground or background. A Detail Refinement Brush will be offered to the user as a simple interactive drawing tool, with which the foreground selection could implement a soft segmentation. It would improve the performance of the tool for areas where background and foregound overlap, such as in fine-grained, highly-textured, or semi-transparent objects like hair, clouds, or iced objects.

Proposal - Advanced GUI for brush dynamics (GIMP)

Mentor: Kaja Liiv
Student: Zhenfeng Zhao

This proposal presents the plan and goals to the project “Advanced GUI for brush dynamics”, and how my experience fits. With my graduate studies in image processing, and being Lead Developer of a local company (3-patent image manipulation R&D) I had outstanding skills and experiences. I am proficient in C, understand the tasks, and enjoy working virtually.


Projects finished in GSoC 2008

Improving the text-tool in GIMP

Mentor: Daniel Eddeland
Student: William Skaggs

"Although the text-tool in GIMP works right now, it could be even better and more convenient with more functionality. When editing text you type the text in a dialog instead of on the canvas itself. I found "on-canvas text editing" as one of the ideas listed on the GIMP GSoC ideas page, and thought it would be a good idea to implement, as it would make the text tool more ergonomic and also look a little better (less dialogs to keep track off = cleaner interface)."

Enhance Python Scripting Interface Experience

Mentor: João Sebastião de Oliveira Bueno
Student: Lars-Peter Clausen

"The overall goal of this project is to enhance the python scripting interface experience for The GIMP.

As part of this I'll creating binding for gimp objects and widgets that haven't a binding yet but would be useful to have in python scripts. I'll also in collaboration with the community identify other missing or nice to have aspects in the python scripting interface and then try add them."

Tagging of GIMP Resources

Mentor: Aurimas Juska
Student: Sven Neumann

"Currently resources such as brushes, gradients, etc are presented to the user in a single list without a possibility to organize them in any way. This makes it impossible to deal with large number of resources efficiently, thus making the GIMP less attractive for both professional and casual users.

Adding tags to resources is natural and convenient way for users to organize their collection of resources so they could quickly find the ones they want for the specific task and create their own collections easily."

Operations in Frequency Domain

Mentor: Øyvind Kolås
Student: Zhang Junbo

"Many of the image processing operations in the spatial domain are very difficult or even impossible, but in the frequency domain it may be quite simple. But GEGL, the new framework of GIMP, has not support operations in frequency domain yet. Therefore, a collection of operations in frequency domain for GEGL is urgently needed.

A good framework has been provided in GEGL. Operations(plug-ins) in frequency domain could be implemented modularly."



GSoC 2007 - GIMP wasn't accepted =(


Projects finished in GSoC 2006

JPEG2000 plug-in

There is a number of file formats that GIMP should support, but doesn't or at least doesn't support fully, for example JPEG 2000.

Vector layers and tools to manipulate them

Mentor: Simon Budig
Student: Hendrik Boom

Have Vector layers that are connected to (multiple) vectors objects (think paths) and get re-rendered when the vectors change. Make it possible to attach styles to the vectors and maybe add different types of vector shapes (rectangles, ellipses...). Make all this usable...

Ruby binding for GIMP scripting

Mentor: Kevin Cozens
Student: Scott Lembcke

Ruby is an object-oriented language that is driven by the „principle of least surprise“ - it tries to avoid all the pitfalls and caveats other languages have. There is an ancient version of a GIMP binding, it would be interesting to have it resurrected (with as little undead side effects as possible

Healing brush

Mentor: Manish Singh
Student: Kevin Sookocheff

Removing freckles or other spots from skin can be tedious - the clone tool helps, but sometimes it is hard to find the right spot to clone from. A "healing brush", as it is named in other programs, removes the spots by e.g. averaging the surrounding area; other approaches are possible as well.

Vanishing point cloning

Mentor: Manish Singh
Student: Pedro Alonso

Photoshop got an interesting tool recently - similar to clone, but it applies a perspective transform to the texture. Think about changing or "repairing" a tiled floor of a hallway on a photo - it is easy to create a flat tile texture, but it has to be transformed correctly when applying it


General student requirements for GIMP related GSoC

  • Knowledge and expirience of coding. C is the preferable language.
  • Experience with GTK+, glib and gobject is a plus
  • If you are implementing a graphical algorithm, then some knowledge of the algorithm, or at least about general computer graphics/image manipulation, is obvoiusly required

Recent Ideas for GSoC (2010 and later)

You may also want to take a look at the todo's page - some of the projects there are big, and can maybe be incorparated as a part of some GSoC student's work.

JavaScript scripting in the core and/or plug-ins - using GNOME Java Script infrastructure (GJS)

Mentor: Martin Nordholts
 
GIMP scripts and plug-ins can be written in Scheme, Perl, Python and C. Scheme is always available, but limited in its application in regard on image manipulation. Additionally, as a list-processing language, it may appear as weird to most users. Its main purpose is scripting workflows for repetitive work.
 
The Perl binding is currently the least supported one and not available on platforms other than Unix. The Python binding and the C libraries are current the most powerful ones.
 
Javascript could take over Scheme's role as the genreral purpose scripting language for GIMP.
 
Optimal student requirements:
  • Experience with JavaScript integration in applications
[Editor's Note]: At least for scheme, there are no debuggers for scripting in GIMP, and only tracing is supported. It would be neat if as a part of this project, a javascript debugger will be integrated so scripts could be debugged in a sane way. Again, this is not a part of the original project suggestion, but this is something I thought that should be added.

Make menus searchable

Mentor: Martin Nordholts
 
... i.e. have a textbox, in te menu for example, and anything typed will be matched against all menu items and their blurbs and maybe something more (like procedures not registered in menus).
 
Optimal student requirements:
  • Experience with database algorithms and implementation issues

Implement the free transform tool

Mentor: Martin Nordholts
 
For exact specifications, see: http://gui.gimp.org/index.php/Transformation_tool_specification
(may be offline at the moment)
 
Optimal student requirements
  • Good knowledge about image resampling, in particular warping base

Implement and add infrastructure for on-canvas tool drawing/options

Mentor: Martin Nordholts
 
Most of GIMP's tools do still require a dockable dialog for user interaction. Some of the values and settings that are changed there could be presented and modified directly on the image canvas (see for example the text tool of GIMP 2.7).
 
Optimal student requirements:
  • Good at high-level and architectural, API based thinking


Replace the GimpSizeEntry widget

Mentor: Martin Nordholts
 
Right now both the code and the UI is a mess. The unit should for example be in the text entry itself instead of in a combo box
 
Optimal student requirements:
  • Widget and interaction design experience or at least interest

Brush selector wigdet

Mentor: Alexia Death
 
More precisely one that is also capable for brush transform input (size/angle/aspect ratio).
 
Optimal student requirements:
  • Widget and interaction design experience or at least interest

Basic gegl based paint tool

Mentor: Alexia Death
 
Basic paint tool that is capable of taking user input, converting it into something that gegl handles, creating paths that gegl renders keeping up with the painter as fast as possible. Integration with gimp is optional, but the tool's gegl core should have some ui and be capable of accepting both just parametric and parameters plus a gegl buffer input to render.
 
Optimal student requirements
  • Prior experience with gegl or with graph based rendering

Slicing tool

One of the most requested features by web designers and/or interface designers, is the addition of a slice tool. Currently slicing images inside GIMP can only be done in grids (using guides and the guillotine action) and you can't split just one rectangle in the middle.

For example, the following slice can not be achieved:

-----------------------------------
|            |                    |
|            |                    |
|            |--------------------|
|            |                    |
-------------|                    |
|            |                    |
-----------------------------------

Note that it's arguable where a slice tool since be in GIMP, since according to the product vision GIMP "GIMP is a high-end application for producing icons, graphical elements of web pages and art for user interface elements" and as it was pointed out, it's for designing elements and not the entire thing.

However, this is a highly requested feature, which should also be useful in other cases (example: artists might want to break their images into parts for printing on different canvases and for many other reasons).

A recent discussion showed a consensus that this should be supported.

Older Ideas for GSoC

Note: Ideas listed in this section may be 100% rellevant, may be 50% or so relevant, and may be completly outdated. You may want to check if this idea is still relevant before suggesting to work on it.
  • Filetype registration

    There is currently no way to register a file type to open with GIMP from within GIMP itself. On some desktop environments and platforms, this makes registering types to open with GIMP awkward. We need a configuration GUI within GIMP, which does show the available types and/or file extensions, and a means (a backend) to register them according to the platform/environment. The latter should probably be modular and extensible, because this is different on each of them.

  • Tests have shown that it is possible to crash plug-ins when feeding them bogus data via the PDB API, for example when calling them from scripts (another interesting approach might be to run file loader plug-ins with zzuf). Needed: a test framework to find the bugs, and then time to fix them.

  • Additional file format plug-ins

    There is a number of file formats that GIMP should support, but doesn't or at least doesn't support fully, for example MNG. The MNG save plug-in needs to be modified to save images in MNG-LC profile. Then a loader can be easily written to work similar to the GIF loader. It also needs support for JPEG chunks.

  • Search-based menu browser

    The amount of menu entries in GIMP - either from plug-ins, scripts or internal functions - is huge. The name of a particular function might be easier to remember than its menu location. Being able to search for the function and applying it to the image without having to go through the menus can help (similar to Emacs' M-x feature).

  • Unified UI for scripting

    We have three major scripting interfaces, Script-Fu, PyGimp and Perl-Fu. All of them allow to create an interface for a script easily, just by registering a function with their respective parameters. However, all widgets look a bit different depending on the binding.

  • Unit testing framework

    GIMP currently doesn't have a test framework that API changes or internal changes could be tested against. This is crucial to avoid regressions, especially with the major rewrite we will seen when GEGL is introduced.

  • SVG brushes

    VBR brushes in GIMP - basic shapes like ellipses, rectangles and rhombuses; with additional spikes - are scalable. In SVN trunk, all brushes including the pixmap-based ones can at least be scaled down. We do not yet have means for more advanced brushes (think about a brush consisting of two disjoint circles) that can be scaled up in a lossless way.

    Using SVG files as brushes could help to solve this.

  • Benchmarking

    In many cases, image manipulation is compute-intensive - many operations are loops which go over all pixels of an image. Sometimes, there are more efficient algorithms for a particular method. But does it have other drawback? Or is the time spent at an entirely different place, e.g. code that does check something on every loop while it would be sufficient to only do it once? Can it be changed safely?

  • Font Selector Widget

    We need something better. Something that is reusable. Something to turn choosing fonts into a pleasure, rather than a pain. Something to leave the competition on the dust.