[CREATE] plug-ins

[Øyvind Kolås]

On 4/24/06, Alexandre Prokoudine <alexandre.prokoudine at gmail.com> wrote:
> On 4/24/06, BERGER Cyrille wrote:
> > > 1. How exactly many developers like the idea of having uniform API for plug-ins?
> > me :)
>
> That's a good start :)

The problem with 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. GEGL will 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.

Other efforts to achieve cross application image/video processing
plug-ins already exist, various applications have different needs.
Dataflow(/graph) based designs like GEGL have the advantage that
supporting new types of plug-ins are relativly easy. GEGL will aim to
support legacy 8bit only GIMP plug-ins through an adapter. Such
adapters could also be made for freeframe[1], Frei0r[2], livido[3] and
foobar[4].

1: http://freeframe.sourceforge.net/
2: http://www.piksel.org/Frei0r
3: http://livido.dyne.org/
4: http://pippin.gimp.org/gggl/ops.html
5: insert missing standard effect/filter plug-in architecture here.

> > But, anyway, it's the heart of the problem, plugins often require a
> > configuration widget, and GTK apps will want a GTK widget and Qt apps
> > a Qt widget (and don't forget about wx and fltk ;) ), and we cannot
> > ask all plugins devs to provide a widget for all toolkit. (one
> > solution would be to provide a xml description of widgets (like Qt's
> > ui files) and let the host application transform it to its favorite
> > toolkit widget).
>
> I'm not sure what you mean with a configuration widget. Do you mean
> custom widgets?

For plug-ins to be easily shareable in such a scenario it is important
that parameters and their ranges are discoverable through
introspection. This will be done in GEGL thorugh the use of
gparamspecs. This allows some guaranteed support. Bauxite[6] for
instance the default way is to use simple entries/slider for
strings/doubles. But also allow the host application to recognize the
plug-in and provide a specialized vector widget that controls those
same parameters.

6: http://pippin.gimp.org/bauxite/

> > > 4. Is it possible at all to create a uniform API for plug-ins that
> > > could work e.g. in both Krita and GIMP (and with GIMP I mean upcoming
> > > GEGL-based GIMP) with regard to color management, bit depth (8/16/32
> > > floating point per channel), color spaces etc?
> >
> > And I think you forgot at least one question:
> > 5] what plugins are to be common ? tools ? filters/effects ?
> > colorspaces ? file import/export ? "batch" processing (like
> > kipi-plugins) ?

My answer to question #4 is, yes and no, and it might not even be
neccesary if one of the existing ones could already be adapted to some
of the needs.

/Øyvind Kolås

--
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/