SummerOfCode2008ideas

GSoC2008 Project Ideas

Please note that, although you are welcome to look at what is here, this is a workspace for mentors to write down and modify their ideas, and suggestions here should not be taken as necessarily viable projects until they have been finalized. Also, the fact that something appears here does not necessarily mean that anybody has volunteered to mentor it.

Note to people who add stuff here: Please try to add information about a proposal's overall complexity and experience that could be helpful. E.G. experience with GTK+, image manipulation algorithms, web application development, ...

Tagging of GIMP resources

Mentor: Sven Neumann

Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, only sorted alphabetically. This greatly limits the number of items a user can deal with.

People love to make collections of things and think of them by names for these collections, like "sprinf flower brushes" or "fancy fonts". However, one resource can belong to more than one set, and there can be sets which are determined by other means than the content, maybe even without the user having to do anything manually - think "Favorites", "Most recently used" and "Most frequently used". It has been suggested that this should not be a finite set of categories, bug rather done by assigning tags.

The tasks in this project include:

• adding a way for gimp resources to be tagged

• decide which types of resources (i.e. which types of gimp objects) should be tagged

• find a nice way for users to manage tags (add them, remove them)

• present tags in the UI (i.e. how do you show them in the brush list, font list, ...?)

• think about how tags can assigned to resources (or resources to tags)

Apart from that, a related task which can be integrated here, or expanded on its own:

• create structure for an online repository from which tagged resources can be seamlessly retrieved

On-canvas text editing

Right now, the text tool opens a dialog window where the text has to be put, thereby creating a new text layer. Nearly every other option of the text tool - font, font size, color, line height, ... - is available in the text tool options dialog, so it would be nice to get rid of this dialog as well. There have been feature requests about being able to edit text directly on the image, like for example Inkscape does it.

It may be that getting to the point where editing text on the image canvas is possible isn't that much of work, actually. But this is where the interesting challenges do begin: eventually, we do also want multiple styles in one text layer. This is not so straight forward anymore if your enter text in the image. Not present right now, so not having it isn't exactly a showstopper, but making it hard to ever get there is.

And you will have to consider support for GTK+ input methods. They may be used to enter characters from languages (or, more precisely, scripts) beyond the simple Western scripts which define how our common keyboards are layed out. This is supported right now in any GTK+ text entry, not having it for on-canvas editing would be a regression.

Tasks for this project include:

• port the text core to PangoCairo

• get on-convas text editing implemented

• figure out if we do still need a text entry dialog (even Inkscape still has it in the properties of the text object)

• make sure that GTK+ input methods work this this new approach

• think about making it possible or not making it impossible to style the text while editing it this way

GIMP Python

mentors: Yosh or João

With version 2.4, python becomes the preferred method of scripting plug-ins for GIMP. Python is an universal multipurpose cross-platform language, adopted as scripting language by several applicatives, easy to understand, with a feature rich set of standard libraries.

GIMP python scripting is possible since 1999, before version 1.2 and it allows access either to GIMP's procedural database and to internal image pixel data, just like plug-ins written in C.

However there are points that can be greatly improved. Things that can be done for a Google Summer of Code project:

Properly map Gimp Widgets and objects to Python

Wrap all libgimpwidgets to be accessible from python, so python plug-ins can have the same presentation as gimp components written in C (that is gradient and palette selectors, scale entries). Additionally map all remaining gimp objects to proper python objects, just as layers and images are already: palettes, gradients, brushes, patterns, fonts.

The best way to do this is making sure that GIMP widgets are GtkBuildable. The GtkBuildableIface interface contains method that are necessary to allow GtkBuilder to construct an object from a GtkBuilder UI definition. This would make it a lot easier to write GIMP plug-ins for other languages as well, as developers would have less hassle with UI code.

Enhance the interface builder, add plug-in previews

Add optional parameters to the automatic interface builder in python-fu, to allow gtk+ expanders, parameter groups, different layouts and plug-in previews.

Enhance the python console

Add some GUI controls allowing more things to be done from the python prompt with less typing. That could involve creating a utility python module to allow for practical "CAD like" drawing from the python console, by typing short drawing commands.

• Any of these tasks in pygimp could include adding missing Procedural Database calls in the gimp core (for example, not all paint options are accessible through the PDB)

Work on GEGL

mentor: pippin

• GEGL is a graph based image processing framework. It has been introduced into the GIMP trunk after 2.4 has been released. Processing is done by the nodes of the graph, which are implemented as so-called operations or 'ops'. A good introduction to the current state of GEGL is the presentation given at FOSDEM in 2007.

  Possible topics for projects includes:

  • Prototype GEGL backend (with own set of operations) that uses a GPU instead of the CPU for rendering.

  • Networked buffers (and maybe distributed rendering).

  • Create a paint core and related plug-ins. A paint-core is the system used for drawing tools like paintbrush, airbrush, pencil, clone and other paint tools. The core should be made in a way that facilitates integration with a procedural brush system.

  • Frequency domain processing.

  • Any known bug or a number of bugs fixed

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.

