7. Common Problems and Caveats

Batch mode is not robust, or well designed, or particularily flexible. But it does work most of the time.

7.1 Script Debugging

Debugging Script-Fu scripts is only slightly less painful than stabbing yourself in the eye with a dull spoon.

There is no debugger for Script-Fu, and it tends to generate either no errors or pretty much useless errors. In light of this I'll try to outline a few basic debugging tips.

Using Script-Fu console

There is a console for script-fu available under Xtns->Script-Fu->Console that can be a great help in tracking down bugs.

Since script-fu procedures expect strings, you need to quote all the paramaters to a script-fu procedure when called from the console. For example, the way to call script-fu-swirly-pattern is:

   (script-fu-swirly-pattern 1 "20" "90" "4" "foo.jpg")

This will run the script in the same fashion as it would be called from the commandline, so this is a somewhat more interactive way to test scripts.

The consoel also offers slightly more verbose error output, and more importantly, its more persistent error output.

Typical errors to loof for here include:

ERROR: Invalid types specified for arguments

ERROR: too few arguments (see errobj)

ERROR: unbound variable (errobj foo.jpg)

The "invalid types for arguments" error is usually the result of misquoting in the console. Either that or your suppying a string where a color should be or such.

The "Too few arguments" error is pretty self explanatory. You probabaly have a mismatch between the number of arguments you supplied and the number of arguments it wants. Things to check here would be if you include the run-mode paramater thats is required.

The "unbound variable" error typicaly means your trying to pass a argument that hasnt been declared. THis can be caused my misquoting, spelling errors, or just trying to use a variable out of scope (not really a concern for batch mode...).

Printing out debugging info.

SIOD scheme and script-fu have a way to print error and debugging info to stdout/stderr,but its hardly obvious.

If your using the Script-Fu console to debug scripts, you can just add something like:

(print "Got this far, in the inner loop")

If you are running in batch mode, the first thing you need to do is to make sure the error messages from Script-fu get redirected somewhere you can use them. The default is to send output to the standard gimp handlers, typically a small popup window. There are GIMP PDB procedures for changing how this is handled.

(gimp-message-handler-set 1)

Will tell all

(gimp-message "foo")

Note: The gimp-message fucntionailty is really meant as a replacement for debugging printfs in the main c code, but there is a pdb function for it so we can use it from Script-fu. The reason this is important is that in Gimp 1.0, gimp-message basically acts as a print statement, just printing out the string its told. But changes in the architecture of this in the 1.1 series adds a "gimp:" to each error messages (so that programs can determine if the warnings/errors/messages are coming from glib/gtk/gimp/etc). So in 1.1, its usefulness as a way to just dump to stdout is limited.

7.2 Passing colors and other data types to a batch command.

Gimp batch mode only implements parsing for a handful of the several data types available to gimp and script-fu. Some of the types that dont get parsed include the standard Script-Fu color format of `(red green blue) . Theres no real reason it does not do this aside from it hasnt been written yet.

The simplest workaround is to pass the color as a set of strings and then use script-fu to combine those strings into a script-fu color-type. For example,

(define (script_fu_pass_colors red green blue)
  (let* ((new-color (list red green blue)))

    (gimp-palette-set-foreground new-color)))

(script-fu-register "script_fu_pass_colors"
                    "<Toolbox>/Xtns/Script-Fu/Pass COlors"
                    "Example Script"
                    "Adrian Likins"
                    "Adrian Likins"
                    "Sept 98"
                    ""
                    SF-VALUE "Red" "123"
                    SF-VALUE "Green" "0"
                    SF-VALUE "Blue" "200")

This passes the color as seperate values for red, green, and blue and then combines them into a list for use by gimp procedures.

7.3 Performance Issues

Batch mode is slow. Its not really a practical replacement for tools like ImageMagick or NetPBM when it comes to large scale image conversions or similar. At least not without writing some very clever scripts.

The problem with this approach is that gimp/script-fu has no built in procedures to itterate though a list of images. So you cant easily tell gimp to load up *.jpg and run predator.scm on them, at least not without it taking a _long_ time.

So you could write a shell script to fire up gimp in batch mode for each image, but that starts a new gimp for every image. And gimp startup time is very very slow, especially if you plan to repeat ir a few hndred times.

Even in one time single image oeprations, the gimp startup time is quite slow. Somethings you can do to speed up gimp startup include using the --no-data flag to avoid parsing the data files. Another possibilty is to set up a gimprc and/or pluginrc that only knows about the plugins that the particular script uses so that it can avoid registering all the plugins on startup. This only works in 1.1 gimp however.