Re: [Gimp-developer] Python Docs
Hi, On Sat, 2008-09-27 at 22:41 +0200, Samuel wrote: Where can I find the actual Python docs for GIMP? I know this site: http://www.gimp.org/docs/python/index.html These docs are very outdated. But unfortunately there is no newer documentation available at this point. I suggest that you have a look at the Python plug-ins that come with the GIMP source code. There are some examples that will probably help you. Hopefully we will have better Python documentation at some point. Perhaps you want to volunteer to make that happen? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] template python plugin
Hi, On Sun, 2008-09-28 at 17:15 -0700, Greg MacDonald wrote: I've been fiddling around with writing gimp-python plugins and ended up creating a template for myself. It took me a day to put together so I was thinking I might post it. This is interesting. Is there a particular reason that your plug-in template is not using gimpfu, the convenience layer that the Python binding offers for making it easier to write simple plug-ins? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] template python plugin
Hi Sven, No reason really. But now that you bring it up, I wonder if gimpfu might be more useful to people. If I had needed to setup a gui, I probably would've stuck with gimpfu for it's auto gui generation features. I think I may have gone with gimpplugin too because it just felt familiar to me; reminded me of other sorts of plugins I've written. Would you like me to switch it over? -Greg On Mon, Sep 29, 2008 at 2:03 AM, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sun, 2008-09-28 at 17:15 -0700, Greg MacDonald wrote: I've been fiddling around with writing gimp-python plugins and ended up creating a template for myself. It took me a day to put together so I was thinking I might post it. This is interesting. Is there a particular reason that your plug-in template is not using gimpfu, the convenience layer that the Python binding offers for making it easier to write simple plug-ins? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Python
I have been at the GIMP IRC channel and they told me that C is faster than Python if I want many pixel ops. I wrote a test plugin in Python which copies a layer pixel per pixel to another one and it needs several minutes for a vga picture. I put it here: http://pastebin.com/m1e61c74a Regards Samuel Hi, On Mon, 2008-09-29 at 11:35 +0200, Samuel wrote: I got, what I wanted (pixel ops), but I found out that it's too slow. I'll try to write in C now. Pixel operations in Python, if done correctly, are not very much slower than doing the same in C. But please keep this discussion on the mailing-list. I am not going to reply to further mails unless you move this discussion back to the list. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Python
Hi, On Mon, 2008-09-29 at 12:10 +0200, Samuel wrote: I have been at the GIMP IRC channel and they told me that C is faster than Python if I want many pixel ops. I wrote a test plugin in Python which copies a layer pixel per pixel to another one and it needs several minutes for a vga picture. I put it here: http://pastebin.com/m1e61c74a What you are doing there is quite ineffecient. Your plug-in does not allocate a tile cache. And since you are reading a pixel from one tile, then writing a pixel to another tile, the tiles have to be re-requested from the core over and over again. There are several ways you can improve this: (1) Use a tile-cache with two tiles: gimp.tile_cache_ntiles(2). (2) Change your access pattern to iterate over the layer tile-by-tile instead of doing it row-by-row. If you want to keep row-by-row access, then you should increase your tile cache further so that it can hold 2 rows of tiles. (3) Instead of reading and writing single pixels, you could read and write arrays of pixels. For example rows of GIMP_TILE_WIDTH. This would reduce the overhead you have to do for each pixel. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] template python plugin
Hi, I would very much welcome if you could change the call to gimp.install_procedure() to not pass the full menu path. The procedure is supposed to be passed the menu label only. There's a seperate procedure to register the menu entry: gimp.menu_register(). Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Python
Hi Samuel, On Mon, Sep 29, 2008 at 7:40 PM, Samuel [EMAIL PROTECTED] wrote: I have been at the GIMP IRC channel and they told me that C is faster than Python if I want many pixel ops. I wrote a test plugin in Python which copies a layer pixel per pixel to another one and it needs several minutes for a vga picture. Sven has covered how to access tiles faster. There is also the following approach, which does not require any knowledge of tiles and is quite simple. If you are copying large areas (eg 1024x1024), a tile based approach may be more appropriate. # create a pixel region: pr = sourcelayer.get_pixel_rgn (0, 0, sourcelayer.width, sourcelayer.height, False, False) # then you read all pixels from that region pixels = pr[:,:] # create another region on the destination pr2 = destlayer.get_pixel_rgn (0, 0, destlayer.width, destlayer.height, True, False) # and write the stored pixels pr2[:,:] = pixels Every pixel has now been copied (on my machine, this takes less than a second for a VGA picture). Note that the above assumes certain similarities between the layers -- ie. they are of the same dimensions,and they either both have an alpha channel or they both lack an alpha channel. It also assumes they are of the same type (as in, both belonging to an RGB image, or both belonging to an Indexed image, or both belonging to a Greyscale image) HTH, David -- Everything has reasons. Nothing has justification. Ĉio havas kialojn; Neniaĵo havas pravigeron. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] numpy Docs
I made a speed test with Python and found out that it's too slow for pixel ops. I change to C now. Furthermore the docs for a C plugin are much better than these for Python. Hi Sam, Thanks for your response. Sven seems to know alot about it, he thinks python speed is good. That would be because people are leveraging numpy and pixel_regions. You can blit to a pr in a flash, afaict. I have not done timing tests. I recommend you look over this page: http://www.scipy.org/Numpy_Example_List_With_Doc ...then see how people are blitting numpy arrays into pixel_regions. AFAICT that is the deep secret. And find Travis Oliphants book on numpy; its 350 pages. He just freed it about two weeks ago. Now, if I could ask for your help on my little problem, I just dont know how to treat only a rectangular selection in my plugin (and return a result as a new layer). That would be a big help. Check out the attachment when you have some time. It is beginning to behave -- on my dataset, weather charts. See you, paul stroke_to_vector.py Description: Binary data ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] numpy Docs
Maybe when you save the selection at the beginning of the plugin with selection = drawable.image.selection #The selection mask for the image. bounds = drawable.mask_bounds #The bounds of the drawable's selection. #or like in feca_hdr: http://registry.gimp.org/node/4752 self.sel_x1, self.sel_y1, self.sel_x2, self.sel_y2 = drawable.mask_bounds But like I said, I don't know anything about Python, I just had a look at the old docs at http://www.gimp.org/docs/python/index.html paul taney wrote: I made a speed test with Python and found out that it's too slow for pixel ops. I change to C now. Furthermore the docs for a C plugin are much better than these for Python. Hi Sam, Thanks for your response. Sven seems to know alot about it, he thinks python speed is good. That would be because people are leveraging numpy and pixel_regions. You can blit to a pr in a flash, afaict. I have not done timing tests. I recommend you look over this page: http://www.scipy.org/Numpy_Example_List_With_Doc ...then see how people are blitting numpy arrays into pixel_regions. AFAICT that is the deep secret. And find Travis Oliphants book on numpy; its 350 pages. He just freed it about two weeks ago. Now, if I could ask for your help on my little problem, I just dont know how to treat only a rectangular selection in my plugin (and return a result as a new layer). That would be a big help. Check out the attachment when you have some time. It is beginning to behave -- on my dataset, weather charts. See you, paul ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Updated code for gegl-sampler-yafr
Hello all: I submitted what is probably the last yafr patch for a while. (Unless I figure out how to use Geert's patch to do more careful boundary conditions and compute pixel values past the abyss boundary, which is documented through a #define in the code.) I really believe that this is without question the best overall (interpolatory) sampler currently running under gegl (and ImageMagick for this matter). Give it a try. The scheme is quite different from the one currently in the svn, which had an early diagonal version (the current version uses horizontal and vertical differences). You can find the patch file at http://bugzilla.gnome.org/show_bug.cgi?id=552159 There are suggestions in the source code to test it and compare it to the other schemes from the gegl command. You may also find a replacement gegl/gegl/docs/gallery at the following location, which uses, with permission to use for research purposes, the great test images shown of http://www.cambridgeincolour.com/tutorials/digital-photo-enlargement.htm The alternative gallery.tgz, which you untar then recompile if you replace the current one with it, is found here: http://web.cs.laurentian.ca/robidoux/misc/ It will produce a web page at that location which includes timings as well as clickable thumbnails (just like the original gallery did). To the main developers: Thank you for your patience, and apologies the high bandwidth. Nicolas Robidoux Laurentian University/Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Updated code for gegl-sampler-yafr
Apologies: The yafr email was meant for the gegl-developer list. Nicolas Robidoux Laurentian University/Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
