Hello

I am trying to find some sort of a very basic tutorial how to call common pdb actions (like levels, saturation etc) inside a C plugin.

The only C tutorials I can find, are low level, messing with each pixel values, something I am not interested in.

I have some experience in writing python and script-fu plugins but none in c.


Any help is appreciated

John

Any procedure that is available in the PDB should be available as a function in libgimp (libgimp is the interface that C plug-ins use to communicate with GIMP).

For example, 'gimp-levels' as listed in the PDB Browser should be available as gimp_levels() in your C plug-in, and receive the same parameters and return the same values as specified in the PDB Browser.

First question : Why do you want to implement your functionality as a C plugin?
If your intention is to use Gimp's standard built-in tools such as Levels and Saturation (or other plugins such as Gaussian Blur) as the main workhorse of your processing, then going to C won't provide anything that cannot be done just as well (and much more easily) in Python, Perl or even Script-Fu.
One normally only "drops-down" to C for three reasons:
a. Speed in pixel-level manipulation (using Gimp's tile-caching and pixel-regions)
b. Speed in other intensive computation
c. Preview window
In your case, you say you're not interested in pixel-level manipulation, so that rules out a.
If what you're really after is a preview window then I'm afraid you're going to be sorely disappointed - all of these standard Gimp tools and plugins operate only upon Gimp "drawables" such as the active layer in your input image (or upon a selection therein) - they do NOT operate directly on preview windows (which are GTK widgets) and AFAIK there is no easy way to use such tools/plugins to prepare a preview. (The assumption is that if you're doing something as a C plugin you will be doing the pixel-level manipulation yourself using pixel-regions and your "render" routine should send the output region either to the preview window or the output drawable as appropriate.)

So, unless you have some sort of application-specific intensive computing to do (other than pixel-level manipulation), there is probably no benefit to be had in going to C.

If, despite the foregoing, you still want to use C, then yes (as Saul Goode said) the standard Gimp tools are all available as C functions with the same name as used in the PDB except with underscores instead of hyphens, so for example the PDB procedure "gimp-levels" can be called directly as "gimp_levels()" and "gimp-hue-saturation" can be called as "gimp_hue_saturation()" with the appropriate arguments.
...see: http://developer.gimp.org/api/2.0/libgi ... color.html
Other plugins can be invoked using "gimp_run_procedure()".
...see http://developer.gimp.org/api/2.0/libgi ... -procedure

Edit:
Further to the above comments about previews.. if the processing you want to do is pretty much instantaneous (as it is with Levels and Saturation, but not long-running plugins like map-object!) you might consider using the input/output drawable as your preview in the same way that most of Gimp's built-in <Image>Colors tools do (eg. when you use Color>Levels the image in the main image window is updated in real-time as you change the settings). I think that is reasonably do-able.
If that would suit your needs let me know and I'll see if I can provide you with a suitable C template.

You might find this example useful.
https://mail.gnome.org/archives/gimp-de ... 00008.html

I should clarify my statement. As jontait2 and GNUtux suggest, other plugins and scripts (which are registered in the PDB) should be invoked with the gimp_run_procedure() function. It is only the PDB procedures in the 'gimp' namespace (i.e., begin with "gimp-") that have libgimp functions available for making direct calls.

jontait2 thank you for the detailed response and the insight on the subject. I am mostly after case c, the faster preview, with or without the preview box.

