Difference between revisions of "Hacking:GSoC/2011/Ideas"

From GIMP Developer Wiki
Jump to: navigation, search
Line 183: Line 183:
  
 
See http://www.cs.huji.ac.il/~danix/mvclone/
 
See http://www.cs.huji.ac.il/~danix/mvclone/
 
 
== For a later GSoC ==
 
 
It is too early to start working on projects listed here.
 
 
===GEGL based brush core in gimp===
 
 
'''Category:''' Tools
 
 
'''Potential Mentor:''' Alexia Death
 
 
GIMP's old paint core needs a replacement. This is a big process and as a first step a prototype would need to be created. This GSoC project is essentially a research task.
 
 
For successful completion following items need to be provided:
 
* Research paper in form of a web page detailing work done, bottlenecks encountered and outline for the architecture of GEGL based paint core in GIMP based on the prototype.
 
* The prototype code, applicable to gimp git master, capable of painting using raster brushes interactively with application at least one dynamic parameter and at least one application mode other than normal.
 
 
Minimal Student Requirements:
 
* Good spoken/written English
 
* Good communication skills
 
* Good C knowledge
 
* Some GIMP or GEGL coding experience
 
* Basic knowledge in image manipulation and digital painting
 
 
===Implementing an infrastructure to run GIMP plugins on GEGL===
 
 
'''Category:''' Plug-Ins
 
 
The current way of accessing pixel data will be deprecated in GIMP 3.0, so it was suggested to implemnt an infrastructre to manipulate pixels with GIMP's existing API over GEGL. this will make porting plugins easier to GIMP 3.0.
 
 
===Port UI code to a non-low level language===
 
'''Category:''' User Interface, Future
 
 
Hacking UI code in C is a resource eater for us, we should use C for
 
quick and efficient pixel processing but not for creating buttons. It
 
would be interesting to make changes to the GIMP codebase that would
 
allow us for example write the Pointer Information Dialog in JavaScript, Python or probably most preferable: Vala.
 
 
=== Scripting line-by-line debugging support ===
 
'''Category:''' Plug-Ins/Scripts
 
 
There are no debuggers for scripting in GIMP, and only tracing is supported. Support should be added to allow one to single-step line-by-line in a JavaScript script for example (if we take the JS scripting project) and if not, integrating a debugger for tinyscheme is also going to be very helpful as a massive part of GIMP's scripting is done in tinyscheme.
 

Revision as of 09:14, 24 March 2011

WORK IN PROGRESS!

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

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/gsoc2011/timeline

Recommended

Ideas which are generally considered as good for GSoC this year, and are recommended for students.

Note about mentors: some projects have mentors listed for them - these are projects where a specific mentor already agreed to take 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.

Replace the GimpSizeEntry widget

Category: User Interface

Potential 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. Right now the value and the unit are displayed in different fields - one in a combobox and one in a regular text entry. Doing things like 50px*3+3cm should be possible - that requires adding basic logic for math (which partially exists now) and merging the unit smartly into the text entry with the value.

Minimal Student Requirements:

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

Porting GIMP plugins to GEGL operations

Category: Plug-Ins

In short, there are many many GIMP plugins that would need eventually to be converted to GEGL operations, if we want to use them in future versions of GIMP.

GIMP is being ported to use a new image processing core called GEGL, a graph based image processing library, which allows non-destructive editing, higher bit depths, smart job managements and memory management, and much more. Unfortunatly, GIMP's plugins use GIMP's own existing API which is not compatiable with GEGL's api for design reasons. Therefore, at least the core plugins should be ported to GEGL, which means porting the image processing logic and doing some adaptions to the logic.

This is a massive project, since GIMP has many many official plugins, which will be composed out of many small tasks.

Minimal Student Requirements:

  • Good C knowledge
  • Good image processing/filtering knowledge and possibly some actual experience in the area

Implement the free transform tool

Category: Tools, User Interface

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

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

IWarp tool (aka Liquify)

Category: Tools

GIMP has a plugin with a small preview which allows to whirl/pinch/grow/shrink parts of the image. We want to create a live on-canvas tool for that operation, like the rest of the core tools.

For details about the original plugin, see http://docs.gimp.org/2.6/en/plug-in-iwarp.html

In order to implement this, in a way that will match the upcoming changes in the core, it will be implemented using a GEGL operation which does the actual image transformation. A big part of the infrastructure for a GEGL based tool, was written in the previous Google Summer of Code in which a cage transformation tool was implemented using a GEGL operation.

Minimal Student Requirements:

  • Good C knowledge
  • Basic knowledge in image manipulation and/or filtering


Adaptive Image Cloning (aka Seamless Cloning)

Category: Tools

Potential Mentor: Michael Natterer

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.

It differs from the existing heal tool, since it is meant for taking one area from an image, and paste it smoothly in some other area. The current algorithm implemented by the healing tool allows to remove local irregularities (such as dots, hairs, etc.) very well, but experiments of using it to do "adaptive cloning" of areas (for example copying a person from one image to the other) do not produce good results.

Minimal Student Requirements:

  • Good C knowledge
  • Basic knowledge in image manipulation and/or filtering

See http://www.cs.huji.ac.il/~danix/mvclone/