Re: [Gimp-developer] Enhancement - Diagonal line crop guide
Martin Nordholts wrote: * Tim Jedlicka wrote:** ** ** I stumbled upon this link describing the use of the Diagonal (45 degree ** diagonal from each corner of an image) as the optimum crop guide (better ** than rule-of-thirds or golden rule). ... * Oops, it of course depends on portrait or landscape which line you hit first. I think you will have to throw in an if there. I figured out a way to avoid the if statement. However, I don't know which method would be more efficient. i.e. should I try to avoid the if? These diagonal crop guides are very dynamic as you change your crop rectangle so I don't want to bog down the rendering. Just need some guidance on which route to take. I'll then have some follow up questions since I am not much of a coder (I'll do this off list unless directed otherwise). gimpregionselecttool.c has this bit of code when selecting a region: /* don't let the events come in too fast, ignore below a delay of 100 ms */ if (time - last_time 100) return; last_time = time; diff_x = coords-x - region_sel-x; diff_y = coords-y - region_sel-y; diff = ((ABS (diff_x) ABS (diff_y)) ? diff_x : diff_y) / 2.0; So there if doesn't look like it is too costly. The way I came up with to avoid the if is (pseudo code): X = x2-x1 Y = y2-y1 Z = [(X + Y) - ABS (X - Y)] / 2 So the upper left diagonal would go from x1,y1 to (x1 + Z), (y1 + Z) Any advice on which way to implement? -- Tim Jedlicka, Network Entomologist [EMAIL PROTECTED], http://www.galifree.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] redeye.c and gimp-2.4
On Sun, 11 Nov 2007 17:54:15 +1100 Owen [EMAIL PROTECTED] wrote: Tried updating Robert Merkel and Benoit Drooghaag's redeye.c into gimp-2.4 but it failed. I have 2.4 in /opt and called gimptool with that prefix, didn't set any other environment variable Here is a compile error redeye.c: In function ‘remove_redeye’: redeye.c:380: warning: ISO C90 forbids mixed declarations and code And attempting to run the script produces an error dialogue Procedure 'gimp-progress-init' has been called with a wrong value type for argument 'gdisplay' (#2). Expected GimpDisplayID, got GimpInt32. The script functions in 2.4, just throws the error message above. So for my once in a year red eye removal needs, I don't think I will worry about it. Sorry for the noise Owen ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
Sven Neumann wrote: Hi, On Sun, 2007-11-04 at 20:37 -0500, Daniel Falk wrote: Photoshop has a tool that works like the healing brush except that it doesn't require a source region to be specified before using the tool. When there are a lot of quick touch-ups to do, this is very convenient. Photoshop somehow guesses what it should use as source material and is often accurate. When it's not accurate, users can undo it, and then fall back on the healing brush and manually specify that information. Since we don't know how this works in detail, there is not much point in suggesting that we add such a feature. Could you explain the reasoning behind this? Such feature requests are always a good thing, and listening to them is a sign of a user-centric development team. By listening to them I don't mean *implementing* them, but a steady stream of such ideas can be beneficial. Though I suppose suggesting it on IRC might be more appropriate then on the list. Is that what you meant? Joe ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement - Diagonal line crop guide
Tim Jedlicka wrote: Martin Nordholts wrote: Oops, it of course depends on portrait or landscape which line you hit first. I think you will have to throw in an if there. I figured out a way to avoid the if statement. However, I don't know which method would be more efficient. i.e. should I try to avoid the if? These diagonal crop guides are very dynamic as you change your crop rectangle so I don't want to bog down the rendering. Just need some guidance on which route to take. I'll then have some follow up questions since I am not much of a coder (I'll do this off list unless directed otherwise). gimpregionselecttool.c has this bit of code when selecting a region: [...] So there if doesn't look like it is too costly. The way I came up with to avoid the if is (pseudo code): X = x2-x1 Y = y2-y1 Z = [(X + Y) - ABS (X - Y)] / 2 So the upper left diagonal would go from x1,y1 to (x1 + Z), (y1 + Z) Any advice on which way to implement? We can keep this on-list so other people can jump in the they wish to. From a performance point of view it is completely negligible to use an if. The time it takes to do the actual rendering of a line is orders of magnitude larger than having a conditional statement when calculating what coordinates to use. So the method of calculating what coordinates to use basically boils down to using the method that gives the most readable code, and I would say making use of an if is the most natural approach. - Martin Nordholts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
Joe Eagar wrote: Sven Neumann wrote: Hi, On Sun, 2007-11-04 at 20:37 -0500, Daniel Falk wrote: Photoshop has a tool that works like the healing brush except that it doesn't require a source region to be specified before using the tool. When there are a lot of quick touch-ups to do, this is very convenient. Photoshop somehow guesses what it should use as source material and is often accurate. When it's not accurate, users can undo it, and then fall back on the healing brush and manually specify that information. Since we don't know how this works in detail, there is not much point in suggesting that we add such a feature. Could you explain the reasoning behind this? Such feature requests are always a good thing, and listening to them is a sign of a user-centric development team. By listening to them I don't mean *implementing* them, but a steady stream of such ideas can be beneficial. Hi Joe Suggesting a new feature without specifying how the algorithm behind it work is pointless because how could the feature then be implemented? There are way too many other things to use the sparse GIMP developer resources for than to research details of other peoples feature requests. Note the difference between not listening to users and rejecting incomplete feature requests. We appreciate that you think GIMP is worth spending some on to help improving, but please don't take it personal if some of your suggestions are considered incomplete. It would be very appreciated if you took the time to research exactly how this algorithm is supposed to work. Regards, Martin Nordholts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
Martin Nordholts wrote: Hi Joe Suggesting a new feature without specifying how the algorithm behind it work is pointless because how could the feature then be implemented? There are way too many other things to use the sparse GIMP developer resources for than to research details of other peoples feature requests. Well people do it to me all the time with blender. . .I sometimes figure it out, and if I don't have time to develop it myself I'll try and tell some other dev how it works. And he also offered to show a video about it. Feature videos are really useful for reverse engineering; I don't understand why Sven said otherwise. You can tell a lot sometimes. Also it's not as if anyone *has* to devote time to figuring it out. Users will make many, many more requests then there will ever be time to code, much less research. Simply listening to the more popular or useful sounding ones will give devs an impression of what users really want, and even what they *need*. This can help formulate long-term plans, both for the project but also for individual devs who think that way. Such requests might not always be appropriate for a feature tracker, or even a mailing list (I think IRC is a good place to put forth these ideas). But they shouldn't be rejected out of hand, either. I'm not totally sure the best way to handle this; Blender has a functionality mailing list that kindof serves the purpose of random feature requests, but it doesn't work very well. Like I said, for unlikely or somewhat obscure features it seems to be best if users discuss them on IRC, then if a dev gets interested he can, oh I don't know add it to the feature tracker or something like that. Or if he's like me, he may think about these sorts of a features every once in a while, and in a year or two even implement a few of them. Note the difference between not listening to users and rejecting incomplete feature requests. We appreciate that you think GIMP is worth spending some on to help improving, but please don't take it personal if some of your suggestions are considered incomplete. Imho, an incomplete feature request is something like I want a tool to make healing brush better or something weird like that. I want a tool that automatically selects a source region for healing brush imho gives plenty of information, and if passed along to someone who knows the math behind it might even make sense to them. No one is obligated to research this, or even pay attention to it. All that matters is it sounds like a useful idea proposed by a user. And feature videos can help; I myself pieced 3d ray baking together from watching one modo video. It would be very appreciated if you took the time to research exactly how this algorithm is supposed to work. Regards, Martin Nordholts Well I don't have the time for that. :) Joe ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] redeye.c and gimp-2.4
Owen writes: Tried updating Robert Merkel and Benoit Drooghaag's redeye.c into gimp-2.4 but it failed. You know about Filters-Enhance-Red eye removal, standard with GIMP 2.4, I hope? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] redeye.c and gimp-2.4
Owen writes: Tried updating Robert Merkel and Benoit Drooghaag's redeye.c into gimp-2.4 but it failed. You know about Filters-Enhance-Red eye removal, standard with GIMP 2.4, I hope? No Wasn't there! Suspect it was removed during uninstalls of the old redeye.c :-( Just rebuilt 2.4 and all is well again Thank you Owen ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 and how to continue from here
resending... Sven wrote, On Fri, 2007-11-09 at 12:36 -0300, Joao S. O. Bueno wrote: One other smallf eature I will want to add is the ability to add free- angled guides. I have this almost complete on my codebase, just .XCF saving for it is missing. I should commit that early on 2.6 cycle. I would like to get some feedback from the UI team and from some artists on this. And of course the patch would have to be reviewed before it is committed. I am not yet convinced that this is an important feature and I also have the impression that it's just added ad-hoc without seeing the big picture. It certainly has the potential to cause a lot of problems. yeah. Kamila came up with the plan for rotating guides and I could see then how it could have an impact on for instance web design by breaking the normal hor/vert grid. and after a few minutes I could come up with a decent on-screen UI. but the real question is the priority of this yet-another-feature. something like geometry tools integration has a much higher priority than this. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 and how to continue from here
A Sunday 11 November 2007 20:48:27, peter sikking escreveu: but the real question is the priority of this yet-another-feature. something like geometry tools integration has a much higher priority than this. There eason I proposed this at this stage is that I have this feature complete minus UI and XCF saving in my GIMP tree. It has been like that for over an year when I was told it was too late to make it into gimp 2.4. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
