[next] [prev] [prev-tail] [tail] [up]

### 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:

#include <stdio.h>
#include <vips/vips.h>
/⋆ The function we define. Call this
⋆ from other parts of your C
⋆ application.
⋆/
int
double_integer( int in )
{
return( in ⋆ 2 );
}

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:

/⋆ Describe the type of our function.
⋆ One input int, and one output int.
⋆/
static im_arg_desc arg_types[] = {
IM_INPUT_INT( "in" ),
IM_OUTPUT_INT( "out" )
};

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.

Macro | Meaning | im_object has type

IM_INPUT_INT | Input int | int ⋆
IM_INPUT_INTVEC | Input vector of int | im_intvec_object ⋆
IM_INPUT_IMASK | Input int array | im_mask_object ⋆
IM_OUTPUT_INT | Output int | int ⋆
IM_INPUT_INTVEC | Output vector of int | im_intvec_object ⋆
IM_OUTPUT_IMASK | Output int array to file | im_mask_object ⋆
IM_INPUT_DOUBLE | Input double | double ⋆
IM_INPUT_DOUBLEVEC | Input vector of double | im_realvec_object ⋆
IM_INPUT_DMASK | Input double array | im_mask_object ⋆
IM_OUTPUT_DOUBLE | Output double | double ⋆
IM_OUTPUT_DOUBLEVEC | Output vector of double | im_realvec_object ⋆
IM_OUTPUT_DMASK | Output double array to file | im_mask_object ⋆
IM_OUTPUT_DMASK_STATS | Output double array to screen |
IM_OUTPUT_COMPLEX | Output complex | double ⋆
IM_INPUT_STRING | Input string | char ⋆
IM_OUTPUT_STRING | Output string | char ⋆
IM_INPUT_IMAGE | Input image | IMAGE ⋆
IM_INPUT_IMAGEVEC | Vector of input images | IMAGE ⋆⋆
IM_OUTPUT_IMAGE | Output image | IMAGE ⋆
IM_RW_IMAGE | Read-write image | IMAGE ⋆
IM_INPUT_DISPLAY | Input display | im_col_display ⋆
IM_OUTPUT_DISPLAY | Output display | im_col_display ⋆
IM_INPUT_GVALUE | Input GValue | GValue ⋆
IM_OUTPUT_GVALUE | Output GValue | GValue ⋆
IM_INPUT_INTERPOLATE | Input VipsInterpolate | VipsInterpolate ⋆

Table 2.1: Argument type macros

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:

/⋆ Call our function via a VIPS
⋆ im_object vector.
⋆/
static int
double_vec( im_object ⋆argv )
{
int ⋆in = (int ⋆) argv[0];
int ⋆out = (int ⋆) argv[1];
⋆out = double_integer( ⋆in );
/⋆ Always succeed.
⋆/
return( 0 );
}

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

/⋆ Description of double_integer.
⋆/
static im_function double_desc = {
"double_integer",
"double an integer",
0,
double_vec,
IM_NUMBER( arg_types ),
arg_types
};

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:

/⋆ Group up all the functions in this
⋆ file.
⋆/
static im_function
⋆function_list[] = {
&double_desc
};
/⋆ Define the package_table symbol.
⋆ This is what VIPS looks for when
⋆ loading the plugin.
⋆/
im_package package_table = {
"example",
IM_NUMBER( function_list ),
function_list
};

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:

example% gcc -fPIC -DPIC -c
‘pkg-config vips-7.12 --cflags‘
plug.c -o plug.o
example% gcc -shared plug.o
-o double.plg

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

example% vips -plugin double.plg \
double_integer 12
24
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.

/⋆ Args to im_extract.
⋆/
static im_arg_desc
extract_args[] = {
IM_INPUT_IMAGE( "input" ),
IM_OUTPUT_IMAGE( "output" ),
IM_INPUT_INT( "left" ),
IM_INPUT_INT( "top" ),
IM_INPUT_INT( "width" ),
IM_INPUT_INT( "height" ),
IM_INPUT_INT( "channel" )
};
/⋆ Call im_extract via arg vector.
⋆/
static int
extract_vec( im_object ⋆argv )
{
IMAGE_BOX box;
box.xstart = ⋆((int ⋆) argv[2]);
box.ystart = ⋆((int ⋆) argv[3]);
box.xsize = ⋆((int ⋆) argv[4]);
box.ysize = ⋆((int ⋆) argv[5]);
box.chsel = ⋆((int ⋆) argv[6]);
return( im_extract(
argv[0], argv[1], &box ) );
}
/⋆ Description of im_extract.
⋆/
static im_function
extract_desc = {
"im_extract",
"extract area/band",
IM_FN_PIO | IM_FN_TRANSFORM,
extract_vec,
NUMBER( extract_args ),
extract_args
};

#### 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:

/⋆ Describe a VIPS command argument.
⋆/
typedef struct {
char ⋆name;
im_type_desc ⋆desc;
im_print_obj_fn print;
} 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.

/⋆ Success on an argument. This is
⋆ called if the image processing
⋆ function succeeds and should be
⋆ used to (for example) print
⋆ output.
⋆/
typedef int (⋆im_print_obj_fn)
( im_object obj );

