Unified plug-in API
From Create Wiki
Contents |
Unified plug-in API for processing raster images
Problem definition
There are several APIs for plug-ins to process raster images:
- GIMP's API
- Krita's API
- digiKam's API
- KIPI
There are many filters available as plug-ins that are duplicated across APIs. If another application appears, it will either create its own set of plug-ins or use of those four. Creating one unified plug-in API would help developers concentrate on improved functionality rather than reinventing the wheel.
Possible solutions
LADSPA/DSSI way
LADSPA and DSSI are audio plug-in APIs that describe basic functionality, letting host applications draw UI either in native widget set of a host or a plug-in.
Unix way
Good known is the unix pipe facility. One can on the command line combine several commands to form a much more complex task that it would be possible with a single command. Netpbm, exrtools and similar packages rely on such mechanism. The drawback is pipes are not available everywhere and options must often be known in advance. But they are a good example of interaction and independence.
Bottlenecks
- Plug-ins that use custom widgets cannot be fully redrawn in other widget set. Possible solution would be adding a NEED_CUSTOM_UI flag for those demanding custom widgets plug-ins and thus tell hosts to load them in their native widget set, which means that a host application might need static library of the native widget set of that plug-ins.
Annotation: this is only needed for complex user interaction. The majority of plug-ins will simply
expect some parameters and the image to work on. How about swallowing for the exceeding
complex ones? KaiUweBehrmann 06:24, 28 September 2007 (UTC)
- Any such approach is that it caters to the lowest common denominator. This makes such a filter/plug-in/effect framework only suitable for the common subset and is likely to suffer either in quality and performance compared to native plug-ins. Some host applications (e.g. GEGL in GIMP) may demand reference implemententations of >=32bit floating point accuracy, mechanisms for minimizing temporary buffers to reduce computational overhead when rendering subregions, and hopefully even scale invariant/tolerant parameters (as stated by Øyvind Kolås).
Annotation: such bottleneck can easily circumvented by defining the capabilities of each plug-in
during the registration process. Why not create plug-ins which are capable of 8-bit
grayscale only or HDR float or 10-bit subsampled YCbCr?
KaiUweBehrmann 06:24, 28 September 2007 (UTC)
