Hacking:GSoC/Future/Ideas

From GIMP Developer Wiki
Jump to: navigation, search

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.


Contents

IMPORTANT: Implement GEGL operations for GIMP

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
  • ... and many other things that currently exist in the Filters menu of GIMP.

See Hacking:Porting filters to GEGL for details.

Slicing tool

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

Category: Tools, User-Interface

Proposed in: 2012, 2013

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

Make GIMP more suitable for use in VFX pipelines

Category: Plug-Ins/Scripts

Proposed in: 2013

Upcoming GIMP 2.10 finally provides 16/32bit precision per color channel. However, this is not sufficient to make GIMP play well with other tools like Blender. There is a number of things, one of them — implementing a new GEGL-based GIMP plug-in for working with OpenEXR images. That would involve:

  • writing the code for importing EXR with settings:
    • exposure and gamma (reusable GEGL op is ready)
    • un-premultiply option
    • reading layers
  • writing the code for exporting EXR with settings:
    • format and type
    • compression
    • handling alpha channel
    • storage type
    • image region
    • exporting layers

Another potential task to solve is implementing a way to quickly export sets of layers to a file, which is useful for working on variants of textures.

Minimal Student Requirements:

  • Good C knowledge
  • Highly recommended — some knowledge of GIMP's internals (core/tools/etc.)
  • Highly recommended — being familiar with VFX workflows, OpenEXR

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.

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.

Personal tools