Re: [Gimp-developer] Invoking custom Gimp module from Web (Apache)
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. for...@gimpusers.com 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Invoking custom Gimp module from Web (Apache)
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 alexiade...@gmail.com wrote: On Sun, Oct 4, 2009 at 4:19 PM, Vio zaza...@gmail.com 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Invoking custom Gimp module from Web (Apache)
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] scripting GFig
Hi, Could someone post some links or examples on scripting GFig, please. I mean, I know how to call the plug-in from a script: python pdb.plug_in_gfig(image, drawable,dummy) but then how do I pass commands to gfig, say, to draw a shape which is not included in its catalog? Or even one which is part of the gfig catalog? My first guess would be to create a shape description file in ~/gimp/gfig. But then how is gfig instructed to load and process that shape? Thanks, Vio ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Wanted: pixel warrior drones
Hi all, After browsing the gimp-1.3 TODO list, I would like to add my little suggestion of things I would wish from Gimp: how about also developing a clear path towards Gimp as a web graphics server. Analogy: as we now have static web pages and dynamic web pages (php, zope, etc), similarily I ould like to see not only static graphic representations (implementations: bitmap, vector, mpegs), also dynamic graphic representations. What are dynamic graphic representations? Nice images we can only see at runtime (just as dynamic web pages can only be seen at runtime). Well Gimp's scripts are a good example of dynamic pictures (granted, scripts are not pictures per se, but follow my idea). So from a web designer's point of view, what would really make a lot of sense would be the ability to call such dynamic graphical representations from, let's say, a 'php' or 'dtml' page. For those who don't know, 'dtml' are simple tags inserted in a html page, which the Zope server replaces with the appropriate value before sending it to the client. Example of a dtml tag inside a html page: img src=dtml-var expr=My_time_alienGlow. img ... is a html tag, and dtml-var expr=My_time_alienGlow is a dtml tag. What does the latter do ? Well, it is a call to my method - Zope server with call it at run time. This method, using Gimp's python bindings, will hopefully call Gimp's AlienGlow script and pass it a string (in this case, the local time on my hardware), and some other parameters required by the AlienGlow script (I guess colour parameners, font size, etc.). Does this sound far-fetched? Ok, this may be still fantasy on ice, as I only installed Gimp 1.2.3 couple of days ago, and haven't yet touched gimp-python or scripting-gimp docs (fun starts in a few minutes). But I am totally impressed with Gimp 1.2.3, and I read it can in fact be made to act like a server, started without the GUI, passing it commands with the 'gimp-remote' program (which incidentally seems absent from my installation). So there's the idea: use Gimp as a general purpose image manipulation server (and beef it up with some charting and other vector-based image manipulation plug-ins, for those lazy designers who like me don't really want to learn more than one toolkit to do their job). Push Gimp towards the industry standard's pixel warrior drone. (as opposed to breathing pixel warriors). In a server configuration, the web browser is the all-encompassing GUI. Granted, not all of Gimp's functionality can be accessed through Netscape or IE's limited GUI, but a lot still (like all the image transformation scripts !!!). And for those who want the rest of it, they'll just need to install the GimpGUI, which from here on is a specialized client for the Gimp server, alongside Zope, Php server, eventually some possible Apache perl module, etc. Well, I'm an old Photoshop - new Gimp convert and don't yet know all there is to know about this impressive piece of code. But I hope this may give some ideas to other participants, or more encouragement if discussions/efforts in this direction are already under way. Cheers, Vio ¢^½éh¥êæj)b b²Ñ¢^½éh¥êåËlÅÇÛz¹ ìvèm¶ÿ+-³ mêäzW²yÛ¿¨¥©ÿ+-wèþ¦¥×¯zZ)z
[Gimp-developer] Wanted: pixel warrior drones
Hi all, After browsing the gimp-1.3 TODO list, I would like to add my little suggestion of things I would wish from Gimp: how about also developing a clear path towardsGimp as a web graphics server. Analogy: as we now have static web pages and dynamic web pages (php, zope, etc), similarily I ould like to see not only static graphic representations (implementations: bitmap, vector, mpegs), also dynamic graphic representations. What are dynamic graphic representations? Nice images we can only see at runtime (just as dynamic web pages can only be seen at runtime). Well Gimp's scripts are a good example of dynamic pictures (granted, scripts are not pictures per se, but follow my idea). So from a web designer's point of view, what would really make a lot of sense would be the ability to call such dynamic graphical representations from, let's say, a 'php' or 'dtml' page. For those who don't know, 'dtml' are simple tags inserted in a html page, which the Zope server replaces with the appropriate value before sending it to the client. Example of a dtml tag inside a html page: img src=dtml-var expr=My_time_alienGlow. img ... is a html tag, and dtml-var expr=My_time_alienGlow is a dtml tag. What does the latter do ? Well, it is a call to my method - Zope server with call it at run time. This method, using Gimp's python bindings, will hopefully call Gimp's AlienGlow script and pass it a string (in this case, the local time on my hardware), and some other parameters required by the AlienGlow script (I guess colour parameners, font size, etc.). Does this sound far-fetched? Ok, this may be still fantasy on ice, as I only installed Gimp 1.2.3 couple of days ago, and haven't yet touched gimp-python or scripting-gimp docs (fun starts in a few minutes). But I am totally impressed with Gimp 1.2.3, and I read it can in fact be made to act like a server, startedwithout the GUI, passing it commands with the 'gimp-remote' program (which incidentally seems absent from my installation). So there's the idea: use Gimp as a general purpose image manipulation server (and beef it up with some charting and other vector-based image manipulation plug-ins, for those lazy designers who like me don't really want to learn more than one toolkit to do their job). Push Gimp towards the industry standard's pixel warrior drone. (as opposed to breathing pixel warriors). In a server configuration, the web browser is the all-encompassing GUI. Granted, not all of Gimp's functionality can be accessed through Netscape or IE's limited GUI, but a lot still (like all the image transformation scripts !!!). And for those who want the rest of it, they'll just need to install the GimpGUI, which from here on is a specialized client for the Gimp server, alongside Zope, Php server, eventually some possible Apache perl module, etc. Well, I'm an old Photoshop - new Gimp convert and don't yet know all there is toknow about this impressive piece of code. But I hope this may give some ideas toother participants, or more encouragement if discussions/efforts in this direction are already under way. Cheers, Vio ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wanted: pixel warrior drones
* Stephen J Baker [EMAIL PROTECTED] [020304 10:27]: On 4 Mar 2002, at 4:10, vio wrote: After browsing the gimp-1.3 TODO list, I would like to add my little suggestion of things I would wish from Gimp: how about also developing a clear path towardsGimp as a web graphics server. Wouldn't it make more sense to push Gimp's scripted rendering features into the browser (as a plugin) and send just the script to the user's machine for interpreting? It would presumably be a LOT less bandwidth than sending out an image...particularly if you are doing animations. I don't understand what you mean by Gimp's scripted rendering features? That the Gimp plugin/script source code is stored on the browser side? And a browser plugin: which browser? Exactly. The client (the web browser) has no idea (nor interest to know!) who or how the pictures it receives from the web server are generated. The only difference in this situation is that those images are generated after the web server received the request from the client for that image. A good analogy would be with Dell's 'direct' distribution model: a Dell computer is assembled only after a customer has placed the order for it. Same here: Gimp assembles the pixels for the image only after the server has received an order for it (a request). Let's call this Image On Demand. Obviously, most images on a web page will continue to be served pre-assembled (pre-cooked) images. But there is a market out there for images generated on the spot, bleeding fresh, photons still smoking. Examples could be any images who age very fast (stock graphs come to mind, though it's not the best example) or images who are dependent on the client's request (so they couldn't have been generated beforehand since the server had no idea what the client's parameters for that image was before it made the request). Yes, this is a very resource-intensive proposition, as opposed to static images, but CPU speeds are getting faster, RAM is getting cheaper. And hopefully bandwidth providers will follow suit. I managed to put my hand on a Net-Fu package. Yes, that is what I was talking about. I wonder if this code is still maintained by anyone, because what I got had a 1997 timestamp. I hope the authors won't mind, but if I can manage to get rid of the Java code (for their client), and re-write the server in python, we're in business (not that I have personally anything against Java or C). Regards, Vio ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
