Re: [Gimp-developer] Finding out what happens when compositing layers
On 09/16/2011 02:20 AM, David Gowers (kampu) wrote: In GEGL, the layer mode code is autogenerated from formula strings -- see operations/generated/math.rb The opacity behaviour is not documented there, but my understanding is that the alpha of the underlying composite is preserved, and opacity only effects how much of the layer's COLOR channels are applied (per the standard blending formula). On Fri, Sep 16, 2011 at 7:09 AM, Ofnuts ofn...@laposte.net mailto:ofn...@laposte.net wrote: I'll trying to find out what happens when a layer is in subtract mode with a global opacity not one or zero (i.e. what computations are done with the pixels values of the composite image of the layers below, the pixel values of the layer, and the general opacity). I have a git extract of the Gimp source code (and of gegl babl) but got lost... Can someone help? Well, I know that in Normal mode, I have in each RGB channel: Composite=Over*alpha+Under(1-alpha) (assuming Under is fully opaque), but in Subtract mode, I would have several possibilities Composite=Under(1-alpha)-Over*alpha or Composite=Under(1-alpha)+(1-Over)*alpha or Composite=Under(1-alpha)+(1-Over*alpha) and $deity knows what else. math.rb isn't taking the opacity in account (but is an interesting read...) Thx. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Finding out what happens when compositing layers
I'll trying to find out what happens when a layer is in subtract mode with a global opacity not one or zero (i.e. what computations are done with the pixels values of the composite image of the layers below, the pixel values of the layer, and the general opacity). I have a git extract of the Gimp source code (and of gegl babl) but got lost... Can someone help? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Blog article about Scheme usage in GIMP
On 09/06/2011 10:55 AM, Martin Nordholts wrote: Haven't we got a quite nice Python interface already? Yes we do, which is nice, but Scheme still has higher status. In particular, the format of gimprc files etc are Scheme-ish, and the default batch interpreter is Script-Fu. The format of the gimprc files is not very relevant for scripts? As to the default batch interpreter, if/when python plugins have sufficient appeal, people add python support (when they didn't get it out of the box). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Blog article about Scheme usage in GIMP
On 09/05/2011 07:57 PM, Martin Nordholts wrote: If we look at what programming languages that are popular [1], we can see that the vast majority of languages in use today have a syntax where 1 + 1 is written 1 + 1 and not (+ 1 1). If we want to have a main scripting language that as many as possible can use with as little effort as possible, Scheme is simply not an alternative. For most programmers, Scheme is an odd language. In the long term I think it is inevitable that we need to replace Scheme with something that has a syntax that is more mainstream. I wholeheartedly agree with that. However, doing the switch is a huge task and we have other things that are more important to work on, so I don't see this happening any time soon. Haven't we got a quite nice Python interface already? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Accessing the sample points
Is there a way to get the Sample points coordinates in a script? I've seen scripts needing point coordinates using paths for that, but this seems a bit artificial and not very user-friendly. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Color mode in brushes and layers
The doc at http://docs.gimp.org/en/gimp-concepts-layer-modes.html says: Color mode uses the hue and saturation of the upper layer and the value of the lower layer to form the resulting image. However, this isn't what I see... it seems that the saturation of the top layer only acts if it's below 0.05 (it then slightly reduces the saturation from the bottom layer), and Color mode otherwise behaves like Hue mode. Am I misssing something? And if not, why this behavior? -- Bertrand ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Unified transform tool
On 04/17/2011 08:31 AM, Michael Grosberg wrote: Ofnutsofnutsat laposte.net writes: Symmetry mode is not well defined... In your drawing, you drag on top-right and the top-left follows (vertical axis), but it could as well have been the bottom-right (horizontal axis), and even the bottom-left (radial). As I did mention, it was not a complete spec. The points you raise are valid, but they are already treated well in the original spec, and I only wanted to present the differences. In distort mode, Symmetry is applied to the larger distort delta of the two axes, i.e. if you distort a corner point 20 px to the right and 10px to the top, the symmetry will be horizontal. IMHO, your proposal, like the original one, doesn't address a very frequent use of these transforms, which is to match the transformed object with an existing one. Actually, the original spec DOES mention that scale from center is toggled by the CTRL key. Moving the center point lets you scale from any given point. Assuming we are both talking about http://gui.gimp.org/index.php/Transformation_tool_specification, this is not how I read it... there is the rotation axis, and the centre, that is defined as the point where the two diagonals through the corner points cross. The spec for the rotation does specify that the rotation axis can be dragged (that part would have been moved outside of the rotation transform it were usable with other transforms) The spec for the scaling, when using the from centre constraint, says translate the opposite side by the same distance which implies that the centre is equidistant to both sides and thus is still the centre defined above. An arbitrary fixed point would have implied the use of proportional somewhere in the spec. I may be wrong. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Unified transform tool
On 04/16/2011 04:13 PM, Michael Grosberg wrote: There has been some interest among the GSOC applicants to work on the unified transform tool.there already exists a very original specification for this tool. But I have some reservations about the transform frame being a bit too complex. I wrote an alternative suggestion. This is not a complete spec, just a direction the transform FRAME might be taken to, in order to make it easier to use. You can read it here: http://bit.ly/hIJdxW I'll be glad to hear any feedback you have. Symmetry mode is not well defined... In your drawing, you drag on top-right and the top-left follows (vertical axis), but it could as well have been the bottom-right (horizontal axis), and even the bottom-left (radial). IMHO, your proposal, like the original one, doesn't address a very frequent use of these transforms, which is to match the transformed object with an existing one. In that use-case, having a fixed point elsewhere than in the center for the whole transform is very useful. There is such a thing for rotation (the axis can be moved), but not for scaling (where the fixed point is either a corner or the center). Imagine for instance that you want to graft a new face on a picture: with an arbitrary fixed point for scaling, you would move a pupil over the matching one of the target face, and select that point as the fixed point. The rest of the process in one gesture to rotate/scale the new face so that the second pupils match (that is mathematically very simple since rotation and homotecy have the same center). Without it, it is a long sequence of small steps, because you can't adjust the scale without moving your reference point. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gimp_vectors_bezier_stroke_lineto() working backwards?
Why is gimp_vectors_bezier_stroke_lineto(vectors, stroke_id, x0, y0) (and Stroke.lineto(x,y)) working backwards? If I add a lineto() to the stroke, the point of origin (the one returned by gimp_vectors_stroke_get_point_at_dist(0,..)) changes... I'm sure there is a good reason, but I can't find it. Can someone enlighten me? -- Bertrand ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp_vectors_bezier_stroke_lineto() working backwards?
On 03/21/2011 02:34 PM, Simon Budig wrote: Ofnuts (ofn...@laposte.net) wrote: Why is gimp_vectors_bezier_stroke_lineto(vectors, stroke_id, x0, y0) (and Stroke.lineto(x,y)) working backwards? If I add a lineto() to the stroke, the point of origin (the one returned by gimp_vectors_stroke_get_point_at_dist(0,..)) changes... I'm sure there is a good reason, but I can't find it. Can someone enlighten me? The reason is simply the internal data structure as well as a (possibly over-)optimzation in the code. A lineto basically needs to add three anchors to the list of anchors. If the current point is the beginning of the list, you can add these three anchors in an O(1) operation. If you'd append them to the end you'd have to first search for the end, making this an O(n) operation (unless you of course keep track of the other end). That's one reason :) The API does not guarantee consistency for the distance-point mapping when the length of the total path changes. When I designed the API I tried to avoid the idea of a specific start and end for each stroke, since this would introduce a directionality which would not be visible in the User Interface. But there is directionality if you stroke the path using a gradient you somewhat have to know where it starts and where it ends. I'm writing a scrirt that draws a path parallel to another one and if I don't want it to switch sides around a circle directionality is important: on a circle, there are always two points where the tangent has the same slope, but in one the outside is above and oin the other the outside is below, and to tell which locally you have to know in which direction you are going. Do you need to have get_point_at_dist(0...) staying constant while constructing the stroke with the _lineto-family of commands? My need is to be able to iterate between two points in the stroke (as located by their distance since that's the only thing we have) and not have this change if I add segments to the path. But I think I can iterate a copy of the stroke instead. However if point_at_dist(0) currently returns the end instead of the start, going for the start isn't that easy since stroke.point_at_dist(stroke.get_length()) often fails (due to round-off errors, likely). I conclude that the best way to get at the beginning of the path is to look at the last points in stroke.points? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] are curves broken?
On 03/11/2011 11:18 PM, Jacek Poplawski wrote: Hello, two weeks ago I realized that curves don't work as before, and I submitted following bug report: https://bugzilla.gnome.org/show_bug.cgi?id=643155 am I doing something wrong, or am I the only person who is using curves this way? I tested following builds: gimp-git-20110216-1-i686.pkg.tar.xz gimp-git-20110221-1-i686.pkg.tar.xz gimp-git-20110222-1-i686.pkg.tar.xz gimp-git-20110224-1-i686.pkg.tar.xz gimp-git-20110301-1-i686.pkg.tar.xz gimp-git-20110309-1-i686.pkg.tar.xz gimp-git-20110311-1-i686.pkg.tar.xz and I always back to 02.16 because it was the last one which works correctly My 2.7 built from a git-clone on March 3 works OK and I can use the color picker in the Curves tool without problems. Running a Kubuntu 10.04 with auto-updates. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On 03/08/2011 08:46 AM, Olivier wrote: 2011/3/8 Michael Grosberg grosberg.mich...@gmail.com mailto:grosberg.mich...@gmail.com Debi Rapson drapson at mansd.org http://mansd.org writes: Can you point me in the direction of a list of places that actually use GIMP for photo retouching and graphics creation. Hmm. GIMP is not well suited for professional photo retouching - it lack the necessary CMYK color model (among other things). I'm not sure what the focus of your program is but if you're looking for real-world use I would look more into video game art creation or online content. Could you explain why retouching photos should be made in CMYK rather than RGB? Could you explain why retouching photos should be made in RGB rather than HSV/HSL :) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On 03/03/2011 02:17 AM, Chris Mohler wrote: I *think* that would cover all of the transformations of the proposed tool. And I assume all or most of those values are going to be in play (and in the undo stack) during use of the transform tool. But yeah, just having the one-off dialogs for transforms would work as well. I have no real preference either way, but the dockable (or placing those items in tool options) seems cleaner to me for some reason. Since each transform slightly blurs the image, using the individual transforms one by one would not give results as good as applying one single transform that combines everything, would it? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pencil Tool
On 02/26/2011 07:40 PM, Michael Grosberg wrote: I've begun working on GIMP documentation so GIMP is on my mind a lot lately. So, I have a suggestion - remove the pencil tool, and instead, add a checkbox to the brush tool with an antialiased label. My reasoning is that for a new user, the difference between brush and pencil is not evident from their name or icon. They do pretty much the same thing with they only difference being that pencil is not antialiased. The pencil tool is nothing like an actual pencil. So, if we want the UI to reflect the actual workings of the program, it makes sense to do this. The only objection I can think of is if in real-life situation people actually use the pencil tool in conjunction with the brush tool in such a way that they have a separate settings for each, and the change from one to other a lot. But that is what tool presets are for. If you have a tablet, you can switch tools by reversing the stylus. It's meant for brush vs eraser, but someone must be using that for brush vs pencil :-) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIT access no longer working
My local copy of the Gimp code used to be updatable by issuing a git update in the root directory.. This no longer work and I get: fatal: read error: Connection reset by peer -- My .git/config: core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = git://git.gnome.org/gimp [branch master] remote = origin merge = refs/heads/master -- I'm not too familiar with Git. Am I doing something wrong? Or has something changed elsewhere? -- Bertrand ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIT access no longer working
On 02/21/2011 04:01 PM, LightningIsMyName wrote: I'm not a git wizard myself, but cloning here (using git clone) and updating (using git pull) does work for me. I have no idea what about the config file - it means nothing to me :P As I undertstand it, you git clone once to initialize your local version, and you then git pull for updates. You did say you use git update in the root directory to update the sources, and I'm not familiar with such a command. Did you possibly mean git pull? Indeed. Doing too much CVS... git pull it is. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-item-transform-scale vs gimp-drawable-transform-scale
On 02/11/2011 01:02 PM, Alexander Rabtchevich wrote: I apologize, you are right. I apparently only added links to the new context functions from the new selection API. It's the new context API, e.g. gimp_context_set_interpolation(). Will add the docs after work today. Hmmm. What proportion of existing plug-ins working in 2.6 will have to be rewritten for 2.8? In my neck of the IT woods, within the same version backward compatibility is implied... And if a rewrite is necessary we will have to support both versions for quite some time (some people fall in love with some plug-ins and won't upgrade Gimp until there is a new version of their beloved plug-in). And do it again when 3.0 shows up... ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop ?compatibility? mode
On 02/01/2011 06:25 PM, Alexandre Prokoudine wrote: On Tue, Feb 1, 2011 at 8:16 PM, Michael Grosberg wrote: I will refrain from expressing my opinion on undocumented, undiscoverable features. Now only a help page is needed. I think I'll go and join the Gimp-Docs mailing list and take it from there. This is an area in which I have a lot of experience (I've been documenting graphic apps for several years now). So far it looks like the best outcome of the thread :) Thank you. Let's remove one stroke from the name of the program. Let's call it GINP. GINP Is Not Photoshop. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] donations for GIMP 2.8
On 01/17/2011 11:32 PM, Mike Williams wrote: On Mon, Jan 17, 2011 at 4:46 PM, Sven Neumann s...@gimp.org mailto:s...@gimp.org wrote:So far this has been the most constructive idea that has been brought up in this thread. So why not? Let's try to come up with a list of bugs that block the GIMP 2.8 release and put bounties on them. Who wants to volunteer to prepare a list of bugs that are worth having a bounty put on them? Sven Hi there. This has been effective for google and mozilla, sounds like it is worth a try. I've got one week before school starts, if the list appears soon, I'd be inclined to try to fix something. Ideally CS professors would be lured into giving assignments around GIMP bug fixing... And this would introduce students to real-world programming. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Possible Future of ScriptFu/TinyFu with R6RS/Racket
On 01/14/2011 12:29 PM, Alexandre Prokoudine wrote: On 1/14/11, Kevin Cozens wrote: It is well known in that a lot of people know it exists. As for it being understood, not so much. I hate to tell you, but JS indeed is broadly known and used. At least half of Creative Suite is scripted in JS, and there is a whole industry around various JS based extensions and scripts for CS. I won't say how many times I heard users saying Oh my, I could write scripts in JS, but learning a new language just for GIMP? Thanks, no. only because I stopped counting few years ago. Just a little perspective from outside :) This might be true for Scheme but Python is a lot more mainstream. And IMHO it's not as much a question of language than a question of API ( I write my Python scripts by looking at Scheme code docs). When your remove all things document-related from someone's alleged JS expertise, there isn't much left and that's all they would be able to reuse to write Gimps scripts in JS... Python is a rather nice and sound language, GIMP already has an interface for it, it only needs some improvements and a better/more up-to-date documentation... ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/22/2010 09:59 PM, Patrick Horgan wrote: From the comments in the code, it looks like it's computing the convolution matrix values by integrating the gaussian bell curve (using 100 points total). Now I'm interested. Where can I look in the code for this? They really do this every time with the same results instead of just having an array of the numbers so generated? plugins/unsharp-mask.c, line 768 and up. It's not always the same results, because the blur radius is used as at the standard deviation of the integrated gaussian. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/22/2010 10:18 PM, Patrick Horgan wrote: On 11/22/2010 12:59 PM, Patrick Horgan wrote: Now I'm interested. Where can I look in the code for this? They really do this every time with the same results instead of just having an array of the numbers so generated? Never mind. I saw it. It's depending on the radius which is a double. Even though double's aren't reals so it wouldn't be an infinite number of matrices required if you did it for each possible value less than 10 to would be an impossibly large number. Reading this code was a pleasure. Clearly written by someone who wants the code to be maintainable/comprehensible by others. Well, I wondered too: the radius slider goes from 0 to 120 in .1 steps so that would be only 1200 values to pre-calculate. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] distributing gimp with another program
On 11/21/2010 02:03 PM, Graeme Gill wrote: If there is functional dependence, then the mere aggregation on the same media escape clause wouldn't seem to apply. Then everything written for Linux would have to be GPL because it has functional dependence on GPL code? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Reference Manuals gone?
I have a bookmark on GIMP Reference Manuals at http://developer.gimp.org/api/2.0/index.html that no longer works: The requested URL /api/2.0/index.html was not found on this server. Apache/2.2.16 (Debian) Server at developer.gimp.org Port 80 Trying the home page (http://developer.gimp.org/) says: It works! This is the default web page for this server. The web server software is running but no content has been added, yet. Googling for GIMP Reference Manuals point to the same URL, so I assume my bookmark has been OK at some point in the not so distant past. Is the server hosed? Or has the content moved (and how do we get Google to display the right URL)? -- Ofnuts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why the Van Gogh filter is still in gimp?
On 11/14/2010 04:53 PM, Liam R E Quin wrote: Consider the amateur photographer and Gimp beginner who wants to add some sharpening of a picture. What filter to use? Sharpen? Unsharp mask? NL? Why does Gimp offers the three? What are the differences? That's a bit of a culture shock when one comes from Picasa.Putting the Unsharp mask one in a Photo submenu would already be a hint. But sharpen is useful on images that are not photographs. I haven't done much with NL or Van Gogh myself, but any assertion that no-one uses them or that they are not useful must be backed up with some real data. Let's apply Paretos's rule. 90% of users use 10% of the code. 10% of users uses 90% of the code. There was a project gathering usage statistics on an earlier version of Gimp, maybe they have some data on that? Or make the filers crash when used and see if anyone complains :-) :-) I did that a long time ago to clean up a disk full of obsolete utilities. Got very few requests to put some things back :-) As for, which filter to use on a photograph, it depends on the photograph, on the lighting that was used, on the subject matter... Yes, proper filtering requires a lot of education. And there is little pupose of giving people a whole toolbox (that they have to carry around) if they don't know how/why they could use some of the tools inside. Unsharp Mask is popular partly (I think) because it makes a slight halo effect similar to some darkroom techniques, so that the result is closer to what you see in printed books. It's popular because it's the better bang for the buck. But the Gimp defaults are a bit too much for me :-) Smart sharpen is another interesting alternative, but has no preview and is slow. A better approach long-term might be to make it easier for people distributing gimp to package individual plugins or groups of plugins, and to have away to search and request plugins from within gimp, sort of like CTAN for TeX, CPAN for Perl, CXAN for XQuery. Then the core could have fewer plugins, with perhaps a primary add-on set, or a small group of add-on sets tailored to particular use cases such as digital painter, professional photographer, photomanipulator, scientific visualization, scanning and so forth. We are in full agreement on this. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why the Van Gogh filter is still in gimp?
On 11/15/2010 07:53 PM, g...@catking.net wrote: On 11/15/10 19:01, Ofnuts wrote: There was a project gathering usage statistics on an earlier version of Gimp, maybe they have some data on that? Or make the filers crash when used and see if anyone complains:-) :-) I did that a long time ago to clean up a disk full of obsolete utilities. Got very few requests to put some things back:-) That is really a pretty perverted logic. Due to the all too common lack of repect for backwards compatibility in Linux world most people either conclude that a feature is broken/disappeared and live with it or they just conclude that they can't remember how to do it.. If you look at the 3.0 specs a lot more people are going to be surprised by the new UI than by the absence of some filters. And I'm not advocating to remove anything either, just to move it to optional packages. The percentage of users that actually take the trouble to search for help, subscribe to a list and post a bug report is very small. Hardly a useful way of polling the user base. As for, which filter to use on a photograph, it depends on the photograph, on the lighting that was used, on the subject matter... Yes, proper filtering requires a lot of education. And there is little pupose of giving people a whole toolbox (that they have to carry around) if they don't know how/why they could use some of the tools inside. Little pupose except _education_ . One sure way to make sure users stay uneducated and don't know how/why to use the tools is to remove them ! See above about optional packages. And I am not convinced that the intractable VanGogh or the pre-cooked Alpha-to-Logo filters are very educative. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why the Van Gogh filter is still in gimp?
On 11/14/2010 11:44 AM, Michael Schumacher wrote: On 14.11.2010 01:21, Bill Skaggs wrote: Here is a better reason, maybe. It is a good thing if people can learn to use Gimp by experimenting. When features are included for which experimenting leads only to confusion, and never to anything useful, users are discouraged from experimenting. Doesn't this boil down to Remove anything that requires any level of education? That would be a caricature. Let's face it, the core of Gimp (and of Photoshop, for that matter) requires education. You won't use Gimp efficiently without a good understanding of such concepts as selection, layers canvas, transparency... If you look at Gimp forums, you see very basic questions. Consider the amateur photographer and Gimp beginner who wants to add some sharpening of a picture. What filter to use? Sharpen? Unsharp mask? NL? Why does Gimp offers the three? What are the differences? That's a bit of a culture shock when one comes from Picasa.Putting the Unsharp mask one in a Photo submenu would already be a hint. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Suggestion for upcoming transformation tool
Just read the specs here: http://gui.gimp.org/index.php/Transformation_tool_specification I like that very much... except this: Transformation constraints [...] from centre works on scale and shear, toggled by ctrl [...] centre/corner rotate works on rotation axis, toggled by ctrl Constraining the scale around the center is arbitrary. Scale could be constrained around any fixed point, and this fixed point could as well be the already defined rotation axis (which, by default, is at the center...). If I want to adjust a layer over another one, I don't want scale to move things around. I would move the upper layer until one of its pixels is at its final place, then pin that one down and rotate/scale the upper layer to make at least another pixel match. Additional suggestion; the current crosshair design masks the reference pixel, and in many cases the lines leading to it. A diagonal crosshair with a 3x3 pixels clear center could be better. -- ofnuts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why the Van Gogh filter is still in gimp?
On 11/14/2010 01:21 AM, Bill Skaggs wrote: In my opinion, there are two plug-ins that have this property: the Van Gogh filter (which has absolutely nothing to do with Van Gogh), and the so-called NL Filter. The NL filter is a different matter. The human factors are abysmal. It should be three different menu entries, with descriptive names. But it's typical of a filter useless for people doing original art, and only useful for photography and scan. -- Ofnuts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Stroking path with brush dynamics
On 11/10/2010 08:06 PM, Rob Antonishen wrote: Do you get better results just painting with a paint tool? Yes... the circle isn't as circular, but the inner rim stays the same color throughout. Same for the square, it even rounds the corners. The brush you posted is not a good candidate for orientation dynamics, as is much wider than tall. There are two gradient layers in the XCF, one is the brush (10x50) and the other is the map for the filter I used (50x10). But I originally tried with the 50x10 layer rotated 90 degrees, for the same results. Remember brush dynamics do not deform or distort the brush in any no uniform way, it merely rotates it. You would get (marginally) better results with a bowtie shaped brush. I don't expect them to, either Not sure about the path flipping when stroking. If you use a gih with angular rotation it doesn't flip, so this looks like a bug in the brush dynamic engine. http://www.majhost.com/gallery/ffaat/gimp/more/gihtest.jpg Nice example, but I couldn't find what a gih is? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Stroking path with brush dynamics
On 11/10/2010 10:18 PM, Rob Antonishen wrote: Nice example, but I couldn't find what a gih is? Gimp image hose, aka rotating brush I made that one with my script: http://ffaat.pointclark.net/blog/archives/145-Gimp-Script-to-Help-Make-Rotating-Brushes.html -Rob A Aw, I should have know... already seen your script but it never occcured to me to use rotating brushes for this. Will give it a try. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.7: selection to path procedure lookup failed.
On 11/09/2010 07:17 AM, Martin Nordholts wrote: On 11/08/2010 11:22 PM, Ofnuts wrote: I'm trying to have coexisting a locally built 2.7 and a packaged 2.6.8. 2.6.8 goes to /usr/bin and /usr/lib and 2.7 installs into /usr/local/lib and /usr/local/bin I start 2.7 via a shell that export LD_IBRARY_PATH and updates the PATH so tha the /usr/local stuff goes first. Just a couple of tips: * Don't install into a prefix in a prefix, rather use /usr and /opt Ain't me... I used all defaults in the Git build scripts. * You shouldn't need to set LD_IBRARY_PATH when you run (only when you ./configure) because built binaries will have library paths hardcoded in them through rpath [1], unless you disabled that. OK, will look that up. Thanks. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.7: selection to path procedure lookup failed.
Worked a treat. Now both versions seem to coexist peacefully. Thanks. On 11/09/2010 08:24 PM, Martin Nordholts wrote: Well, the default prefix is for when you want to override an installation in /usr, if you don't want that, which is the case here, it is your responsibility to change it to something else. Pass --prefix=/opt to autogen.sh or configure. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Stroking path with brush dynamics
While playing with 2.7, I noticed that one of the brush dynamics is the oriention, something I had been longing for. However, when stroking a selection, the results are a bit disappointing. Here is an XCF with a couple of tests: http://dl.free.fr/fRALiPMXa (on the left, the 2.7 results, on the right, what one would expect...). The pictures are actually a selection to path + stroke path , because a direct stroke selection on the circle is even worse. From a user point of view, it is difficult to understand - on the circle: the side switch - on the square: the inversion in the top bar (I assume the reason is the same as in the circle), and the inconsistent overlap (the right side of the top bar should be under the right bar). Rounding the corners would be a cherry on the cake :-) If it's still work in progress, I didn't say anything... -- Ofnuts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.7: selection to path procedure lookup failed.
I'm trying to have coexisting a locally built 2.7 and a packaged 2.6.8. 2.6.8 goes to /usr/bin and /usr/lib and 2.7 installs into /usr/local/lib and /usr/local/bin I start 2.7 via a shell that export LD_IBRARY_PATH and updates the PATH so tha the /usr/local stuff goes first. 2.7 seems to work (all tools I tried worked, especially the 2.7-specific cage tool) except when I try to transform a selection to path, for which I get: Selection to path procedure lookup failed. If I recall correctly, my freshly built, bytes-still-wet, 2.7 did work correctly, so I must have broken something when playing with the system load paths. Can anyone suggest where to look? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Error compiling GIT version
Fairly new at all this, but managed to - git-clone the repository (should give me the latest and greatest (yes, unstable, but that's understood)?) - run autogen.sh and install the various dependencies - at last, running make But, then after some amount of time and much console activity (that let me assume that my setup is OK) I get: gimpoperationcagecoefcalc.c:23:34: error: gegl-buffer-iterator.h: No such file or directory And this file is indeed not part of the headers I got when I built/installed gegl-0.1.2 (from tjhe gtk.org repository). Do I need an even more recent version of GEGL (but autogen.sh looked happy with 0.1.2), and if so, where do I get it from? -- Ofnuts, in very rainy Paris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Color from gradient broken
I just played a bit with this and I confirm there is something fishy in the UI (I'm on 2.6). When using a tablet, with color from gradient checked and all brush dynamics (pressure/velocity/random) un-checked, one ends up in a mode where the color is derived from the length of the current brush stroke. And there is nothing making that clear in the UI. And when one selects another dynamic, the length one disappears and nothing shows how to put it back. So, my suggestion; 1) make the length dynamic (or whatever its official name is) explicit, with its own line of checkboxes. 2) grey out the gradient part when no color is used in any of the dynamics (its length selector, that seem used only for the length dynamic could be replaced by the cursor on the right of the checkboxes). 3) the fade out option is merely the opacity controlled by the length dynamic. 4) grey out the pressure/veloclity (no tilt support yet?) when there are no extended devices. 5) come to think of it, the amount of jitter could also be controlled by the dynamics (of course we need a way to specifiy a fixed jitter, either by an artificial no dynamic, or by using a minimum cursor value in the length dynamic). 6) I'm not too enamored with the little cursor symbols next to the checkboxes. 1) iIt is not so obvious there is something to set there, 2) they aren't that much readable, 3) they don't explain how they work (percentage? length? pixels/second)? 3) some dynamics may need more than one cursor (for length: none/sawtooth/triangle, but pressure/velocity could have several transfer functions) Hoping my criticism has been constructive enough ... ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] menu back in the toolbox
On 10/24/2010 08:49 PM, Tomek CEDRO wrote: On Sun, Oct 24, 2010 at 8:24 PM, Rob Antonishen rob.antonis...@gmail.com wrote: Well, To chip in my two cents, I want to remind you that Gimp is open source and if you want the menu there then you are free to fork and maintain a version of Gimp with the menu in. Arguing against the vision and direction already set is counterproductive at this point. Arguing that one user's work flow is better than any others is just egoism imoo. OK guys, I am bad egoist - I want to be productive and use comfortable tools, sometimes I create them, and always try to remember about good standard, quality and usability. Also there are some bad egoists around. New vision is not necessary against standard or backward compatibility, because standard is what makes base for further development. I don't think development requires enforcement, but its your socialist style with your nice theories and wise words, because you enforce others to do as you please with no alternative for them (while this alternative is possible). I just wanted to ask for old menu back, or anything that could be similar to this menu - its not about changing your vision, but accepting feedback from users that enjoyed this feature. Don't you think such vision would be much more fulfilled when at low cost both sides are happy? None of this is going to happen. We waste more time and energy on talking than simply fixing this issue. The patch is created for 2.6, I am switching back to 2.4 then. You can be proud of your bright new vision and forcing everyone to use it, because you know better than user. You are right, I can still use version 2.4 or patch the sources of 2.6, but like I said - its not Open Source anymore, only the source code is available, because you are not open to feedback and user ideas, even when patch is ready. Maybe someone come soon and enforce his own vision irreversibly destroying your work, then you will understand what I was talking about. I'm not a Gimp developer, but as a software developer I understand the point of view of the current Gimp team, and I sympathize. UI development is one person to do the work and 10 to criticize :-) If we want to improve things we have to shed some of the old. Our ancestors lost their gills when they developed lungs. Having both would have been useful only to a very small set of species. Backward compatibility is nice, often very useful and on the verge of mandatory when it comes to file formats and APIs, but in the world of UIs it creates confusion and is more complicated to achieve than you think (should new features be implemented in both UIs?). It's not uncommon for software to drastically change its human interface. From Windows 3.1 to Seven I see at least two landmark UI changes, and about the same for MS-Office (I'm too recent a Linux convert to tell but I'm sure there are examples on that side of the force, too). OTOH there are usually many ways to skin a specific cat (especially with Gimp), so what you want may be there but under a different guise. __ Ofnuts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Detecting closure of selection
On 10/10/2010 04:01, saulgo...@flashingtwelve.brickfilms.com wrote: Quoting Ofnutsofn...@laposte.net: Is there a practical, fast way, to detect this case, i.e, that the selection covers the whole layer (or image?) and that no pixels remain unselected? I assume that inverting the selection again and testing for empty would work, but that would be two selection inversions in the normal case and that may be a bit costly. The following appears to be about twice as fast as the two inversion approach. (let ((count (cdddr (gimp-histogram (car (gimp-image-get-selection image)) HISTOGRAM-VALUE 255 255 (= (car count) (cadr count)) ; compare num of all pixels to all white pixels ) Exactly what the doctor ordered. Thanks (and to Rob...). However, the only documentation I found of this function was in the API browser of the python-fu console. I couldn't find it in the files I sampled at http://developer.gimp.org/api/2.0/index.html. Where is it documented? -- Bertrand ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Detecting closure of selection
Assume I have a selection on small area (for instance a 20px circle), and I invert it. Now, if I grow the selection by a sufficient amount (10px in this case), everything gets selected. Is there a practical, fast way, to detect this case, i.e, that the selection covers the whole layer (or image?) and that no pixels remain unselected? I assume that inverting the selection again and testing for empty would work, but that would be two selection inversions in the normal case and that may be a bit costly. -- Bertrand ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Detecting closure of selection
On 09/10/2010 23:24, Owen wrote: Assume I have a selection on small area (for instance a 20px circle), and I invert it. Now, if I grow the selection by a sufficient amount (10px in this case), everything gets selected. Is there a practical, fast way, to detect this case, i.e, that the selection covers the whole layer (or image?) and that no pixels remain unselected? I assume that inverting the selection again and testing for empty would work, but that would be two selection inversions in the normal case and that may be a bit costly. Select-all? I don't want to select all. I want to catch if a selection_grow() ended up selecting everything. -- Bertrand ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Detecting closure of selection
On 10/10/2010 00:22, David Gowers (kampu) wrote: On Sun, Oct 10, 2010 at 7:47 AM, Ofnutsofn...@laposte.net wrote: Assume I have a selection on small area (for instance a 20px circle), and I invert it. Now, if I grow the selection by a sufficient amount (10px in this case), everything gets selected. Is there a practical, fast way, to detect this case, i.e, that the selection covers the whole layer (or image?) and that no pixels remain unselected? I assume that inverting the selection again and testing for empty would work, but that would be two selection inversions in the normal case and that may be a bit costly. Testing for empty and for full are the same operation (an empty sel is equivalent to a full one) HTH There are indeed many tools that behave the same way if the selection is empty of complete, but gimp_selection_is_empty http://developer.gimp.org/api/2.0/libgimp/libgimp-gimpselection.html#gimp-selection-is-empty() return False when the selection is complete, alas. -- Bertrand ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Optimizing border-like selection in python
On 27/09/2010 18:47, saulgo...@flashingtwelve.brickfilms.com wrote: Quoting Ofnutsofn...@laposte.net: My code needs to do a one-pixel-wide selection, at distance x from the current selection. This looks a lot like a border selection except that the border selection creates at best a two-pixel wide ribbon and I only want one (but if I'm wrong, please tell me how to :-) So far my code goes like this: # Selects pixels that are between x and x+1 pixels from # the original selection. Bumping the selection by one # each time doesn't work, a small circle degenerates into # a square with rounded corners instead of a big circle. def select_ribbon(self,image,selection,dist): pdb.gimp_selection_load(selection) pdb.gimp_selection_grow(image,dist+1) outer=pdb.gimp_selection_save(image) pdb.gimp_selection_load(selection) pdb.gimp_selection_grow(image,dist) inner=pdb.gimp_selection_save(image) pdb.gimp_channel_combine_masks(outer,inner,CHANNEL_OP_SUBTRACT,0,0) pdb.gimp_selection_load(outer) image.remove_channel(outer) image.remove_channel(inner) That works, but can be slow (especially since it's at the core of a loop). Is there any better way? Or useless code to jettison? There is no need to create (and later delete) the 'outer' channel. Just use the selection itself. In Script-fu, this would be done as follows: (gimp-selection-load selection) (gimp-selection-grow image dist) (set! inner (car (gimp-selection-save image))) (gimp-selection-load selection) (gimp-selection-grow image (+ dist 1)) (gimp-channel-combine-masks (car (gimp-image-get-selection image)) inner CHANNEL-OP-SUBTRACT 0 0) (gimp-image-remove-channel image inner) Implemented your code. It runs 10 to 20% faster, and uses only half the memory... So you have been duly credited in the V0.2 history. Thx. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Optimizing border-like selection in python
On 24/09/2010 17:05, Joao S. O. Bueno wrote: On Fri, Sep 24, 2010 at 11:19 AM, Ofnutsofn...@laposte.net wrote: Hi, My code needs to do a one-pixel-wide selection, at distance x from the current selection. This looks a lot like a border selection except that the border selection creates at best a two-pixel wide ribbon and I only want one (but if I'm wrong, please tell me how to :-) So far my code goes like this: # Selects pixels that are between x and x+1 pixels from # the original selection. Bumping the selection by one # each time doesn't work, a small circle degenerates into # a square with rounded corners instead of a big circle. def select_ribbon(self,image,selection,dist): pdb.gimp_selection_load(selection) pdb.gimp_selection_grow(image,dist+1) outer=pdb.gimp_selection_save(image) pdb.gimp_selection_load(selection) pdb.gimp_selection_grow(image,dist) inner=pdb.gimp_selection_save(image) pdb.gimp_channel_combine_masks(outer,inner,CHANNEL_OP_SUBTRACT,0,0) pdb.gimp_selection_load(outer) image.remove_channel(outer) image.remove_channel(inner) That works, but can be slow (especially since it's at the core of a loop). Is there any better way? Or useless code to jettison? Next improvement is to create a 3-pixels selection and feather it one pixel. Anything to be wary of? Hmm..this _will_ be slow. :-) You can speed it up by making a copy of your drawable to another image, disable the undo system on this new image and perform your cations above, before copying the results back to the original image - but it is about it. Maybe you can perform the whole loop in the copy with undo disabled - but I don't know your intent. Disabling undo on the main image (just for tests) doesn't show much speed gain (from 2'03 to 1'56 in my test). It's only better memory-wise. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Optimizing border-like selection in python
Hi, My code needs to do a one-pixel-wide selection, at distance x from the current selection. This looks a lot like a border selection except that the border selection creates at best a two-pixel wide ribbon and I only want one (but if I'm wrong, please tell me how to :-) So far my code goes like this: # Selects pixels that are between x and x+1 pixels from # the original selection. Bumping the selection by one # each time doesn't work, a small circle degenerates into # a square with rounded corners instead of a big circle. def select_ribbon(self,image,selection,dist): pdb.gimp_selection_load(selection) pdb.gimp_selection_grow(image,dist+1) outer=pdb.gimp_selection_save(image) pdb.gimp_selection_load(selection) pdb.gimp_selection_grow(image,dist) inner=pdb.gimp_selection_save(image) pdb.gimp_channel_combine_masks(outer,inner,CHANNEL_OP_SUBTRACT,0,0) pdb.gimp_selection_load(outer) image.remove_channel(outer) image.remove_channel(inner) That works, but can be slow (especially since it's at the core of a loop). Is there any better way? Or useless code to jettison? Next improvement is to create a 3-pixels selection and feather it one pixel. Anything to be wary of? -- Ofnuts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Optimizing border-like selection in python
On 24/09/2010 19:44, Ofnuts wrote: The whole plugin paints successive concentric uniform 1-pixel ribbons around the original selection (pixel values a obtained from another layer). On my laptop (T2400, 1.83GHz) it takes roughly 10 seconds to draw 20 concentric ribbons around a 500-pixels circular selection. The whole thing runs within a undo_group_start()/image.undo_group_end() so I don't expect any more undos? By the way, when my plug-in runs, the marching ants go into a frenzy, as if each selection change caused a screen update (though the bucket-fills don't show until the whole thing is finished). Would disabling these updates speed things up? (if so how is it done?) -- Ofnuts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Optimizing border-like selection in python
The code should work for any shape of selection (for instance after a text-to-selection). Actually the plugin this routine is part of hasn't got much merit on rectangular/circular selections... On 25/09/2010 00:27, Jerry Baker wrote: Ahh... autoformatting... this should be easier to read... (sorry) def create_border(image, selection_type='rectangle', size=1): is_selection, x1, y1, x2, y2 = pdb.gimp_selection_bounds(image) if is_selection: if size 1: size = 1 if selection_type =='rectangle': pdb.gimp_rect_select(image, x1+size, y1+size, (x2-x1)-(size*2), (y2-y1)-(size*2), CHANNEL_OP_SUBTRACT, False, 0) elif selection_type == 'ellipse': pdb.gimp_ellipse_select(image, x1+size, y1+size, (x2-x1)-(size*2), (y2-y1)-(size*2), CHANNEL_OP_SUBTRACT, True, False, 0) else: gimp.message(Please make a selection...) def test_plugin(image, drawable): image.undo_group_start() # A rectangular selecion with default settings... create_border(image) # Ellipse with custom settings... Uncomment to activate #create_border(image, selection_type='ellipse', size=3) # Fill pdb.gimp_edit_fill(drawable, 0) pdb.gimp_selection_none(image) image.undo_group_end() On 09/24/2010 06:18 PM, Jerry Baker wrote: Calculating a new selection from the current selection would be faster (I think): def create_border(image, selection_type='rectangle', size=1): is_selection, x1, y1, x2, y2 = pdb.gimp_selection_bounds(image) if is_selection: if size 1: size = 1 if selection_type =='rectangle': pdb.gimp_rect_select(image, x1+size, y1+size, (x2-x1)-(size*2), (y2-y1)-(size*2), CHANNEL_OP_SUBTRACT, False, 0) elif selection_type == 'ellipse': pdb.gimp_ellipse_select(image, x1+size, y1+size, (x2-x1)-(size*2), (y2-y1)-(size*2), CHANNEL_OP_SUBTRACT, True, False, 0) else: gimp.message(Please make a selection...) def test_plugin(image, drawable): image.undo_group_start() create_border(image) # A rectangular selecion with default settings... #create_border(image, selection_type='ellipse', size=3) # Or Ellipse with custom settings... # Fill pdb.gimp_edit_fill(drawable, 0) pdb.gimp_selection_none(image) image.undo_group_end() ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gracefully handling BPP in a python plugin
On 19/09/2010 20:44, Sven Neumann wrote: First of all, why are you using the PDB directly instead of using the Python objects? Ignorance, defiance, and laziness. The doc for the Image class (http://www.gimp.org/docs/python/index.html) has around 20 methods. Compare to the number of gimp_image_* functions in the PDB (not speaking of all the Python class methods/attributes vs the whole PDB)(*) For a newcomer, it looks like using the Python classes isn't going to cut it, since PDB functions will have to be used anyway, so why bother with two ways of doing things? And for the laziness bit, the python-fu console gives pre-cooked PDB calls... The code to create an image and an RGBA layer should look like this: image = image = gimp.Image(100, 100, RGB) layer = gimp.Layer(image, RGB layer, 100, 100, RGBA_IMAGE) image.add_layer(layer) Then to address you problem, you are not really creating a grayscale layer in an RGB image. Your code only creates the layer, it doesn't actually add it to the image. If you tried to do that, then that would fail. Indeed. Case closed :-) (*) I'm not underestimating the challenge of having a complete Python vision of the PDB... ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gracefully handling BPP in a python plugin
On 18/09/2010 19:23, Sven Neumann wrote: On Sat, 2010-09-18 at 01:51 +0200, Ofnuts wrote: I had overlooked the fact that greyscale was an attribute of the image and not the layer. Thanks for the reminder. With that in mind I could perform some more tests with greyscale and it turns out that at least the python interface returns 3 or 4 channels even in greyscale, so everything is OK. If that is the case, then there is a bug somewhere. But I very much doubt that gray-scale layers are reported to have 3 or channels. Perhaps you can show us some example code? Hmm. Wrote some fresh code to demonstrate this and of course it behaves as you say. Grumble, grumble. Back to the drawing board. Thx for the heads up. PS: well, something fishy still. Creating a greyscale layer in a RGB image works, and yields a 1BPP layer: image_color = pdb.gimp_image_new(100,100,0) layer_grayscale=pdb.gimp_layer_new(image_color,100,100,2,'grayscale_layer',100,0) print pdb.gimp_drawable_get_pixel(layer_grayscale,0,0) This a moot point right now because I'm not creating images layers that way, but you said this couldn't happen? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gracefully handling BPP in a python plugin
Hello, I'm writing a plugin that takes a drawable as input for pixel values. What kind of BPP can I expect? I'd say 4 and 3 are color layers with and without alpha. Will I encounter 2 and 1 for grey-levels with and without alpha, too? I can't find a way to create a layer in grey levels (or to change an existing color one to grey levels). Am I overlooking the obvious or would that only apply to layer masks? I'm actually using the drawable pixels fro set the foreground color for various operation (selection stroke and bucket fill). Is there a general function to convert the pixel values betwen drawables of different depth? or can I put in gimp_context_set_foreground() whatever I get from gimp_drawable_get_pixel()? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gracefully handling BPP in a python plugin
On 18/09/2010 00:33, Sven Neumann wrote: On Fri, 2010-09-17 at 20:48 +0200, Ofnuts wrote: Hello, I'm writing a plugin that takes a drawable as input for pixel values. What kind of BPP can I expect? I'd say 4 and 3 are color layers with and without alpha. Will I encounter 2 and 1 for grey-levels with and without alpha, too? Well, it depends on what your procedure specifies as image types when it registers. The documentation says: image_types is a comma separated list of image types, or actually drawable types, that this procedure can deal with. Wildcards are possible here, so you could say RGB* instead of RGB, RGBA or * for all image types. If the procedure doesn't need an image to run, use the empty string. I can't find a way to create a layer in grey levels (or to change an existing color one to grey levels). Am I overlooking the obvious or would that only apply to layer masks? Grayscale layers only exist in grayscale images. If you specify GRAY and/or GRAYA or *, then your procedure needs to handle those drawable types. I had overlooked the fact that greyscale was an attribute of the image and not the layer. Thanks for the reminder. With that in mind I could perform some more tests with greyscale and it turns out that at least the python interface returns 3 or 4 channels even in greyscale, so everything is OK. Thx for the help. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Python plugin registration: choosing between a closed set of strings
I'd like the user to select a variant of a plugin (among 3 to 5 ones). I would normally do so with a R/O drop-down box displaying the names. Is there a way to do so using the right type of parameter type in the registration (couldn't find it)? Otherwise what would be the recommended way to do it? Define separate plugins for each variant? Btw, can I define several plugins (ie, register() calls) in one single Python file? Or what is the best way (ie, easier to install for the end-user) to share code between Python plugins? -- Ofnuts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Python plugin registration: choosing between a closed set of strings
On 07/09/2010 20:52, Sven Neumann wrote: On Tue, 2010-09-07 at 16:53 +0200, Ofnuts wrote: I'd like the user to select a variant of a plugin (among 3 to 5 ones). I would normally do so with a R/O drop-down box displaying the names. Is there a way to do so using the right type of parameter type in the registration (couldn't find it)? You should consider to avoid gimpfu for this and write a real GIMP plug-in in Python using a user interface built in PyGTK. The auto-generated UI of gimpfu is really just suited for very simple scripts. And there is a lot of awkwardness in gimpfu. It tries to make things easy for you, but then it gets into your way and you end up spending time to find workarounds for that. Still a rather simple script so far, parameter-wise, so python-fu is sufficient, especially given Jerry's answers... but I'll keep your suggestion in mind for when I get more proficient with all this. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Python plugin registration: choosing between a closed set of strings
On 07/09/2010 20:55, Jerry Baker wrote: PF_OPTION is what I had in mind, without finding it described. I googled it after you netioned itn and found a nice python-fu sample with all parameters types... I wish I had found it earlier... Thanks for confirming my guess that multiple registration could work. It is therefore a serious option, especially since some variants require less parameters. If your 'variants' are similar you could just use PF_OPTION and change your variables/options with an if/else... Or you can define different functions and register them separately in the same file. The 'palette-to-gradient.py' file in the source does this... http://git.gnome.org/browse/gimp/tree/plug-ins/pygimp/plug-ins/palette-to-gradient.py On 09/07/2010 10:53 AM, Ofnuts wrote: I'd like the user to select a variant of a plugin (among 3 to 5 ones). I would normally do so with a R/O drop-down box displaying the names. Is there a way to do so using the right type of parameter type in the registration (couldn't find it)? Otherwise what would be the recommended way to do it? Define separate plugins for each variant? Btw, can I define several plugins (ie, register() calls) in one single Python file? Or what is the best way (ie, easier to install for the end-user) to share code between Python plugins? -- Ofnuts ___ 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
[Gimp-developer] Bucket-fill the selection in a python plugin
Hello from the noob... I'm working on my first Gimp plugin in python, and most things work, but I can't seem to make a bucket-fill into the selection. My code currently does: res=pdb.gimp_edit_bucket_fill_full(drawable,FG_BUCKET_FILL,NORMAL_MODE,0,0,True,False,SELECT_CRITERION_COMPOSITE,0,0) ... but this returns None, so I suspect something is not correct in the call. As far as I can tell: - drawable is indeed an existing layer of the image. - there is a selection. I have tried various other values to no avail. I've also tried the python-fu console, after creating a selection by hand on a plain new image: print gimp.image_list()[0] gimp.Image 'Untitled' img=gimp.image_list()[0] layer=img.active_layer print layer gimp.Layer 'Background' print pdb.gimp_edit_bucket_fill_full(layer,FG_BUCKET_FILL,NORMAL_MODE,0,0,True,False,SELECT_CRITERION_COMPOSITE,0,0) None print pdb.gimp_edit_bucket_fill_full(layer,FG_BUCKET_FILL,NORMAL_MODE,0,0,True,False,SELECT_CRITERION_V,0,0) None Running Gimp Windows 2.6.10 Any ideas? That must be something fairly obvious for anyone else... Ofnuts PS: flattery kind=outrightI take the opportunity to thank all the contributors to that fine piece of software./flattery ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
