Hacking:GSoC/2012/Ideas

From GIMP Developer Wiki

Revision as of 18:48, 23 March 2012 by Pippin (Talk | contribs)
Jump to: navigation, search

WORK IN PROGRESS!

This page is the official ideas list for GIMP (and GEGL's) application to Google Summer of Code 2012.

GIMP is the Gnu Image Manipulation Program, and GEGL is a Graph based Image Processing Library. GEGL is being designed (mainly, but not only) to be GIMP's new core which will allow better parallelism, better memory management, non-destructive editing and higher bit depths.

For more GEGL ideas, see http://gegl.org/contribute.html

For history of GIMP and GSoC, along with past ideas, see Hacking:GSOC_Archive, and for details about applications see Hacking:GSOC‎

The GSoC timeline for this year can be found at: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/timeline

Contents


Recommended

Ideas which are generally considered as good for GSoC this year, and are recommended for students. Note that students are strongly encouraged to come up with their own project - this list is not exhaustive. A submission to gsoc which is just a copy-and paste job of one of these suggestions is not likely to be accepted.

Note about mentors: Some projects have mentors listed for them. These are projects where a specific mentor has already agreed to work with a student if the project is accepted. However, this does not mean that other projects have no mentor! In case projects other than the ones who have a mentor listed here will be accepted, a mentor will be assigned for them.

Note about tasks: Some ideas here may already be claimed by a potential student. If a claim is listed here it's solid enough that, unless the person claiming it gives it up, it wont go to another.

Implement GEGL ops that GIMP need

Category: GEGL, image processing

The migration of GIMP to use GEGL has accelerated - for some GIMP functionality the main hurdle to migrate is having GEGL ops that can act as drop in replacement for the core processing functionality (some ops would be desired directly in GIMP others could likely go directly into GEGL.).

For most code involved, porting to GEGL involves understanding what the current code does; and port or reimplement it as a floating point processing operation (floating point math often ends up shorter and more readable than the 8bit equivalents.)

A list of currently missing :

  • Implementations of layer modes - that behave exactly like the old ones.
  • Equalize (would include implementing histogram infrastructure in GEGL)
  • Stretch HSV
  • Decompose/Compose
  • Alien map
  • Gradient map (needs gradient support)
  • Palette map
  • Rotate colors
  • sample colorise
  • channel mixer
  • Motion blur
  • ... and many other things that currently exist in the Filters menu of GIMP currently.

Implement the free transform tool

Category: Tools, User Interface

This task is already claimed

The free-transform tool should a all-in-one transformation tool that will allow fast and easy transformation of images, with all kinds of affine transformations at once. For exact specifications, reasons which make this tool needed and more, see: http://gui.gimp.org/index.php/Transformation_tool_specification

Minimal Student Requirements:

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

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

Implement the combined selection tool

Category: Tools, User Interface

The combined selection tool should be an all-in-one tool for selecting regions based on a research made by Voralberg students in 2010.

Minimal Student Requirements:

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

Dynamically resized layers

Category: Tools, User Interface, Core

Potential Mentor: Martin Nordholts

Allow layers to be resized dynamically as the user paints on them, and save the user the burden of managing layer sizes

Right now layers have to be manually resized, which is unefficient and non-useable. The first and most common problem is painting and discovering that you reached the end of the layer in the middle of your brush stroke. Another common inefficiency is simply saving large layers which is a waste of memory (RAM and disk space). No need to mention it's annoying to manage the layer size manually, and trying to crop one layer which results cropping the whole image if you don't notice the UI options correctly.

Minimal Student Requirements:

  • Good C knowledge
  • Highly recommended - some knowledge of GIMP's internals (core/tools/etc.)
  • Being a bit familiar with GIMP as a user, as this project touches several areas

Support writing JavaScript plug-ins

Category: Plug-Ins/Scripts

Potential Mentor: Kevin Cozens

GIMP scripts and plug-ins can be written in Scheme, Perl, Python, Ruby, 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 currently the most powerful ones. The Ruby binding should be just as capable as the Python binding but it hasn't seen a lot of use and not many people may be aware of its existence.

Javascript could take over Scheme's role as the general purpose scripting language for GIMP. It should be based on GNOME Java Script infrastructure (GJS).

Minimal Student Requirements:

  • Good C knowledge
  • Good JavaScript knowledge
  • Good gObject knowlege
  • Some basic experience with GIMP's PDB (as a plugin/script writer)

Brush selector widget

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 until we have decent UI specs.

More precisely one that is also capable for brush transform input (size/angle/aspect ratio).

When you want to try a brush right now, you go to the canvas, paint on it, and undo that. No need to explain how wrong this is, both for user experience and for productivity. Right now we have options to adjust the size/aspect-ration (strech)/angle/color and some more parameters, which are not shown in the default brush thumbnail preview.

We need to create a widget that previews a brush after applying all of these parameters. We may also want to consider including the "Brush Dynamics" in the preview; "Brush Dynamics" allow mapping parameteres such as speed, tablet pressure/title, velocity and more, to every painting parameter - this allow to simulate many kinds of painting. This should probably be included in the preview by showing a brush stroke which brings all these effects into consideration.

Minimal Student Requirements:

  • Good C knowledge
  • Highly recommended - some knowledge of GIMP's internals (core/tools/etc.)
  • Gtk+/GObject basic knowledge and/or at least some interest in User Interface programming

Slicing tool

Potential mentor: João S. O. Bueno

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

Minimal Student Requirements:

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