im_type_desc is defined as:

/⋆ Describe a VIPS type.
⋆/
typedef struct {
im_arg_type type;
int size;
im_type_flags flags;
im_init_obj_fn init;
im_dest_obj_fn dest;
} im_type_desc;

Where im_arg_type is defined as

/⋆ Type names. You may define your
⋆ own, but if you use one of these,
⋆ then you should use the built-in
⋆ VIPS type converters.
⋆/
#define IM_TYPE_IMAGEVEC "imagevec"
#define IM_TYPE_DOUBLEVEC "doublevec"
#define IM_TYPE_INTVEC "intvec"
#define IM_TYPE_DOUBLE "double"
#define IM_TYPE_INT "integer"
#define IM_TYPE_COMPLEX "complex"
#define IM_TYPE_STRING "string"
#define IM_TYPE_IMASK "intmask"
#define IM_TYPE_DMASK "doublemask"
#define IM_TYPE_IMAGE "image"
#define IM_TYPE_DISPLAY "display"
#define IM_TYPE_GVALUE "gvalue"
typedef char ⋆im_arg_type;

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:

/⋆ These bits are ored together to
⋆ make the flags in a type
⋆ descriptor.
⋆
⋆ IM_TYPE_OUTPUT: set to indicate
⋆ output, otherwise input.
⋆
⋆ IM_TYPE_ARG: Two ways of making
⋆ an im_object --- with and without
⋆ a command-line string to help you
⋆ along. Arguments with a string
⋆ are thing like IMAGE descriptors,
⋆ which require a filename to
⋆ initialise. Arguments without are
⋆ things like output numbers, where
⋆ making the object simply involves
⋆ allocating storage.
⋆/
typedef enum {
IM_TYPE_OUTPUT = 0x1,
IM_TYPE_ARG = 0x2
} im_type_flags;

And the init and destroy functions are:

/⋆ Initialise and destroy objects.
⋆ The "str" argument to the init
⋆ function will not be supplied
⋆ if this is not an ARG type.
⋆/
typedef int (⋆im_init_obj_fn)
( im_object ⋆obj, char ⋆str );
typedef int (⋆im_dest_obj_fn)
( im_object obj );

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.

/⋆ Init function for unsigned int
⋆ input.
⋆/
static int
uint_init( im_object ⋆obj, char ⋆str )
{
unsigned int ⋆i = (int ⋆) ⋆obj;
if( sscanf( str, "%d", i ) != 1 ||
⋆i < 0 ) {
im_error( "uint_init",
"bad format" );
return( -1 );
}
return( 0 );
}
/⋆ Print function for unsigned int
⋆ output.
⋆/
static int
uint_print( im_object obj )
{
unsigned int ⋆i =
(unsigned int ⋆) obj;
printf( "%d\n", (int) ⋆i );
return( 0 );
}

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

/⋆ Name our type.
⋆/
#define TYPE_UINT "uint"
/⋆ Input unsigned int type.
⋆/
static im_type_desc input_uint = {
TYPE_UINT, /⋆ Its an int ⋆/
sizeof( unsigned int ),/⋆ Memory ⋆/
IM_TYPE_ARG, /⋆ Needs arg ⋆/
uint_init, /⋆ Init ⋆/
NULL /⋆ Destroy ⋆/
};
/⋆ Output unsigned int type.
⋆/
static im_type_desc output_uint = {
TYPE_UINT, /⋆ It's an int ⋆/
sizeof( unsigned int ),/⋆ Memory ⋆/
IM_TYPE_OUTPUT, /⋆ It's output ⋆/
NULL, /⋆ Init ⋆/
NULL /⋆ Destroy ⋆/
};

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

#define INPUT_UINT( S ) \
{ S, &input_uint, NULL }
#define OUTPUT_UINT( S ) \
{ S, &output_uint, uint_print }

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

im_package ⋆im_load_plugin(
const char ⋆name );

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.

int im_close_plugins( void )

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

##### Searching the function database

void ⋆im_map_packages(
im_list_map_fn fn, void ⋆a )

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:

static void ⋆
print_package_name( im_package ⋆pack,
FILE ⋆fp )
{
(void) fprintf( fp,
"package: \"%s\"\n",
pack->name );
/⋆ Continue search.
⋆/
return( NULL );
}
static void
print_packages( FILE ⋆fp )
{
(void) im_map_packages(
(im_list_map_fn)
print_package_name, fp );
}

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

im_function ⋆
im_find_function( char ⋆name )
im_package ⋆
im_find_package( char ⋆name )
im_package ⋆
im_package_of_function( char ⋆name )

##### Building argument structures and running commands

int im_free_vargv( im_function ⋆fn,
im_object ⋆vargv )
int im_allocate_vargv(
im_function ⋆fn,
im_object ⋆vargv )

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.

int im_run_command( char ⋆name,
int argc, char ⋆⋆argv )

This function does everything. In effect,

im_run_command( "im_invert", 2,
{ "fred.v", "fred2.v", NULL } )

is exactly equivalent to

system( "vips im_invert fred.v "
"fred2.v" )

but no process is forked.

[next] [prev] [prev-tail] [front] [up]