Hello,

I've been trying to debug invoking my gimp plug-in from an apache module for past 3 days without much success. I'm sure others tried the same, but Google didn't help much in finding these gems, so far.
So maybe a fresh pair of eyeballs may have other ideas ...

Ok, basically, I have a python-based GIMP plug-in which runs Ok when invoked from command-line.
But when called from apache (from a python-based apache plugin/module), for some reason the command:

gimp --no-interface --batch='(python-fu-pdf2jpg RUN-NONINTERACTIVE "/path/to/image/to/proces.pdf" )' --batch='(gimp-quit 1)'

doesn't get executed. Or it does but fails silently - which is not very helpful here !!

For testing, I've set the permissions of the OUTPUT directory to 'www-data' (apache user) and '777' (open to universe) but still got no output from the GIMP plug-in in this directory. ... though I got debugging files written by the apache module, so I know apache can write can write files in this directory at run-time.

But nothing from the Gimp module ... Actually I don't get ANY error message from GIMP in any of my /var/log files But once again, if I run that Gimp command from the command line (bash), it runs Ok !!
This would suggest a permissions problem, but I'm not sure. I wonder: does Gimp need to write to the user home directory by any chance? In that case, 'www-data' (the apache user) doesn't have a home directory per se.

So after 3 days of trying different options and digging the Web, I'm a little out of 'debug tricks' right now. If anyone knows why Gimp keeps silent
or knows of a mailing list thread which discusses this topic (i.e. Gimp web invocation),
I would very much appreciate it.

Cheers, vio

Thanks for the hints ...
Some interesting developments while running under sudo. The first run:

----------------------------- sudo -u www-data gimp --no-interface --batch='(python-fu-pdf2jpg RUN-NONINTERACTIVE
"/dd/d/app/front/PAK_live/srvr/xformx.com/run/pdf_forms/le-50.0.11.01(2008-10)d8.pdf" )' --batch='(gimp-quit 1)'
-----------------------------

gives error: error: Cannot create folder '/var/www/.gimp-2.6': Permission denied

So I temporarily opened up /var/www with permission 777 and tried previous command again - to see that gimp is going to write in the /var/www directory:

----------------------------------

sudo -u www-data gimp --no-interface --batch='(python-fu-pdf2jpg RUN-NONINTERACTIVE
"/dd/d/app/front/PAK_live/srvr/xformx.com/run/pdf_forms/le-50.0.11.01(2008-10)d8.pdf" )' --batch='(gimp-quit 1)'
No protocol specified
/var/lib/python-support/python2.6/gtk-2.0/gtk/__init__.py:72: GtkWarning: could not open display
warnings.warn(str(e), _gtk.Warning) No protocol specified

(file-uri:5738): Gtk-WARNING **: cannot open display: :0.0

(gimp:5568): LibGimpBase-WARNING **: gimp: gimp_wire_read(): error No protocol specified
/var/lib/python-support/python2.6/gtk-2.0/gtk/__init__.py:72: GtkWarning: could not open display
warnings.warn(str(e), _gtk.Warning) batch command executed successfully

----------------------------------

This 2nd run interesting things (FINALLY) happened :) The most important is the last line: it says that gimp executed my plugin, and indeed, it did (wrote some debug file to the filesystem, as expected).

Also, after examining '/var/www', I see that gimp created 2 new directories:

drwx------ 4 www-data www-data 4096 2009-10-02 15:38 .gegl-0.0 drwxr-xr-x 21 www-data www-data 4096 2009-10-02 15:38 .gimp-2.6

I don't know how safe it is to keep these Gimp directories inside my main apache directory - it probably opens up some hole of some kind - but anyway, priority now is to make Gimp happy. I'll deal with holes inside my web server later ...

Conclusion: it seems Gimp needed these 2 dirs in that place, as now it seems to work with my preliminary (i.e. debugging) code. The key was to run that gimp command as "sudo -u www-data gimp ..."
to get that error message. Before that, I had no idea what Gimp was complaining about, or if it was even invoked at all ...

Thanks for your help, suggestions, and happy Gimping all ! (I'll be 'web-gimping' in my case :) vio

I haven't tried mod_wsgi yet, so I'm doing it using mod_python. (I don't see a compelling reason to dump mod_python yet, not to mention the learning curve and potential time-cost to convert my scripts from mod_py to mod_wsgi - I don't really know if there are any, just guessing here...)

Invoking GIMP from mod_python works Ok, but it is quite slow. 1 round-trip request - from the client page requesting the Gimp stuff until the server gets back to the client with the response page is quite long - about 10-15 sec - and most (ALL?) of the time is spent on the Gimp side, NOT the apache/mod_py side. So obviously this is not a speed demon, as Gimp was not designed to serve web requests. But speed problem aside, it does work. ... it just needs 'veeery' patient users :)

Anyway, good luck on your side, I think you'll have no big problem making this work,
vio

On Sat, Oct 3, 2009 at 11:26 PM, Brochester L. wrote:

i consider myself pretty well versed with efficiency based upon server performance and apache conforms for me pretty well in plugging in modules to suite my needs and users demands. But I just don't see how you can use Common Gateway Interfacing for this task. I found your thread through a search engine looking for this exact same type of discussion but theres no way I'm gonna pipe gimp to apache in this manner. But Hey Man if you fetch yourself a release of mod_wsgi or mod_python this cgi method might just be doable, but with a lot of users running this, it could be hazardous. With My method I am developing I am going to use (hypothetically, I have not done this) a seperate module for gimp which will thread request's to and fro mod_wsgi(which I have just config'd and am working on the kinks). I would be more than happy to share my progress. Check out my website in a couple of days (http://site.google.com/site/abstractind)

-- Subscidiary Faction of AbstractIndustrys

You're right. Keeping a running Gimp daemon in memory would most certainly speed things up (for subsequent calls)

I recall the python tutorial has some sample code on writing simple servers in python (so, the python code is already available, therefore I'd guess it's probably just a matter of importing it into the Gimp-python plugin - hence no need to do much/any low-level socket programming.

I'm running my devel code (apache+mod_py+Gimp) on a tiny web-book (acer's aspire one) so I'd guess better performance would be achieved de-facto by simply using better hardware (I mean, in a production environment).

(and re-writing all this in C would obviously win the 100m hurdles, but that's overkill for me, for now, I'll be happy with working python code)

vio

PS. Hey, nice last name :) Sounds like You must get a lot of action at Halloween...

On Sun, Oct 4, 2009 at 12:02 PM, Alexia Death wrote:

On Sun, Oct 4, 2009 at 4:19 PM, Vio wrote:

Invoking GIMP from mod_python works Ok, but it is quite slow. 1 round-trip request - from the client page requesting the Gimp stuff until the server gets back to the client with the response page is quite long - about 10-15 sec - and most (ALL?) of the time is spent on the Gimp side, NOT the apache/mod_py side. So obviously this is not a speed demon, as Gimp was not designed to serve web requests. But speed problem aside, it does work.  ... it just needs 'veeery' patient users :)

I suspect part of the speed problem is that gimp is started and loaded at each call. a running gimp process is capable of taking over without a new process at least for opening images, but I don't know if you can do this for scripts. You might get better times if you write a plug-in that listens on a socket and executes received pdb calls.