Von: "Amit Kumar Saha"

Is there any way to make GIMP plugins themselves extensible. My point here is that, can we make a GIMP plugin which allows itself modifiable by a end-user to include a new functionality without much of a hassle on part of the end-user. Does any one know of a method to do this or any GIMP plugin which already does this?

Should it be more easy than writing e.g. a plug-in in Python?

HTH, Michael

Von: "Amit Kumar Saha"
Is there any way to make GIMP plugins themselves extensible. My point here is that, can we make a GIMP plugin which allows itself modifiable by a end-user to include a new functionality without much of a hassle on part of the end-user.

The trick here isn't creating an extensible plugin. The trick is defining what "without much hassle on the part of the end-user" really means. Who's the end user? Joe Artist or Edward Engineer? Sven's granny or a bunch of kernel developers?

In general, making a piece of software extensible requires two main components: a grammer understandable by the core software and an API accessible through that grammer to core functionality. One problem you'll have to address is what parts of the API are visible to the plugins and what parts are not.

To make a piece of software extendable you could ignore the API portion and create a simple grammer that end users could use to essentially configure the plugin. Imagine a simplistic scripting language that simply sets a bunch of variables that the main plugin normally requires you to set manually using a series of dialogs or tabs. Wouldn't even require anything as complex as Perl or Python - it could just be a series of name/value pairs. But this isn't really extension, its configuration.

More complex examples would include exactly what GIMP already does with it's language extensions. You can load a dll easily enough or embed an interpreter like Perl or Python. But is programming in Perl or Python "easy" to your end user? A more common approach these days is to allow extension via XML. You can easily embed an XML parser into a plugin (I've used libXML2 in my plugins to save configuration data). But then you have to decide if writing XML by hand is easy for your users. Not to mention defining the XML Schema or DTD for the language. In the end, though, what you've done is create a new programming language. If you're doing that, and started with the intention of making it easy to use, you might as well use a well known language like Perl or Python instead.

You could provide a series of core features in the plugin that could be used in a reorderable stack and then build a GUI that used drag and drop to rearrange that stack. Sort of like arranging a series of existing plugins to be run in any given order. The plugin would then process in the order defined by the stack. The problem here is that you're simply providing a mechanism for using existing features, not allowing the user to extend that feature set.

So before you decide on the mechanism, you have to define who will use it and what you're really trying to allow them to do.

Does any one know of a method to do this or

any GIMP plugin which already does this?

I'm not aware of any plugins that provide this though it wouldn't suprise me if someone had already done something similar. Plugin interfaces are a standard part of many applications these days but I think you'd be hard pressed to find any that don't require some level of programming expertise to use.

Amit Kumar Saha wrote:

Is there any way to make GIMP plugins themselves extensible.

[snip]

I would appreciate even the slightest of insights.

As Michael mentioned, using a scripting language such as Perl, Python, or Ruby would be to do most things you might want to do. If you want to extend a compiled plug-in that is also possible.

Take a look at TinyScheme (used in the Script-Fu plug-in of the SVN version of GIMP). It has the ability to use run-time loadable pre-compiled extensions. The URL for TinyScheme is http://tinyscheme.sourceforge.net/.

The other scripting language plug-ins for GIMP also have ways to extend the base language. The hooks used to allow scripts to tie in to GIMP use them.

Karl Günter Wünsch wrote:

On Tuesday 21 August 2007, Michael Schumacher wrote:

Should it be more easy than writing e.g. a plug-in in Python?