Specifically, I am examining the amount of work required in porting my Color Grading plug-in (http://registry.gimp.org/node/26187) in C. This plugin applies levels three times, one in each color primary (RGB), and then depending the user input a saturation filter.

So based on your input, I guess preview box is not an option unless I recreate the levels and saturation algorithm myself and then paint in GTK widget. So I am pretty much left with using the whole drawable as a preview right?

If you can provide a very basic C template to build upon that would be very nice.

Τhank you saulgoode and GnuTux for your input.

Did you try the online doc?
http://developer.gimp.org/writing-a-plu ... index.html
the code
http://developer.gimp.org/writing-a-plug-in/3/myblur5.c

@John:
I don't really see any reason why this shouldn't be done in Python!

I've had a look at your Color Grading script and, as far as I can see, all you want to do is to update your existing "in-situ" preview (in the image stack) whenever the user makes any changes to the settings in the "Color Wheels" tab or loads a new profile. And that just means connecting the appropriate "signals".
So as a quick test I've hacked your script thus:

This just connects signals from the slider/spinners to invoke your preview display routine each time a value is changed.
And it works!

At the moment, of course, the preview routine works on a toggle basis, alternately removing the current preview (if there is one) and creating a new preview. So, connecting signals as above, the preview is only displayed on alternate clicks, but with a little re-arrangement I think you can get the immediacy of a "live-updated" preview that you wanted.

The net result is basically the same as I was going to provide as a C template and works at very much the same speed (which is determined by the Gimp operations).

If you want to try this approach, a few other thoughts:
- You'll have to connect signals for the Color Wheels and "Load Config" button as well;
- I think you should include an "update preview live" checkbutton so that the updating can be disabled by the user, especially on large images;
- I think you may have to do something a bit different with the undo history (though I haven't looked at this in any great detail yet) ..at the moment it's generating two undo items for every preview change ..that could amount to an awful lot if the user keeps playing around with the settings!

Cheers.

@John:
I've had another play with this
..connected up the ColorWheels, Reset button and Load Profile so they all update the preview
..amended the preview routine to always update the preview (rather than toggle)
..also frozen the undo history during the preview changes so that it doesn't eat up huge amounts of disk space while you're tinkering with the settings.

It all seems to work pretty well, at least with small to medium-sized images ..gets rather slow with large images as you might expect ..which is why I think you need an "update preview live" toggle.

I've marked all my changes with "*JT*" .. have a play with it and see what you think.

@jontait2:
I was going to play with the code today but I see you have already done quite some job on the issue! Thank you! I have tweaked the preview toggle so now it's working in the way you proposed.

Unfortunately in my Archlinux installation both the original v155 and the last tweaked version has a serious issue causing the plugin to stop. Some sort of pixbuf issue with the X causes the crash and no real info is given in the terminal. Maybe something with the colorwheell redraw. I have to further lookup on this issue. This must be some isolated issue on archlinux.

In windows works like a charm! I will probably integrate the functionality on my other plugins as well!

@John
I like what you did with the "Preview" button ..much better than a little checkbox!

Just a few minor niggles with this otherwise laudable filter:

1. Dialog window transience
Like many other non-Fu Python plugins, Color Grading tends to disappear from view ..eg. if you click on the Gimp main window or any of the other dialogs, the plugin dialog disappears and you have to go to your task bar to try to retrieve it. (And, of course, it can easily get forgotten about ..lost under the avalanche of windows strewn across your desktop!)
This can be easily rectified just by invoking immediately after creating the dialog window.
[set_transient() makes the dialog a transient child of the main window, rather than an independent process and the underlying windows manager(s) (ie. X/Linux/Windows/OSX/etc) should then keep the dialog on top of the Gimp main window. So, if Gimp is visible, the dialog should be too. Python Fu plugins (ie. those that import gimpfu) have this done for them automatically if and when gimpfu.py creates the dialog window; non-Fu plugins are responsible for doing it themselves if and when appropriate.]

2. ColorWheel Mouse clicks
If you click on a ColorWheel without actually dragging the mouse, the position indicator does not actually move to the new position. This is because your code is only processing the mouse-move events and not button-presses. I've amended the code in the attached zip.

3. The GUI dialog is, IMHO, rather let down by the ragged edges on the ColorWheels. Since this image is simply imported from PNG file (rather than being generated from scratch at run-time), I would have thought the obvious fix is just to feather the edges of the color disc in that PNG file, eg:
Standard: With 2px feather: With 3px feather:


PS. If you're going to make an official release of this updated filter, please remove the "..hacked by JT 7-3-15" comment in the registration block date/version field ..that was only put in for test purposes (a) to make sure I had the right version installed (by checking in the Procedure Browser) and (b) to make sure that my hacked version wouldn't get confused with the official/stable version. But I do not want that to remain there ..it's still your baby.

Cheers.

@jontait2

I have incorporated all the changes you suggested ! Thank you for the time and effort you put into this. Thanks for good tips! Python was indeed capable of handling all this . Your code contributions have brought significant polish to the overall user experience and usability!

I should probably mention that the original colorwheel can get generated by the developer version of the plugin, if the .png file is absent. Unfortunately this algorithm depends on numpy so it is not enabled in the standard version. Numpy as far as I remeber is not installed in Windows with the python of the gimp installer. The png file was just a screenshot of that.

The version with all the fixes is 1.6.1, the suggested fixes where also ported to Color Balance 2.

Glad to be of help, John. Your "Color Grading" filter in particular has been a notable addition to the arsenal of both Gimp and GMIC, so you're very welcome to my small contribution.

Just one little problem: for some reason best known to yourself you've changed the method set_wheel_posn() to invoke queue_draw() rather than refresh_view() ...unfortunately this has stopped the preview-update-on-mouseclick which I introduced from working - if you just click on a colorwheel without actually dragging the mouse, the position indicator moves to the new position as intended but the preview isn't actually updated. Can you put it back the way it was?

You're right, I fixed it. I used to play with the safemode version because of the weird bug in Arch occurring only when used with Intel graphics card. This was one of my earlier attempts to rectify that strange bug.

Great job.
Thank you very much.
Version Color_grading_v162 http://sourceforge.net/projects/johnlakgimp/files/Color%20Grading/1.6.2/ also works in Windows with numpy (I installed numpy-1.9.2-win32-superpack-python2.7.exe
http://sourceforge.net/projects/numpy/files/NumPy/1.9.2/ ).

Oops! Never mind, these things happen! Can confirm v162 works as intended.

One other slight hitch: on the sourceforge page for Color Balance 2, the "Looking for the latest version?" link is to Color Grading instead of Color Balance 2 ..bit confusing!

Another thought: for large and very large images it may be better to have an "auto-scale preview" option whereby:
- if the user's image is larger than a certain max size (say 400px in either dimension), the plugin will first copy the active layer to a new "scaled copy" layer, turn off the visibility of the active layer and then use that scaled copy as the basis for the preview rather than the original;
- if and when the user finally presses "OK" the plugin will then remove the preview and scaled copy layers and apply the settings to the original active layer.
This feature would be enabled/disabled by another toggle button.
Have a think about it.

Cheers.

Very good idea, I' ll work on that and will be back soon.

I added the optional small preview and introduced an autosave feature for the last applied filter options.

Download from:
SourceForge
Because of malware being found in SourceForge downloads, this link has been removed.