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
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] 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] 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] 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] 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] 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"
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] 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] 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