UFRaw

mentor: Udi Fuchs

UFRaw is the GIMP plug-in responsible for opening raw files from digital cameras. There are several possible projects for enhancing UFRaw.

100% Zoom

Currently, when previewing the image to be converted, the maximal zoom is 50%. Simply generating the full 100% image will not work, because it take too much time for an interactive process. To implement this option one has to modify UFRaw to generate the 100% image in tiles. Later this feature could be used to multithread the process of generating the image.

User presets

The settings for image conversion can be saves in UFRaw ID files. Later those ID files can be used as presets for converting other images through the use of the command-line. The idea is to allow the user to switch between presets in the GUI. The GUI should give a natural way to modify and apply settings.

Multi-image workflow

Currently UFRaw is concentrated on the workflow for converting a single image. A multi-image workflow would show the user all the images in the directory, let him edit single images or apply presets to a group of images. The actual conversion would be applied in the background with feedback to the user on its progress.

The first two projects would involve substantial changes to the core code of UFRaw and require programming in C, C++. For the third project one might be able to work with a scripting language, such as Python.

All three projects are complicated. I don't think that any of them can be completely finished during the given time frame. Still, it should be possible to make enough progress that will give substantial improvement to UFRaw.

Enhancing Painting with parameter curves

• Currently there are quite a few options to use with the paint tools, however, mapping how these options could vary with pressure, tilt, speed, angle of painting is somewhat limited. A complete tabbed dock, where new curves could be added that would map one input variable to paint option could increase several fold the options available to artists. A request for this is drafted in | bug #119240.

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

Your own proposal

• Feel free to come up with other possible projects - the enhancement proposals in Bugzilla may contain some additional viable project ideas.

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 & Plug-in stability effort

• 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 are seeing as GEGL is introduced.

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.

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.

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. One thing to keep in mind is that the more useful the format is for a large audience, the more likely a project proposal will be accepted. Some interesting examples are MNG and APNG.

• There is a MNG save plug-in, but currently no loader for this file format. In general, the file format is being criticized for being overly complex to become a replacement for the still more common GIF images, which has lead to specifications for subsets of its features. The MNG plug-in needs to be modified to save images in these MNG-LC or MNG-VLC profiles. Then a loader for the less complex files can be easily written to work similar to the GIF loader. It also needs support for JPEG chunks.

• There is no APNG plug-in we know about. There is a set of patches against libpng which might make this task a lot easier. But keep in mind that some people see this image format as an abuse of PNG.

Tasks for these types of project include:

• find a file format which is not yet supported by GIMP

• determine its usefulness

• find the file type specification for this format

• determine what has to be done to add support, e.g. using a library, sample code or code from scratch

• implement loading and saving, including advanced features like paths, guides, layers etc. if supported by the format

• add a suitable UI to the load and save operations, if necessary

• test against many - or all, if possible - variations of the file format

Filetype registration

On every major platform, there is a way for the user to configure which application should handle which types of files. Many file managers will then allow the user to open the file in this application - Text files are opened within a text editor, rich text will open a word processor, and image files in an image viewer or image editor.

Unfortunately, some platforms (like Microsoft Windows) make it rather hard to configure this in a reasonable way. Therefore, many applications have chosen to offer file type association in their own user interface, by providing a list of formats which can be handled. This is done in the installer right now, but is limited to install time and has some other shortcomings. Furthermore, it is quite common for them to steal the types from other applications. It would really be nice to do this in GIMP.

Tasks for this project include:

• add a dialog in GIMP which does provide a way for the user to check which type should open with GIMP

• identify platforms where this can work at all

• add backends for different platforms to make sure that this does happen

Unpaper

Currently, it's not possible with free software to digitalize a book (with text) oneself and to publish the results... because the collection of digitalized pages will be not clean. You can scan it but it's not possible to make automatically basic treatments to beautify the result, i.e :

• remove black borders,

• remove background and keep the letters with an anti aliasing effect,

• detect margin/text zones and crop the picture in a predefined way (margin, picture size, etc...),

• rotate the text to make it perfectly horizontal.

This piece of software is necessary to make from every scanner owner a potential part of the global book digitalization effort. Projects like wikisource would love such a plugin in GIMP.

One software has already this purpose : unpaper ... Unfortunately, it's really complicated to use it, and the result is not perfect : I'm absolutely not convinced by it.