How about having a C++ virutal interface which you only have to fill in with your own methods and GUI elements in a set dialog interface... I have several things that I really would like to try and would require a native compiled plugin.
But since there is no sound C++ interface to the innards of the GIMP :-(...

There is no sound C++ interface for only one reason: nobody has written it yet.

It should be fairly easy, especially since the C library GIMP builds upon was designed specifically to be easy to write wrappers for (GObject).

- Martin Nordholts

On Tuesday 21 August 2007, Michael Schumacher wrote:

Should it be more easy than writing e.g. a plug-in in Python?

How about having a C++ virutal interface which you only have to fill in with your own methods and GUI elements in a set dialog interface... I have several things that I really would like to try and would require a native compiled plugin.
But since there is no sound C++ interface to the innards of the GIMP :-(...

On Tue, 21 Aug 2007 15:48:15 +0530, "Amit Kumar Saha" wrote:

Is there any way to make GIMP plugins themselves extensible. My point here is that, can we make a GIMP plugin which allows itself modifiable by a end-user to include a new functionality without much of a hassle on part of the end-user. Does any one know of a method to do this or any GIMP plugin which already does this?

Besides the scripting languages mentioned by others, you could also take a look at the MathMap plug-in if you are good at math...

MathMap home page: http://www.complang.tuwien.ac.at/schani/mathmap/

Nice examples of MathMap usage: http://www.flickr.com/groups/mathmap/

-Raphaël

Amit Kumar Saha wrote:

Here is another way I thought I could give some form of "extensibility" to a plugin user. Say, that I want my plugin to be a single entry point to all the Image processing operations possible with GIMP.

Now your plug-in seems to become something I'd call GIMP. What use cases are you trying to handle, actually?

Regards, Michael

Amit Kumar Saha wrote:

Am i thinking in a way that could possibly be implemented? or is the word "extensible" remotely applicable to my idea?

So what you're talking about here is a graphical interface to the API that a user can use to build his own extensions? Essentially, it's a graphical programming language. There are quite a few examples of these in the music world that allow the construction of modular synths (amongst other things).

It sounds to me more like a separate companion program that's used to construct plug-ins than a plug-in itself. I like the idea very much.

---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---

Em Qua, 2007-08-22 às 23:19 +0100, David Marrs escreveu:

It sounds to me more like a separate companion program that's used to construct
plug-ins than a plug-in itself. I like the idea very much.

Same with me; I would love something like a node-based editor (e.g. http://pupuedit.sourceforge.net/screenshots/pihlaja_04_04_2007.png and http://imaginit.rand.com/files/water_graph.gif )

This would let non-programmers, or programmers which aren't into image processing, create their own plug-ins.

On Wed, 22 Aug 2007 23:19:30 +0100, David Marrs wrote:

Amit Kumar Saha wrote:

Am i thinking in a way that could possibly be implemented? or is the word "extensible" remotely applicable to my idea?

So what you're talking about here is a graphical interface to the API that a user can use to build his own extensions? Essentially, it's a graphical programming language. There are quite a few examples of these in the music world that allow the construction of modular synths (amongst other things).

Not only in the music world. Around 1993 or so, I remember using a program called Khoros Cantata to design some image filters. A quick search on the web returned this tutorial with screenshots of the old X11 version that I used:
http://www.cse.psu.edu/~cg585/cantata-over.html Just imagine that the glyphs (the boxes that can be connected) could be the operations that GIMP offers through the PDB.

It seems that Khoros Cantata has been acquired at least twice by different companies, has been ported to Windows, and is now sold as Accusoft VisiQuest:
http://www.accusoft.com/products/visiquest/overview.asp The interface has changed a bit, but it is still based on the same ideas of connecting glyphs providing various functions.

By the way, this brings back some memories about what I did in 1993 as an exercise for a course in digital imaging. Students were asked to write a new filter for Khoros and use it to perform some interesting image transformations. I decided to write a filter that would use various correlation methods to reconstruct an image in which the lines were shifted horizontally by some random amount. The default method was optimized for "un-shifting" images at TV resolution (PAL) that were shifted by one of three predefined offsets picked at random. The method worked surprisingly well. The code and the results were presented to the professor. He asked if, by any chance, this could be used to decode Canal+ images (a pay TV channel that was popular in several European countries). And the answer was yes. Not in real time because the 486 processors that were common at that time were not fast enough, but the method worked well with recorded TV streams (sometimes even without using inter- frame correlations). Ah, I still have fun when I remember this and when I consider that the professor gave one of the top marks for this exercise.

-Raphaël

On 8/23/07, David Marrs wrote:

Amit Kumar Saha wrote:

Am i thinking in a way that could possibly be implemented? or is the word "extensible" remotely applicable to my idea?

So what you're talking about here is a graphical interface to the API that a user can use to build his own extensions? Essentially, it's a graphical programming language. There are quite a few examples of these in the music world that allow the construction of modular synths (amongst other things).

It sounds to me more like a separate companion program that's used to construct plug-ins than a plug-in itself. I like the idea very much.

In some ways, this is essentially what /meta operations/ in GEGL is about, at the moment they are written in C, but they could just as well be created with an XML syntax and edited in a graph based environment. See GEGL (http://www.gegl.org/) and bug #465743.

/Øyvind K.

Renan Birck wrote:

Same with me; I would love something like a node-based editor (e.g. http://pupuedit.sourceforge.net/screenshots/pihlaja_04_04_2007.png and http://imaginit.rand.com/files/water_graph.gif )

This would let non-programmers, or programmers which aren't into image processing, create their own plug-ins.

That looks similar to the types of things one can do with GEGL which is due to be integrated in to GIMP after the 2.4 release.

On Sat, 25 Aug 2007 12:19:44 +0200, Amit Kumar Saha wrote:

Hi Raphael,

On 8/23/07, Raphaël Quinet wrote:

On Wed, 22 Aug 2007 23:19:30 +0100, David Marrs wrote:
Not only in the music world. Around 1993 or so, I remember using a program called Khoros Cantata to design some image filters. A quick search on the web returned this tutorial with screenshots of the old X11 version that I used:
http://www.cse.psu.edu/~cg585/cantata-over.html

The link is dead.Any chance you have some docs with you?

Regards

google
Khoros Cantata

Amit Kumar Saha wrote:

The others were about the commercial products that uses that concept of "glyphs". Though i got a vague idea of what it was, but more information is desired.

Most systems used for creating visual effects for movies are node-based, and have been for over a decade. Look at Nuke (http://www.thefoundry.co.uk/promo/nuke.html) or Shake (http://www.apple.com/shake/) for current examples.

Amit Kumar Saha wrote:

The link is dead.Any chance you have some docs with you?

The last version of the page (from Feb. 08, 2005) can be found at: http://web.archive.org/web/20050208090913/http://www.cse.psu.edu/~cg585/cantata-over.html

About half of the images on that page are missing.

On 8/26/07, Amit Kumar Saha wrote:

2. Can I work with the individual pixels of an Image using GEGL? Say I want GEGL to work with only certain range of pixels of my Image, is it possible?

You mean a certain area of your image, rather than all of it? You would do that using the 'crop' operation (and you would later layer the result on top of the original image with a 'clear' operation to clear the area, and a 'normal' operation to overlay the result)

On 8/26/07, Amit Kumar Saha wrote:

Also, I would like to know, when GEGL is integrated into the GIMP, will it be available for the Plugins to access the GEGL as well?

The plan is that GEGL integration into GIMP will start after 2.4 is released and the 2.5 development cycle will be devoted to a process of gradual replacement, without changing the GUI significantly, thus 2.6 should be a version of GIMP that hasn't changed a lot of the GUI, but a development cycle that leads up to a GEGLified version of GIMP that can see further development and innovation.

According to the plan GEGL will replace all code in the GIMP that is accessing and or modifying pixels, some forms of GIMP plug-ins will most likely be entirely replaced by GEGL plug-ins instead. And as mentioned elsewhere in this thread, GEGL plug-ins can either be descriptions of graphs, or actual C code. Another option that should already be possible if someone is thus inclined, is actually to write a GIMP plug-in for GIMP 2.4 that allows GEGL plug-ins to be used directly by current versions of GIMP, this is less interesting than another bridge that will have to be written, which is a wrapper for (at least some of) the exisitng GIMP plug-ins to work from within GEGL, this will be needed to provide legacy support for some of the older plug-ins (these plug-ins will thus still work, but have limitations wrt bit-depth and such).

/Øyvind K.

Amit Kumar Saha wrote:

1. It seems from the documentation that, I can specify the operations as a XML file as above instead of creating a DAG. How do i then use that file to apply the operations?

Looking again at the API there is the gegl_parse_xml() routine. There is an example of XML code being used to specify a set of operations to be performed as well as the execution of those operations in the gegl binary file (found in the gegl source tree).

> What about error checking? What operations are supported?

I haven't tried this recently. I'm not sure what happens if there are errors in the input XML file. You may get either an incomplete GeglNode structure (ie. one not containing all parts of the input XML) or NULL. The API doc doesn't specify which. All GEGL operations can be used in an XML file.

2. Can I work with the individual pixels of an Image using GEGL? Say I want GEGL to work with only certain range of pixels of my Image, is it possible?

I din't think it is possible to work on individual pixels of an image. Øyvind Kolås would be the person who could give you the more definite answer on this.