About Plug-ins and Filters

Table of Contents

About

This is a general discussion of aspects of plugins.

Read this if you are new to GIMP and want to develop a filter or plugin.

This is an overview, short on details. It explains terminology.

Disambiguation

In the context of image processing, the words “filter” and “plugin” are often used as synonyms.

In the context of software applications, the words “plugin” and “extension” are often used as synonyms. They are software, installed separately, that extend an application. For example, most browser applications let user’s install extensions.

In the context of GIMP:

  • Filter: a GEGL filter extension, aka operation, usually non-destructive
  • Plugin: other extensions, that are programs
  • Resource: extensions that are data, such as brushes

You might classify like this:

Extension
  Resource / Data:  brush, font, gradient, palette, pattern
  Programs:
    GEGL Filters
    Plugins

Uses or roles of plugins and filters

  • image processing algorithms i.e. effects (or filters)
  • scripting i.e. programming or automating workflow
  • load/save i.e. exporting or importing image files in various formats
  • browsers (e.g. the PDB Browser)
  • other (e.g. the GFig plugin, an editor application)

The word “filter” has a generic meaning: alter an image. Plugins can be filters in that sense, but not all Plugins are filters.

Most load/save plugins are written in C. But the one for the OpenRaster format is in Python.

Most scripting plugins are in an interpreted language such as Python or Scheme, but see “Sequencing.”

Sequencing

Many plugins and filters are just sequences of primitive filters or plugins. A plugin may abstract away the steps, and choices of parameters of the primitives.

You can think of them as recipes. You might find a tutorial describing a sequence of steps, and want to automate it.

Sometimes “scripting” means writing such a plugin that performs a simple sequence. Not all “scripts” do just simple sequencing.

Most such sequencing plugins are written in an interpreted language.

Many GEGL Filters are primitive operations. But GEGL supports sequences, or more generally a graph, of operations.

Loading

  • Plugin: loaded by the GIMP app
  • Filter: loaded by the GEGL library

A Plugin can only be used with the GIMP app.

A GEGL Filter can be used with other applications that use the GEGL library.

GEGL Filters are installed with GIMP and can appear as menu items in the GIMP app.

Non-Destructive

  • non-destructive: applied to an image but users can tweak parameters later.
  • destructive: has all-or-nothing effect, but users can undo

Most GEGL Filters are non-destructive. Most Plugins are destructive, or it does not pertain.

Non-destructive filters are sometimes called “effects” or “fx” for short.

A user can undo a destructive plugin, but then they need to start over, that is, apply the plugin again.

Run Mode, Interactive versus Non-Interactive

Every filter and plugin has a “run mode.” The run mode is an argument to the plugin or filter. It tells whether the user is present to control the plugin, i.e. whether the plugin should present a GUI dialog. Also know as “interactive versus non-interactive.”

When a user is processing images in batches, they want filters to run in non-interactive mode. You can run the GIMP app from the command line, invoking plugins and filters, to process images non-interactively.

Some filters and plugins never ask a user to control. The plugin still gets the run mode argument. A well-behaved plugin should respect the given run mode argument.

Settings

Most filters and plugins have parameters. The set of parameters that a user actually chooses are kept for the next session, as “settings” sometimes called “preferences.”

The settings are kept for the next session of the plugin, and for the next session of the GIMP app.

The parameters usually have “factory” defaults. A user can reset the settings to their defaults.

Programming Languages

  • GEGL Filters: usually in C or a similar low-level programming language
  • Plugins: in C or in a high-level language, often interpreted

GEGL Filters are usually written in C for performance.

  • interpreted languages for plugins: Python, Scheme, Lua, Javascript
  • compiled languages for plugins: C, C++, Vala

When your favorite language has a module for GObject Introspection, you can use the language to program a plugin for GIMP. A problem is that often such modules, e.g. for the Lua and Javascript languages, are not portable across platforms.

Support for Lua and Javascript is experimental

Long ago, you could write plugins in the Perl language.

Binding

This describes how a programming language binds or links to GIMP and GEGL libraries. A binding lets a high-level language call a C library. A linker links C programs together into an executable.

  • GEGL filter: links to the GEGL library, libgegl. The filter and the library are both C libraries. No binding required.
  • C plugin: links to the GIMP library, libgimp. No binding required.
  • Python plugin: loads the pygobject module and run-time binds to GIMP or GEGL or Gtk/GLib/Gio or other libraries using GObject Introspection.
  • ScriptFu/Scheme plugin: uses a custom, run-time binding to the GIMP PDB (not to libgimp.) No linking required.

Parties

  • First-party: the GIMP project. GIMP developers i.e. project members maintain, translate, and test. Installed with GIMP. Updated with an update to GIMP. Source code kept in the main GIMP repository.

  • Third-party: developed by others. Installed separately by users. Not updated by, but usually not harmed by, an update to GIMP. Often installed private to a user, not shared by users of a machine.

Some third-party plugins are kept in public repositories. For example, the G’Mic plugin. Such third-parties may also distribute packaged plugins.

Distribution and Packaging

The usual form is:

  • binaries or libraries: GEGL filters and plugins written in C
  • text files: plugins written in an interpreted language such as Python or Scheme
  • sandboxed or universal: plugins that a third-party has packaged, flatpak or snap
  • installer: plugins that a third-party has bundled into an installer

Most users are not prepared to build (compile) plugins from source written in low-level languages. Building is too complicated.

Some users are able to install plugins written in interpreted languages, the source is text files.

Acquisition and Installation

  • interpreted plugins: users download the text source and install it themselves
  • binary plugins: users download a binary from a trusted source and install it themselves, or download an installer.

A typical problem for users is to also install any packages a plugin depends on. For example, a plugin written in Python may require a particular version of the Python interpreter, or a particular Python module.

Another problem for users is that they expect to install with one click, without needing adminstrative permissions and skills.

Modern apps let users install extensions from within the app, across the net. For example, there might be an “Extensions” button in the app. The GIMP app does not yet support that.

Some third-party GIMP plugins are packaged as flatpaks. Users can use the flatpak app to install such plugins from the trusted FlatHub site.

The best way to insure your plugin is widely distributed is first, to make it useful to a large audience, and then to make it of such high quality that you can persuade the GIMP project to adopt and maintain it.

Internationalization or i18n

Plugin can appear in the native language of the user.

GIMP uses the “gettext” system for i18n.

Support is built into the GIMP library.

A plugin that is internationalized requires additional build and installation steps.

Security

Some platforms are more locked down than others.

Some platforms require software in binary form to be signed before installation. Alternatively, the platform may allow exceptions to that rule. Many users may not know how to permit an exception.

Signing on an Apple platform requires a developer to have an Apple Developer Account.

The GIMP project signs packages as required.

History

In GIMP version 2, plugins written in Python used the PyGimp module. That was a custom binding from Python to libgimp. It used Python 2, which is no longer supported.

In GIMP version 2, many filters that are now GEGL Filters were just plugins in C. During the development of GIMP version 3, they were moved to the GEGL project.

Formerly, there were web sites that let you download filters and plugins. For example GIMP Registry Now that is rare, because of increased security concerns and lack of resources i.e. time and money.

In GIMP version 2, much of the behavior of plugins was scattered in many implementations. Since GIMP version 3, the behaviors are implemented in fewer places, for example the Plugin class of the GIMP library. Example of behaviors that were scattered are the look-and-feel of dialogs, and the implementation of settings. Formerly they were implemented separately in PyGimp and ScriptFu, and in many individual plugins.