Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
On 09/13/10 05:47, saulgo...@flashingtwelve.brickfilms.com wrote: Quoting Mirza Husadzicmirza.husad...@gmail.com: Hi all, I came up with solution to import and merge Blender's SVG file as path into GIMP. : : I was quite depressed yesterday, but in the middle of night I got an idea :-) If GIMP cannot draw overlapped lines, then why should draw them *overlapped* after all!? If duplicates are removed, then XOR drawing will not affect path. Yupiee. As a side effect, there will be approx. half of lines less to draw (in case of connected polygons a.k.a mesh) so this is a very good optimization for poor gdk-powered line drawing in GIMP. : : I would like to hear you opinions. Why not implement your removal of overlapping path segments as a separate plug-in which can be executed on any paths, not just imported ones? Doing this would eliminate the import interface offering an option which addresses a hardware/graphics preview limitation which many users would not, and would not care to, understand (and may disappear in the future). hi, a quick look at the bug from 2001 suggests this is the underlying issue that affects more than just the svg problem. XOR is a fundamentally flawed way of dealing with overlapping elements. This bug has been repeatedly kicked into the long grass since it was opened. Presumably the best solution would be to deal with the root cause: xor. Removing duplicates would be a reasonable workaround for the mesh problem. Does it have a wider application? /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
Hello, The same as Tobias, I'm not in the topic of paths, so maybe I'm wrong, but you wrote that you add each path (x1, x2, y1, y2) to the hash table and look for duplicates. And what if only a part of a path overlaps? Consider paths: (2,4,2,4) and (1,3,1,3) - then the overlapping fragment will be a path (1,2,1,2), won't it? Łukasz Czerwiński 2010/9/12 Mirza Husadzic mirza.husad...@gmail.com Hi all, I came up with solution to import and merge Blender's SVG file as path into GIMP. This is just quick and dirty solution which I hacked this afternoon. But it works very well. I opened bug report yesterday concerning GIMP's invalid path-line drawing ( https://bugzilla.gnome.org/show_bug.cgi?id=629340). Then, as Sven marked this ticket as duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=55364 (dating form 2001) I realized that things will change really slow:-). I was quite depressed yesterday, but in the middle of night I got an idea :-) If GIMP cannot draw overlapped lines, then why should draw them *overlapped* after all!? If duplicates are removed, then XOR drawing will not affect path. Yupiee. As a side effect, there will be approx. half of lines less to draw (in case of connected polygons a.k.a mesh) so this is a very good optimization for poor gdk-powered line drawing in GIMP. Here is a SVG file for testing: http://www.qsoftz.com/mirza/wp-content/data/gekkoman_unwrapp.svg Here is a screenshot of GIMP with paths on my lovely Ubuntu desktop: http://www.qsoftz.com/mirza/wp-content/data/Screenshot.png Here is a patch: http://www.qsoftz.com/mirza/wp-content/data/0001-cleared-duplicate-lines.patch btw. I used slower variant 'g_hash_table_find' instead of 'g_hash_table_lookup'. I know that this is a flaw. I will try to fix it. And yes, rendering of this kind of optimized path is much better than without optimization. I'm able to work and paint (realtime) over this path. I'm very happy! :-) About patch: The code affects processing only if paths are merged while importing (checked Merge imported path). I'm not sure that I placed code at right place. I'm not sure how it will affect importing of other entities from SVG file (curves, ellipses etc.). But, I'm pretty sure that this is a good way in direction of merging paths. It is useless if they are not flattened into only one path, without duplicated points. The algorithm: As strokes are processed the key for each line in stroke (x1,x2,y1,y2) is constructed and pushed into hash table. If key is uniuqe then line in stroke is valid. If key is duplicated, then line is rejected and current stroke ends (begin of a new stroke). That's it. This method can be applied even if paths are merged from GUI. I will further test this approach with other shapes from SVG (cubic bezier, ellipse etc). If they are flattened on lines, at this stage, maybe this may work with them too. But, I'm not sure about this. I didn't tested it. I would like to hear you opinions. Cheers, Mirza. www.qsoftz.com www.qsoftz.com/mirza ___ 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] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
Then test should be extended to look for collinear lines. But principle should be the same, which means that collinear lines will be removed from flattened path. Mirza. On 13. ruj. 2010., at 10:42, Łukasz Czerwiński lc277...@students.mimuw.edu. pl wrote: Hello, The same as Tobias, I'm not in the topic of paths, so maybe I'm wrong, but you wrote that you add each path (x1, x2, y1, y2) to the hash table and look for duplicates. And what if only a part of a path overlaps? Consider paths: (2,4,2,4) and (1,3,1,3) - then the overlapping fragment will be a path (1,2,1,2), won't it? Łukasz Czerwiński 2010/9/12 Mirza Husadzic mirza.husad...@gmail.com Hi all, I came up with solution to import and merge Blender's SVG file as path into GIMP. This is just quick and dirty solution which I hacked this afternoon. But it works very well. I opened bug report yesterday concerning GIMP's invalid path-line drawing (https://bugzilla.gnome.org/show_bug.cgi?id=629340). Then, as Sven marked this ticket as duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=55364 (dating form 2001) I realized that things will change really slow:-). I was quite depressed yesterday, but in the middle of night I got an idea :-) If GIMP cannot draw overlapped lines, then why should draw them *overlapped* after all!? If duplicates are removed, then XOR drawing will not affect path. Yupiee. As a side effect, there will be approx. half of lines less to draw (in case of connected polygons a.k.a mesh) so this is a very good optimization for poor gdk-powered line drawing in GIMP. Here is a SVG file for testing: http://www.qsoftz.com/mirza/wp-content/data/gekkoman_unwrapp.svg Here is a screenshot of GIMP with paths on my lovely Ubuntu desktop: http://www.qsoftz.com/mirza/wp-content/data/Screenshot.png Here is a patch: http://www.qsoftz.com/mirza/wp-content/data/0001-cleared-duplicate-lines.patch btw. I used slower variant 'g_hash_table_find' instead of 'g_hash_table_lookup'. I know that this is a flaw. I will try to fix it. And yes, rendering of this kind of optimized path is much better than without optimization. I'm able to work and paint (realtime) over this path. I'm very happy! :-) About patch: The code affects processing only if paths are merged while importing (checked Merge imported path). I'm not sure that I placed code at right place. I'm not sure how it will affect importing of other entities from SVG file (curves, ellipses etc.). But, I'm pretty sure that this is a good way in direction of merging paths. It is useless if they are not flattened into only one path, without duplicated points. The algorithm: As strokes are processed the key for each line in stroke (x1,x2,y1,y2) is constructed and pushed into hash table. If key is uniuqe then line in stroke is valid. If key is duplicated, then line is rejected and current stroke ends (begin of a new stroke). That's it. This method can be applied even if paths are merged from GUI. I will further test this approach with other shapes from SVG (cubic bezier, ellipse etc). If they are flattened on lines, at this stage, maybe this may work with them too. But, I'm not sure about this. I didn't tested it. I would like to hear you opinions. Cheers, Mirza. www.qsoftz.com www.qsoftz.com/mirza ___ 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] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
2010/9/13 Mirza mirza.husad...@gmail.com: Then test should be extended to look for collinear lines. But principle should be the same, which means that collinear lines will be removed from flattened path. Mirza. No. Just... no. XOR needs to die. Badly. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
On 13.09.2010 11:47, Alexia Death wrote: No. Just... no. XOR needs to die. Badly. just curious: what coloring options exist to enshure sufficient background contrast when drawing non-XORed/anti-aliased? thx, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
On Mon, Sep 13, 2010 at 11:05 AM, yahvuu yah...@gmail.com wrote: On 13.09.2010 11:47, Alexia Death wrote: No. Just... no. XOR needs to die. Badly. just curious: what coloring options exist to enshure sufficient background contrast when drawing non-XORed/anti-aliased? One good way of doing it is drawing two strokes with slightly different width and contrasting (perhaps transparent) contrasting colors you will achieve sufficient contrast. An old example of such rendering using cairo can be seen here: http://pippin.gimp.org/curve.jpg /Øyvind K. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on LCH layer modes
On 12.09.2010 11:37, Rupert Weber wrote: Just discovered that the clipping in the new layer modes needs more work. It's not a problem with colors that originated in sRGB, but the layer modes can easily construct colors outside sRGB, or even invisible/virtual colors. The current behavior is different from floating point/GEGL implementation. Especially when composing e.g. in Color mode onto a white layer, results differ. A red onto white will become yellow (which isn't necessarily worse than the red from floating point, as it seems to be closer to correct lightness -- but it's different.) btw, the red returned from the current GEGL implementation is too dark: the projection eventually converts to linear light RGB u8 [1] and these values get fed directly to the screen, which in contrast expects gamma-corrected values -- that is, at least when color management is turned off. By numbers: sRGB 1 0 0 red (color mode) over sRGB 1 1 1 white gives LCH(ab) (D65): LCH 53.24 104.55 40 red LCH 100 0 % white the result color is certainly out of gamut: LCH 100 104.55 40 super-bright red = RGB 3.110.450.21 linear light [2] = R'G'B' 1.640.700.50 gamma-encoded [2] with the GEGL projection enabled, GIMP currently delivers (1.0 0.450.21) * 255 = 255 115 55 using proper gamma handling the result, truncated to sRGB, will be: (1.0 0.700.50) * 255 = 255 179 128 hopefully i'm not needlessly complicating things, yahvuu [1] to quick'n'dirty test the gamma-correct conversion, gegl/gimp-gegl-utils.c:61 can be modified to: case 3: return babl_format (R'G'B' u8); /* former (RGB u8) */ case 4: return babl_format (R'G'B'A u8); /* former (RGBA u8) */ [2] babl clamps the results of LCH-RGB conversions to the [0 ..1] interval: extensions/CIE.c:1286 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on LCH layer modes
On 09/13/2010 01:05 PM, yahvuu wrote: btw, the red returned from the current GEGL implementation is too dark: the projection eventually converts to linear light RGB u8 [1] and these values get fed directly to the screen, which in contrast expects gamma-corrected values -- that is, at least when color management is turned off. [...] hopefully i'm not needlessly complicating things, yahvuu The way I understand it is that GEGL intentionally uses the non-gamma-corrected pixels in order to render like the current modes. (As Øyvind had explained somewhere earlier on the list). But for the LCH layer modes that is just wrong without being necessary, as there are no legacy LCH modes, and Lab/LCH is whole different thing from doing RGB arithmetic anyway. I am proposing the attached tiny patch to correct that (Actually I believe someone else described that solution here on the list somewhere, but I maybe confusing it with Øyvind's post). Handling other modes is an opp and thus completely invisible to me ;o) There is a very interesting article about operations on non-linear RGB which I think I found linked on bugzilla: http://www.4p8.com/eric.brasseur/gamma.html Rupert From eb812a330b272dd1579093ae7d9d3076c77e652b Mon Sep 17 00:00:00 2001 From: Rupert Weber g...@leguanease.org Date: Sun, 12 Sep 2010 21:40:19 +0200 Subject: [PATCH] app/gegl: Let GEGL assume sRGB for layer modes GEGL was using babl's RaGaBaA for color layer modes. Changed to R'aG'aB'aA for correct sRGB gamma. --- app/gegl/gimpoperationpointlayermode.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/app/gegl/gimpoperationpointlayermode.c b/app/gegl/gimpoperationpointlayermode.c index 1b59155..a6d145f 100644 --- a/app/gegl/gimpoperationpointlayermode.c +++ b/app/gegl/gimpoperationpointlayermode.c @@ -192,10 +192,10 @@ gimp_operation_point_layer_mode_get_new_color_lchab (GimpLayerModeEffects blend float in_lchab[3]; float lay_lchab[3]; float new_lchab[3]; - Babl *ragabaa_to_lchab = babl_fish (babl_format (RaGaBaA float), + Babl *ragabaa_to_lchab = babl_fish (babl_format (R'aG'aB'aA float), babl_format (CIE LCH(ab) float)); Babl *lchab_to_ragabaa = babl_fish (babl_format (CIE LCH(ab) float), - babl_format (RaGaBaA float)); + babl_format (R'aG'aB'aA float)); babl_process (ragabaa_to_lchab, (void*)in, (void*)in_lchab, 1); babl_process (ragabaa_to_lchab, (void*)lay, (void*)lay_lchab, 1); -- 1.7.0.4 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
There is no doubt about XOR drawing. It should be fixed asap so GIMP development can continue more clearly. But, if you merge some complex path and there is no way to unmerge, it is useless to keep collinear lines. This is just optimization from which users can benefit to import more complex shapes. From which path selection can be traced etc. I dont know which are goals of GIMP, this is just my point of view about programming in general. If there is a demand to optimize bottlenecks I will do it. Drawing half of something (at visible area) is pretty good optimization. Mirza. On 13. ruj. 2010., at 11:47, Alexia Death alexiade...@gmail.com wrote: 2010/9/13 Mirza mirza.husad...@gmail.com: Then test should be extended to look for collinear lines. But principle should be the same, which means that collinear lines will be removed from flattened path. Mirza. No. Just... no. XOR needs to die. Badly. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing per Script
On Sun, 2010-09-12 at 13:58 +0200, oli...@first.in-berlin.de wrote: Hello, I tried drawing per Script. I'm using Python. I can already use vectors for drawing circles, and set single points. I did not found a way to create rectangles, or lines. Probably the easiest method is to have your script generate SVG and use gimp_vectors_import_from_string(). You can of course also create vector strokes using the gimp_vectors_bezier_stroke method. How can I speed up my drawings without switching to C? With my Python script I need about 3 or 4 seconds just for drawing 2072 circles. How do you draw your circles now? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks
On Sun, 2010-09-12 at 23:25 +0200, Mirza Husadzic wrote: Hi all, I came up with solution to import and merge Blender's SVG file as path into GIMP. This is just quick and dirty solution which I hacked this afternoon. But it works very well. I opened bug report yesterday concerning GIMP's invalid path-line drawing (https://bugzilla.gnome.org/show_bug.cgi?id=629340). Then, as Sven marked this ticket as duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=55364 (dating form 2001) I realized that things will change really slow:-). Actually I have fixed the paths drawing problem Friday evening and the problem is solved in my tree. Just needs a little more work to finish it. So please stop wasting your time with work-arounds. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks
Thank you Sven. Actually I didn't wasted my time more on this so far, beacause I'm able to continue my work with painting textures where I jammed last week. I know that I just scratched the surface in this short time and in order to do more solid solution I need to learn more and to look for your help. This is a very good news that it would be solved at git head, and finally realesed with new version of GIMP. I'm sure that many 3D artists will be happy with that fix. This is for sure one of reasons why some of them looked for alternative over GIMP. And this is a reason why I'm such a pain in the ass about this ;-) Because, I want to improve GIMP. And after all I'm doing it with your help. Thanks again ;-) Please consider optimization with merged paths as this is crucial to smooth rendering on current GIMP's architecture. Cheers, Mirza. On 13. ruj. 2010., at 20:19, Sven Neumann s...@gimp.org wrote: On Sun, 2010-09-12 at 23:25 +0200, Mirza Husadzic wrote: Hi all, I came up with solution to import and merge Blender's SVG file as path into GIMP. This is just quick and dirty solution which I hacked this afternoon. But it works very well. I opened bug report yesterday concerning GIMP's invalid path-line drawing (https://bugzilla.gnome.org/show_bug.cgi?id=629340). Then, as Sven marked this ticket as duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=55364 (dating form 2001) I realized that things will change really slow:-). Actually I have fixed the paths drawing problem Friday evening and the problem is solved in my tree. Just needs a little more work to finish it. So please stop wasting your time with work-arounds. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: Drawing per Script
On Sun, Sep 12, 2010 at 8:58 AM, oli...@first.in-berlin.de wrote: Hello, Hi I tried drawing per Script. I'm using Python. I can already use vectors for drawing circles, and set single points. I did not found a way to create rectangles, or lines. You are probablu using pdb_gimp_vectors_bezier_stroke_new_ellipse to draw circles, right? What does prevent you from using the calls for gimp_vectors_bezier_stroke_new_moveto and gimp_vectors_bezier_stroke_lineto to draw lines? (Don't forget to alias then in your code to shorter names, last you have really undereadable stuff) Still, creating a vectors object from stroking is one way of painting with scripts in GIMP (the recomended one to draw curves and circles, though) - for stragiht lines you can use pdb.gimp_paintbrush instead. Aren't there pdb-functions that draw a line? Do I have to create it pixelwise? In a loop? As I stated above, there are calls to draw lines. Are you even using the procedure browser? (Help menu - Procedure browser) - In Python you can access the image data directly, using calls to get the pixel regions if you want to as well (that is about 100x faster than gimp_drawable_set_pixel due to the function calls involved for each pixel change) When using the circle drawing with vectors I would expect that this technique can do it's work fast. But it's very slow (using a loop to set paths in those vectors). (In OpenGL for example there are Vertex Arrays that can be used to speed up drawing. Something like that in GIMP, and available for scripting would be nice.) Sorry to tell you that - tehre is some slowdown in using the PDB, but this is more or less as fast as it gets using GIMP to draw yiu stroken circles. You probably coukd get some speed-u dealing straight with the image data if you don't need the stroking engines from GIMP - i.e. - no need to use different brushes, gradients, dynamics and so on) If so you can get some significant speed-up using C, or maybe even python if you get an efficient way to draw your circles using pixel data. (A suggestion would be to cache different pixel data for the circles with the radii you want, as gimp-buffers, and paste then on the desred places on teh image - that shoul be much faster than creating/stroking paths) (I also saw, that what on the GUI are Paths internally are called vectors. To make things better undesrstandable, it would make sense to give things the same name... but maybe there is more to vectors and I don't see it so far. Why are there different names?) will leave that up to Simon :-) How can I speed up my drawings without switching to C? With my Python script I need about 3 or 4 seconds just for drawing 2072 circles. So, besides my hints above: when I need speed on a PDB using script (which includes python scripts), I found out that GIMP's undo system is the cause for a significant slow down. Creating an Undo group does not help - you have to disbale the undo with pdb.gimp_image_undo_disable This can give you a 3x to 4x times improvement when you have many small operations going on (like drawing thousands of circles) . Unfortunatelly this spoins the undo system for you rimage -even after a call to undo_enable. If you are editing the image interactvely I suggest you make your script to: - copy the drawable you are interested to a new image - disable the undo system on the new image - perform your painting operations - copy the drawable back to the original image (and destroy the newly created image, of course) This seems very slow to me. If I also would need to write pixels of a line pixel-wise, If you weant 1 pixel thick straight lines, use the pencil tool and the pixel brush. I would also await to have very slow scripts. Special functions for drawing lines from within Python-plugins, that use C-speed would be fine. Regards, js -- Gruß, Oliver ___ 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] Fwd: Drawing per Script
Joao S. O. Bueno (gwid...@mpc.com.br) wrote: On Sun, Sep 12, 2010 at 8:58 AM, oli...@first.in-berlin.de wrote: (I also saw, that what on the GUI are Paths internally are called vectors. To make things better undesrstandable, it would make sense to give things the same name... but maybe there is more to vectors and I don't see it so far. Why are there different names?) will leave that up to Simon :-) There already is an internal API that uses the gimp-path-prefix and I wanted to avoid confusion. The new shiny vectors API should have its own namespace, to clearly separate it from the old pesky gimp-path-*-API :-) Also, the vectors infrastructure was designed to allow future extensions that go beyond simple paths. The goal was to have a vectors object as a container for strokes (i.e. connected bezier segments) or circles/ellipses or contrast-following-segments. So it theoretically could contain other stuff as well, going beyond plain paths. That aspect has never been fleshed out, mostly due to UI-confusion-considerations. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fwd: Drawing per Script
Hi, On Mon, Sep 13, 2010 at 05:21:09PM -0300, Joao S. O. Bueno wrote: On Sun, Sep 12, 2010 at 8:58 AM, oli...@first.in-berlin.de wrote: Hello, Hi I tried drawing per Script. I'm using Python. I can already use vectors for drawing circles, and set single points. I did not found a way to create rectangles, or lines. You are probablu using pdb_gimp_vectors_bezier_stroke_new_ellipse to draw circles, right? I use: pdb.gimp_vectors_bezier_stroke_new_ellipse So I think it's what you are talking about, just the absolute name is different. What does prevent you from using the calls for gimp_vectors_bezier_stroke_new_moveto and gimp_vectors_bezier_stroke_lineto to draw lines? I looked for draw and did not find functions that do it. So, in short words: I did not found thos functions. (Don't forget to alias then in your code to shorter names, last you have really undereadable stuff) If it does not eat up too much ressources in Python... ...you mean using def for creating a function that just calls the other one? or are aliases what Python offers as a separate feature? [...] Aren't there pdb-functions that draw a line? Do I have to create it pixelwise? In a loop? As I stated above, there are calls to draw lines. Are you even using the procedure browser? (Help menu - Procedure browser) - I use the procedure browser. But it does not help me, if I look for names that aren't there ...if I look for draw I got nothing. The circle-drawing function via bezier I found by accident/chance. In Python you can access the image data directly, using calls to get the pixel regions if you want to as well (that is about 100x faster than gimp_drawable_set_pixel due to the function calls involved for each pixel change) How can I access the pixel data directly? That would be very interesting to me, especially for some other scripts, where I think about even more intensive work. [...] So, besides my hints above: when I need speed on a PDB using script (which includes python scripts), I found out that GIMP's undo system is the cause for a significant slow down. Creating an Undo group does not help - you have to disbale the undo with pdb.gimp_image_undo_disable OK, I will try that. Thanks for all that hints. :) Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fwd: Drawing per Script
On Mon, Sep 13, 2010 at 8:56 PM, oli...@first.in-berlin.de wrote: Hi, On Mon, Sep 13, 2010 at 05:21:09PM -0300, Joao S. O. Bueno wrote: On Sun, Sep 12, 2010 at 8:58 AM, oli...@first.in-berlin.de wrote: Hello, Hi I tried drawing per Script. I'm using Python. I can already use vectors for drawing circles, and set single points. I did not found a way to create rectangles, or lines. You are probablu using pdb_gimp_vectors_bezier_stroke_new_ellipse to draw circles, right? I use: pdb.gimp_vectors_bezier_stroke_new_ellipse Your way is the correct - mine was just a typo - a thing I excel in. So I think it's what you are talking about, just the absolute name is different. What does prevent you from using the calls for gimp_vectors_bezier_stroke_new_moveto and gimp_vectors_bezier_stroke_lineto to draw lines? I looked for draw and did not find functions that do it. So, in short words: I did not found thos functions. yes-- the procedure broswer has this downside -- you have to keep looking with related words if you don't find something at first. (Don't forget to alias then in your code to shorter names, last you have really undereadable stuff) If it does not eat up too much ressources in Python... It does not. What is delaying the execution is much more the nature of the PDB and the Undo system than python. With aliasing I mea just attributing the pdb functions to a local variable - with lines like these at the start of your function (or even at the start of your module): lineto = pdb.gimp_vectors_bezier_stroke_new_lineto ellipse = pdb.gimp_vectors_bezier_stroke_new_ellipse From then on you can jsut type ellipse( ...) instead of the long name designed to avoid namespace clash. This does not create new functions - you call the very same function, just using another name. ...you mean using def for creating a function that just calls the other one? or are aliases what Python offers as a separate feature? [...] Aren't there pdb-functions that draw a line? Do I have to create it pixelwise? In a loop? As I stated above, there are calls to draw lines. Are you even using the procedure browser? (Help menu - Procedure browser) - I use the procedure browser. But it does not help me, if I look for names that aren't there ...if I look for draw I got nothing. The circle-drawing function via bezier I found by accident/chance. If you type vectors you will see all teh vector related functions. Howeer to paint straight without using a path, you have to look for the tool name: pencil, paintbrush, etc... In Python you can access the image data directly, using calls to get the pixel regions if you want to as well (that is about 100x faster than gimp_drawable_set_pixel due to the function calls involved for each pixel change) How can I access the pixel data directly? That would be very interesting to me, especially for some other scripts, where I think about even more intensive work. px = drawable.get_pixel_rgn(top, left, width, height) px [:, :] = \xff\x00\x00 * drawable.width * drawable.height() drawable.update(top, left, width, height) The get_pixel_region and update are methods of GIMP drawable objects. The item assignment to set/reset pixels is a bit aukward - the example above paints the whole drawable in red (if it is a 3BPP RGB channel, else you willget an error telling the setting string is of the wrong size) For serious work with pixel regions you might prefer to copy the pixel data to a Numpy array - ther eyou can work with numbers from 0 to 2545 instead of having to convert all data to string prior to setting the pixels. [...] So, besides my hints above: when I need speed on a PDB using script (which includes python scripts), I found out that GIMP's undo system is the cause for a significant slow down. Creating an Undo group does not help - you have to disbale the undo with pdb.gimp_image_undo_disable OK, I will try that. Thanks for all that hints. :) Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
