[Gimp-developer] Re: Alternative zoom algorithm
Hello. More in-between steps in the logaritmic zoom (...,2:1,1:1,1:2, 1:4,...) would be nice, but nothing fancy like more steps around 1:1 is not needed here. There are more important problems relating to the zoom and resolution: I scanned a drawing and wanted to complete it with GIMP. After I had zoomed the large image, largest pencil was too tiny for drawing. This gives an idea that GIMP could have a tool which computes the scale ratio required for matching the scanned pencil size with the size of the selected pencil. The tool could work this way: (1) select the pencil, (2) start the tool, (3) zoom the image until the selected pencil size matches the scanned pencil size, (4) start scale operation which takes the zoom ratio as scale ratio. That would require that GIMP can draw the outline circle (say) of the pencils. Does not solve the underlying problems of GIMP, but is better than nothing. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Alternative zoom algorithm
Hi, Juhana Sadeharju [EMAIL PROTECTED] writes: There are more important problems relating to the zoom and resolution: I scanned a drawing and wanted to complete it with GIMP. After I had zoomed the large image, largest pencil was too tiny for drawing. Any particular reason you did not press the New button in the brush dialog to obtain a larger brush? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Alternative zoom algorithm
This is my first post here. Is the proper protocol to
1) post here to the mail lists?
2) put on the bug list?
3) both?
In reference to the earlier discussion about uniform
zooming scale factors, why not let the user choose his
own (reasonable) scale factor in preferences? It
could be set to sqrt(2) by default. The code
below rounds to the nearest multiple of the factor. I
think it is an elegant solution which gives a lot of
power to the user.
gdouble
gimp_display_shell_scale_zoom_step (GimpZoomType
zoom_type,
gdouble
scale,
gdouble factor)
{
/* scale is scaled by factor which is nominally =
sqrt(2) */
/* the user enters factor in preferences */
/* need enough significant digits in factor to get
nice scales */
/* e.g. factor = sqrt(2) = 1.414213562373 */
switch (zoom_type)
{
case GIMP_ZOOM_IN:
factor = CLAMP (factor, 1.1, 4.0);
scale = CLAMP (scale, 1.0/256.0, 256.0);
scale =
pow(factor,floor(log(scale)/log(factor)+0.5)-1.0);
break;
case GIMP_ZOOM_OUT:
factor = CLAMP (factor, 1.1, 4.0);
scale = CLAMP (scale, 1.0/256.0, 256.0);
scale =
pow(factor,floor(log(scale)/log(factor)+0.5)+1.0);
break;
case GIMP_ZOOM_TO:
break;
}
return CLAMP (scale, 1.0/256.0, 256.0);
}
Regards,
Harold
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Alternative zoom algorithm
top flight ([EMAIL PROTECTED]) wrote: This is my first post here.? Is the proper protocol to 1) post here to the mail lists? 2) put on the bug list? 3) both? ? Well, since we are in a discussion here a post on the bug list might be a bit too early. But yes, a enhancement request in bugzilla will definitely get a response, but on the zooming behaviour there are enough open bugs right now :) In reference to the earlier discussion about uniform zooming scale factors, why not let the user choose his own (reasonable) scale factor in preferences? It could be set to sqrt(2) by default. The code below?rounds to the nearest multiple of the?factor.? I think it is an elegant solution which gives a lot of power to the user. Well, we have a lot of preferences already and one can have too much degrees of freedom. When I brought up different sets of zoom presets available in the preferences, some people were complaining, that preferences are just a sign of a lack of descision competence :-) [ code snipped for arbitrary factors ] As you might have seen in the earlier discussion, for some people it is very important, to get sane ratios like 1:x as magnification factors. Your approach of course would work, but usually result in ugly fractions. The list of fractions from the earlier Mails were the result of a compromise, a move back to real floats is not an option. Personally I believe that only factors based on the n'th roots of two are reasonable choices, since we usually want to have the double, quadruple etc. sizes of the images in the list of zoom factors. For a short time we had something based on the golden mean in CVS, and it really felt clumsy, because it was so hard to hit the powers of two as magnification factors... sqrt(2) gives us two steps between each doubling of the size, and it seems to be fine enough. I might experiment later with 2**(1/3), but that isn't really urgent now. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Alternative zoom algorithm
On Sat, 17 Jan 2004, Marc wrote: Date: Sat, 17 Jan 2004 20:22:05 +0100 From: Marc [EMAIL PROTECTED] To: Sven Neumann [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Re: Alternative zoom algorithm On Sat, Jan 17, 2004 at 05:24:51PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: Get used to it, that's how gimp-developer works :( Marc, your comment is highly inappropriate. Eh, really? Yes, maybe I should have said that's how gimp developers work, which would be more approriate. I commend Sven for his diplomacy. I am very pleased by Simons explanation. This may have been the way some of the GIMP developers have worked in the past but I hope that in future the GIMP developers will do just like Simon has done and explain his criticism in a fair and clear manner so that no one will have reason to get offended. I think that more developers will be attracted to the GIMP if they are forgiven for impatient mistakes and the over enthusiasm of beginners and not knowing how things work around here but are given the chance to learn. Sincerely Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Alternative zoom algorithm
[EMAIL PROTECTED] (2004-01-17 at 0309.30 +0100): Ideas? Suggestions? (But please do not complain about the lack of your favourite zoom level, trying to insert specific missing zoom levels in the table above would completely break the advantages of nearly homogenous zooming...) After being pointed in IRC to check what other apps do, a search that resulted in similar things to what I was trying, going thru discarding what people is used to or the levels for typical images and finaly get my patch encouragingly classified as evil, I think I will stop wasting time and keep my ideas and suggestions to myself. So I only have a question: why is homougenous zooming the holy grail that makes the rest of issues discardable? Something other than the words smooth or continous, which only make me think about animation and not about painting. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Alternative zoom algorithm
On Sat, Jan 17, 2004 at 01:26:09PM +0100, GSR - FR [EMAIL PROTECTED] wrote: what people is used to or the levels for typical images and finaly get my patch encouragingly classified as evil, I think I will stop wasting time and keep my ideas and suggestions to myself. Get used to it, that's how gimp-developer works :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Alternative zoom algorithm
hi, On Fri, Jan 16, 2004 at 09:49:31PM +0100, GSR / FR wrote: Hi: I saw that zoom has been changed following bug 124073. After trying it, I did not liked it. Personally I think it gives too much importance to extreme zooms, forgeting most people work around 100%. 4000 to 20 pix images in a reasonable size monitor is what I normally see, not 4 pix or people with one pixel painted as 128*128 screen pixels. I also did not liked that it quickly went to fractional numbers in which one of X:Y is not 1, cos it does not look very pleasing due the fast way Gimp interpolates when displaying. i read a lot of the mail in the threads that followed. I tried to figure out the best way to handle this zoom problem. i think that any functionality should be allowed and encouraged until the info dialog is fixed. maybe the zoom and the info can work together rather than separately. if the user can distinguish the difference between the use of the image then TheGIMP could easier determine the set of rations to use. for instance, in the info dialog the user could choose production and it would first, only accept xcf format for save and second, allow extreme zooms. if the user toggled screen the ratios and save sizes could be limited to screen displays. Different print expectations could be expressed and many of the decisions for the new user could be preset and the GIMP could not just guess what would be best for everything. seems like this is only one use that a better info dialog could help with. determining format and image mode would be easier. i have enough experience with the different image handling, i could help to make the decisions about what the zoom ratio should be if i know you are making a web image and the resolution and image mode that would be best (if you cannot figure it out yourself). lets work on the info dialog. how can we make this thing work properly? carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Alternative zoom algorithm
Marc Lehmann ([EMAIL PROTECTED]) wrote: [...] discussion on #gimp and #gimp is IRC and not gimp-developer The discussion took partly place here also, so please take your dogs back and complain elsewhere about appropriateness. you haven't been around on #gimp when this conversation took place, Well, the discussion here was quite similar (although on #irc it seems to have been worse, which is not surprising to me, many people on #gimp are rather bigheaded and aggressive, much more so than on gimp-developer). If you want to argue about personal matters please do it off the list. The discussion started in bug #124073 and continued on IRC and now gets moved to these lists. GSR wants to replace something I implemented and have put some thought in it. It should be me who is pissed because of this, however, instead of just defending my implementation I chose to offer a compromise on this list. GSR did not yet convince me, that his implementation has any advantages over the current implementation in CVS and I will continue to ask for clarifications until I am convinced that replacing the implementation in CVS is a good thing. Mainly his arguments seem to be: 100% is more important than extreme ratios (please note that my implentation does not have *any* bias towards a certain zoom ratio, and I believe that this is a good thing. And if we need finer grained step it is a two line patch to replace sqrt(2) with something else) and that for some reason certain percentage/ratio numbers are more important than others, which I also doubt. There is no need for 1:7, when 1:6 visually basically looks the same. The fact that certain ratios look bad with the current non interpolating code for the image view cannot be solved by restricting the ratios available. This has to be done in the view code. And btw. I doubt that 1:3 looks significantly better than 10:29. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
