2.3 Function dispatch and plug-ins

(This chapter is on the verge of being deprecated. We have started building a replacement based on GObject, see §2.4.)

As image processing libraries increase in size it becomes progressively more difficult to build applications which present the operations the library offers to the user. Every time a new operation is added, every user interface needs to be adapted — a job which can rapidly become unmanageable.

To address this problem VIPS includes a simple database which stores an abstract description of every image processing operation. User interfaces, rather than having special code wired into them for each operation, can simply interrogate the database and present what they find to the user.

The operation database is extensible. You can define new operations, and even new types, and add them to VIPS. These new operations will then automatically appear in all VIPS user interfaces with no extra programming effort. Plugins can extend the database at runtime: when VIPS starts, it loads all the plugins in the VIPS library area.

2.3.1 Simple plugin example

As an example, consider this function:

The source for all the example code in this section is in the vips-examples package.

The first step is to make a layer over this function which will make it look like a standard VIPS function. VIPS insists on the following pattern:

• The function should be int-valued, and return 0 for success and non-zero for error. It should set im_error().
• The function should take a single argument: a pointer to a NULL-terminated array of im_objects.
• Each im_object represents one argument to the function (either output or input) in the form specified by the corresponding entry in the function’s argument descriptor.

The argument descriptor is an array of structures, each describing one argument. For this example, it is:

IM_INPUT_INT() and IM_OUTPUT_INT() are macros defined in <vips/dispatch.h> which make argument types easy to define. Other macros available are listed in table 2.1.

The argument to the type macro is the name of the argument. These names are used by user-interface programs to provide feedback, and sometimes as variable names. The order in which you list the arguments is the order in which user-interfaces will present them to the user. You should use the following conventions when selecting names and an order for your arguments:

• Names should be entirely in lower-case and contain no special characters, apart from the digits 0-9 and the underscore character ‘_’.
• Names should indicate the function of the argument. For example, im_add() has the following argument names:
  example% vips -help im_add  
  vips: args: in1 in2 out  
  where:  
    in1 is of type "image"  
    in2 is of type "image"  
    out is of type "image"  
  add two images, from package  
    "arithmetic"  
  flags:  
    (PIO function)  
    (no coordinate transformation)  
    (point-to-point operation)

• You should order arguments with large input objects first, then output objects, then any extra arguments or options. For example, im_extract() has the following sequence of arguments:
  example% vips -help im_extract  
  vips: args: input output left top  
    width height channel  
  where:  
    input is of type "image"  
    output is of type "image"  
    left is of type "integer"  
    top is of type "integer"  
    width is of type "integer"  
    height is of type "integer"  
    channel is of type "integer"  
  extract area/band, from package  
    "conversion"  
  flags:  
    (PIO function)  
    (no coordinate transformation)  
    (point-to-point operation)

This function sits over double_integer(), providing VIPS with an interface which it can call:

Finally, these two pieces of information (the argument description and the VIPS-style function wrapper) can be gathered together into a function description.

IM_NUMBER() is a macro which returns the number of elements in a static array. The flags field contains hints which user-interfaces can use for various optimisations. At present, the possible values are:

IM_FN_PIO

This function uses the VIPS PIO system (see §3.3).

IM_FN_TRANSFORM

This the function transforms coordinates.

IM_FN_PTOP

This is a point-to-point operation, that is, it can be replaced with a look-up table.

IM_FN_NOCACHE

This operation has side effects and should not be cached. Useful for video grabbers, for example.

This function description now needs to be added to the VIPS function database. VIPS groups sets of related functions together in packages. There is only a single function in this example, so we can just write:

The package has to be named package_table, and has to be exported from the file (that is, not a static). VIPS looks for a symbol of this name when it opens your object file.

This file needs to be made into a dynamically loadable object. On my machine, I can do this with:

You can now use double.plg with any of the VIPS applications which support function dispatch. For example:

When VIPS starts up, it looks for a directory in the library directory called vips-, with the vips major and minor versions numbers as extensions, and loads all files in there with the suffix .plg. So for example, on my machine, the plugin directory is /usr/lib/vips-7.16 and any plugins in that directory are automatically loaded into any VIPS programs on startup.

2.3.2 A more complicated example

This section lists the source for im_extract()’s function description. Almost all functions in the VIPS library have descriptors — if you are not sure how to write a description, it’s usually easiest to copy one from a similar function in the library.

2.3.3 Adding new types

The VIPS type mechanism is extensible. User plug-ins can add new types and user-interfaces can (to a certain extent) provide interfaces to these user-defined types.

Here is the definition of im_arg_desc:

The name field is the argument name above. The desc field points to a structure defining the argument type, and the print field is an (optionally NULL) pointer to a function which VIPS will call for output arguments after your function successfully completes and before the object is destroyed. It can be used to print results to the terminal, or to copy results into a user-interface layer.

im_type_desc is defined as:

Where im_arg_type is defined as

In other words, it’s just a string. When you add a new type, you just need to choose a new unique string to name it. Be aware that the string is printed to the user by various parts of VIPS, and so needs to be “human-readable”. The flags are:

And the init and destroy functions are:

As an example, here is the definition for a new type of unsigned integers. First, we need to define the init and print functions. These transform objects of the type to and from string representation.

Now we can define the type itself. We make two of these — one for unsigned int used as input, and one for output.

Finally, we can define two macros to make structures of type im_arg_desc for us.

For more examples, see the definitions for the built-in VIPS types.

2.3.4 Using function dispatch in your application

VIPS provides a set of functions for adding new image processing functions to the VIPS function database, finding functions by name, and calling functions. See the manual pages for full details.

Adding and removing functions

This function opens the named file, searches it for a symbol named package_table, and adds any functions it finds to the VIPS function database. When you search for a function, any plug-ins are searched first, so you can override standard VIPS function with your own code.

The function returns a pointer to the package it added, or NULL on error.

This function closes all plug-ins, removing then from the VIPS function database. It returns non-zero on error.

Searching the function database

This function applies the argument function fn to every package in the database, starting with the most recently added package. As with im_list_map(), the argument function should return NULL to continue searching, or non-NULL to terminate the search early. im_map_packages() returns NULL if fn returned NULL for all arguments. The extra argument a is carried around by VIPS for your use.

For example, this fragment of code prints the names of all loaded packages to fd:

VIPS defines three convenience functions based on im_map_packages() which simplify searching for specific functions:

Building argument structures and running commands

These two functions allocate space for and free VIPS argument lists. The allocate function simply calls im_malloc() to allocate any store that the types require (and also initializes it to zero). The free function just calls im_free() for any storage that was allocated.

Note that neither of these functions calls the init, dest or print functions for the types — that’s up to you.

This function does everything. In effect,

is exactly equivalent to

but no process is forked.