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

From GIMP Developer Wiki
Jump to: navigation, search
(Slicing tool: move to GSoC 2013)
(Add GEGL contribution site from GSOC 2012)
Line 1: Line 1:
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.
You may also want to take a look at the [[Mindstrom:Misc TODO's]] and [http://gegl.org/contribute.html the GEGL contribution site] - some of the projects there are big, and can maybe be incorparated as a part of some GSoC student's work.
=== IMPORTANT: Implement GEGL ops that GIMP need===
=== IMPORTANT: Implement GEGL ops that GIMP need===

Revision as of 20:08, 25 May 2013

You may also want to take a look at the Mindstrom:Misc TODO's and the GEGL contribution site - some of the projects there are big, and can maybe be incorparated as a part of some GSoC student's work.

IMPORTANT: 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.
  • Stretch HSV
  • Decompose/Compose
  • Alien map
  • Gradient map (needs gradient support)
  • Palette map
  • Rotate colors
  • sample colorize
  • channel mixer
  • Motion blur
  • ... and many other things that currently exist in the Filters menu of GIMP.

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.

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

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

Category: Plug-Ins/Scripts

Mentor: Martin Nordholts 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)

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

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

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

Older Ideas for GSoC

Note: Ideas listed in this section may be 100% relevant, 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.

Test framework

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.

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.


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.