Hi,
I was trying to run gimp in batch process to create round border with a shadow on a set of .png images.
Basically, I have to apply script-fu-round-corners to a batch of images.

I want the radius of edges to be defined by a certain input fraction of the image size. Attached: is the script I managed to create by looking up various resources on internet. (I am a complete noob to this Lisp family language.)

But when i run it from terminal in batch mode, I get the following error

==========
(script-fu:3287): GLib-WARNING **: (/build/buildd/glib2.0-2.32.4/./glib/gerror.c:390):g_error_new_valist: runtime check failed: (domain != 0)
script-fu-Warning: Error while loading /home/joe/.gimp-2.8/scripts/batch-roundcorner-dropshadow.scm:

batch command experienced an execution error:
Error: (<unknown> : 148012459) eval: unbound variable: batch-roundcorner-dropshadow

==========

What does this error mean? How do I start debuging the code?

You have unbalanced parentheses in your definition of 'batch-roundcorner-dropshadow' -- you need to add a right parenthesis to the end.

Note that the command line recommended in the script's comments invokes 'batch-drop-shadow', which is not the name of the procedure defined. It is obvious from your output that you used the correct procedure name.

You might wish to check your script in the Script-fu console before running it from the command line (at least after encountering an error). In this case, doing so would have shown that your procedure was never actually defined (because of the missing right parenthesis).

Nice job on the script. You might wish to check whether the PNG image loaded is INDEXED before trying to execute plug-ins which can not handle INDEXED images (such as plug-in-cartoon).

For batch processing, you might be interested in this script.

Hi,
Thankyou very much. I can't believe I spent one night trying to debug a missing paranthesis!

I have corrected the comment in the script, (it was a typo, since I modified the bash command systax from another script!)

I wasn't aware of the Script-fu console. I shall try to use it from now.

Thanks for the heads up on the indexed png files.

And also thanks a lot for the link to the general batch process script. That is a very handy script.

You might also be interested in the fact that you don't need to define a new function dedicated to your batch process. Using BASH's HERE documents allows you to easily specify the steps to be executed directly from the command line (without needing to create a .scm file).

Below is your example written as a HERE document (and employing my 'with-files' macro). Note the minus sign after the -b switch; it signifies that the batch code is to be taken from standard input rather than from the command line itself.

saulgoode, Thanks for the Advanced Bash-Scripting Guide link.

@saulgoode : Thanks for the hint on using Bash's Here Document, That is very useful tip to quickly make gimp calls from bigger shell scripts.

In this particular case, since I will have to reuse it very often, I shall keep it in my scripts collection as a script (it is to add some 3D feel to all the images in my beamer presentation slide.!)

Likely faster method with ImageMagick here.

My experience has been that in the vast majority of cases, GIMP is faster.

GIMP does take longer to initially open, no doubt. On my test machine, just opening GIMP and immediately closing takes around 5 seconds. This was measured by running time gimp -i -b '(gimp-quit 0)' . I did not measure the load time of ImageMagick but I presume it is rather negligible relative to the disk activity for the data files.

As to the basic processing done on the images (once loaded), I have not encountered any operations where ImageMagick is faster. GIMP seems to have the edge for common operations such color adjustments, blurring, and scaling. My experience with this is limited, but not as limited as one might think. My RFX-GIMP project enables invoking GIMP scripts from the LiVES video editor and since LiVES employs ImageMagick for many of its video processing operations, I have been able to compare GIMP implementations for many of these operations. The difference has not been that great -- with GIMP performing either the same or up to twice as fast -- but I do not recall ImageMagick ever coming out ahead.

As an example, performing a rescale operation on an assortment of about two dozen images, GIMP took just over 8 seconds. ImageMagick handled this in 5 seconds. If you discount the initial load time for the GIMP program, GIMP would appear to be faster with regard to the actual processing. And for what it's worth, having an instance of GIMP already open dropped its execution time to 6 seconds -- a new GIMP process is still started for the batch run but it doesn't need to be loaded from disk because it already exists in memory¹.

Where GIMP really gains though is when the processing consists of multiple operations, because ImageMagick needs to reload and resave each image file for every operation; whereas with GIMP the image stays in memory during the whole process¹.

Going back to my example testing, adding a step to invert/negate the colors in each of my test files with GIMP had no significant effect on the processing time (1/10th of a second longer or so), whereas ImageMagick's benchmark increased to 10 seconds (double the initial processing time). As more steps are inserted into the processing pipeline, GIMP's advantage only increases.

I was actually a bit surprised by my experiences -- I would've thought that, were one to discount the issues of file loading and saving, ImageMagick should fair much better than GIMP. GIMP has never put an excessive amount of emphasis on optimizing for speed.

Nonetheless, I don't really care that much about the speed of GIMP's batch processing¹. What is important to me is that I know GIMP's capabilities and how to get things done with it. While ImageMagick has very thorough documentation, there is so much of it that I need to consult it even to do the most simple of tasks. Of course this situation would be improved if I used it more, but why bother when I can use GIMP, and generally speaking, GIMP is more featureful than ImageMagick (except for support of higher bit depths and some GIF colortable stuff).

¹ With the way modern computers handle disk caching and process forking, benchmarking programs has become an extremely inexact science. Apart from avoiding any egregious mistakes in approach, I tend to just try to get things to work and move on. Especially for batch processing tasks, I rarely care whether it might take one hour or two, moreso if I have to expend much effort trying to save that extra time. I mainly posted this to provide a counterpoint to the conventional wisdom that ImageMagick is faster. Such has not been my experience. YMMV