From GIMP Developer Wiki
Revision as of 18:36, 25 May 2013 by Scl (Talk | contribs)

Jump to: navigation, search

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 in GSoC 2013

Projects in GSoC 2012

Port missing GIMP features to GEGL

Mentor: Mukund Sivaraman

Student: Ville Sokk

Working on recreating legacy GIMP features that are missing from GEGL. The aim is to help replace the existing GIMP image processing core with GEGL to bring better precision, more colour formats and better programmer flexibility to GIMP while keeping all the familiar GIMP features working as they are.

See also the GSoC page.

Integration status: work in progress

Porting GEGL operations

Mentor: Victor Oliviera

Student: Hans Lo

I am applying for the GEGL operation porting project.

See also

Integration status: work in progress

Graphical Node Editor

Mentor: Alexia Death

Student: Isaac Wagner

It consists of two components. The first and largest component is the development of a fully-featured graphical node editor ("box and hose editor") which will sit on top of the GEGL public API and allow for fast sandboxing of GEGL operations for debugging, artistic, and showcase purposes. The editor will be similar to familiar editors such as Blenders shader editor and the MathMap1 editor. The second component of my proposal is to develop code for saving and loading meta-ops to and from XML (resolving bug 465743). This code will exist within the GEGL codebase and manifest itself as a component of the node editors interface.

See also

To build the project yourself, you also need Graph-gtk.

Unified Transformation Tool

Mentor: Michael Natterer

Student: Mikael Magnusson

Category: Tools, User Interface

Implement a unified transformation tool that combines the functionality of the rotate, shear, scale and perspective tools, and is easier and faster to use.

Initial implementation is available in Mikael Magnusson's Git branch.

Minimal Student Requirements:

  • Good C knowledge
  • Gtk+/GObject basic knowledge and/or at least some interest in User Interface programming

See also

Integration status: work in progress. To be integrated in GIMP 2.10.

Projects in GSoC 2011

Porting GIMP plugins to GEGL operations

Mentor: Mukund Sivaraman

Student: Robert Sasu

The main point is to port GIMP plug-ins to GEGL, because GEGL API supports higher pixel depth, has a smart job and memory management, allows non-destructive editing.

See also

Integration status: work in progress. To be integrated in GIMP 2.10.

OpenCL in GEGL

Mentor: João S. O. Bueno

Student: Victor Oliveira

The proposal is about making it possible to write GEGL operations in OpenCL. There are two tasks:

  1. Automatic memory management and migration of tiles from GPU to the CPU and the other way around.
  2. Make some GEGL operations in OpenCL.

See also

Integration status: work in progress. To be integrated in GIMP 2.10.

Adaptive Cloning (aka Seamless cloning)

Mentor: Michael Natterer

Student: Barak Itkin

Direct cloning of parts from one image to another, usually ends in bad results because of different lighting conditions and other settings (such as white-balance) which causes the color of the cloned part not to match the source image and look out of place. There are some techniques to solve this, by using poisson equations and some other methods. This suggestion allows a fast (realtime) solution for allowing to paste seamlessly parts from one image to another.

See also

Integration status: work in progress. To be integrated in GIMP 2.10.

Replace GimpSizeEntry widget

Mentor: Martin Nordholts

Student: Enrico Schröder

The GimpSizeEntry widget in its current form, which is used across the user interface for entering values and their corresponding units (e.g. image dimensions, lengths, etc.), has a couple of issues both from a users and a developers standpoint. The project is to rewrite the widget being based on GtkEntry with the ability to directly enter and display the desired unit in the text field itself instead of in an external control. Simple mathematical terms for the input of values in different units will be possible using the existing parser (gimpeevl).

See also

Integration status: work in progress. To be integrated in GIMP 2.10.

Warp tool for GIMP

Mentor: Alexia Death

Student: Michael Muré

The goal is to implement a live on-canvas iWarp like tool. Behavior: The basic usecase of this tool would be:

1. The user select the iwarp tool. Nothing is displayed on top of the image.

2. If needed, the user select a particular behavior for the tool (drag,shrink, grow, whirl, pinch ..)

3. The user do a stroke on the canvas. The image is updated accordingly.

See also

Integration status: work in progress. To be integrated in GIMP 2.10.

Projects in GSoC 2010

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 Mindstrom:Misc TODO's - 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

Potential mentor: João S. O. Bueno, Alexia Death

Category: Tools, User-Interface

Note: this project, although very essential, requires complete UI specs which are not yet present, and therefore is considered less likely to be done, at least untill we have decent UI specs.

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:

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

A more advanced version will take the slicing idea to a new place, allowing to create general rectangles:

|          ---------------   ----   |
|          |             |   |  |   |
|          |             |   ----   |
|          ---------------          |
|                               +---+--+
|                               |   |  |
--------------------------------+----  |

And why stop at rectangles? Maybe allow custom shapes using custom paths? Further ideas were suggested in the mailing list, at this post..

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 discussion showed a consensus that this should be supported.

Minimal Student Requirements:

  • Good C knowledge
  • Gtk+/GObject knowledge in high level and experience in User Interface programming

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.