Hi Sven,

Thanks very much for your reply and consideration.

First of all, let me say that I think your suggestion of removing the 16:1 zoom factor limit as you have done in 1.3 is probably a good idea. In fact, I have already made the corresponding changes to my copy of gimp 1.2.4, and it seems to work well. Now, on to your my proposal and your suggested alternatives...

Upon further consideration, I must agree with your concern regarding a case such as the 2000 x 399 example that you gave. However, I don't think that either of the alternatives that you suggested would work well either...

I don't agree that your first suggestion (16X limit) is reasonable all by itself. Consider my typical image, 2000 x 100000 pixels. If we went with your first alternative, then the initial display of this image on my 1600 x 1200 screen would be at a 16X reduction, resulting in an image width of only 125 pixels, or just about 1.25 inches out of my available 12 inch display width. Your second alternative would produce even worse results.

My delay in getting back to you on this is due to the fact that I have spent almost the whole day thinking about this problem and tinkering with various potential solutions. I finally came up with something that is fairly simple and provides reasonable results on a very wide range of image sizes and aspect ratios. The attached files provide both my algorithm (scaleImage.sas), and the results that it would produce (scaleImage.txt) for test cases covering a wide range of possibilities from 10 to 100000 pixels in 25 diffferent combinations on both axes. I actually evaluated even more cases than that, but didn't include those in the attachment because they merely made the results more voluminous to wade through.

I wrote the attached algorithm in SAS to simplify my code changes while evaluating various options and to simplify reporting the results. However, this algorithm can be easily converted to C, and I will be happy to do so and provide a new patch if you agree that the results it produces are desirable. SAS is fairly straightforward as far as the code for the algorithm is concerned, so hopefully you will be able to interpret my code without any significant difficulty.

The new algorithm provides a maximum of compatibility with prior behavior for typical images, while also solving the high aspect ratio problem that I initially reported. It solves the problems that you found with my previous proposal, as well as those that I found with the alternatives that you suggested. It maintains the 16 fold automatic scale reduction limit that was intended by prior versions of app/interface.c, and also addresses the 1 pixel minimum issue that you raised.

I'd appreciate it if you could look all of this over and let me know if you think it is acceptable. If so, then I will recode in C and provide a new patch as soon as possible.

Thanks once again for considering my input.

Regards, s/KAM

----- Original Message ----- From:
To:
Sent: Wednesday, January 15, 2003 8:45 AM Subject: [Bug 103547] Changed - Initial Display Scale Too Small for High Aspect Ratio Images

http://bugzilla.gnome.org/show_bug.cgi?id=103547

------- Additional Comments From sven@gimp.org 2003-01-15 09:45 ------- I haven't checked but I think the proposed solution has some drawbacks. Think of an image of 2000x399 pixels. If we'd go for your proposed change, the image would be displayed with a zoom ratio of 1:1 while earlier versions of Gimp chose 1:2 or 1:3 to be able to display the entire image. I don't want the behaviour for such common formats to change.

I'd like to propose two different solutions:

(1) Limit the initial zoom ratio to 1:16. This would be consequent since zooming in and out using the shortcuts does currently not work if you are outside the 16:1 .. 1:16 range.

(2) Add code that assures that the initial zoom ratio is choosen in a way that assures that the smaller axis is not scaled down below a minimal size of 1 pixel.

I'd prefer solution (1) since it would reduce the time needed to open a large image and create the initial display. Of course it means that very large images (larger than 16 times the screen size) are not displayed entirely when they are opened. As outlined in bug #62313, this is broken anyway. So perhaps we should go for (1) but remove the limitation for the zoom in / zoom out commands as I've already done in the 1.3 tree.

The SAS System 13:37 Wednesday, January 15, 2003 32

----------------------- Horizontal Screen Resolution=1280 Vertical Screen Resolution=1024 Previous Scale Factor=0.125 ------------------------

Horizontal Vertical Horizontal Vertical Scale Scale Effective Scaled Scaled Horizontal Vertical Horizontal Vertical Horizontal Vertical Image Image Factor Factor Scale Image Image Window Window Window Window Scrolling Scrolling Size Size Numerator Denominator Factor Size Size Size Size Fraction Fraction Required Required

10 10 1 1 1.00000 10 10 10 10 1% 1% NO NO 10 100 1 1 1.00000 10 100 10 100 1% 10% NO NO 10 1000 1 2 0.50000 5 500 5 500 0% 49% NO NO 10 10000 1 10 0.10000 1 1000 1 768 0% 75% NO YES 10 100000 1 8 0.12500 1 12500 1 768 0% 75% NO YES 100 10 1 1 1.00000 100 10 100 10 8% 1% NO NO 100 100 1 1 1.00000 100 100 100 100 8% 10% NO NO 100 1000 1 2 0.50000 50 500 50 500 4% 49% NO NO 100 10000 1 14 0.07143 7 714 7 714 1% 70% NO NO 100 100000 1 8 0.12500 12 12500 12 768 1% 75% NO YES 1000 10 1 2 0.50000 500 5 500 5 39% 0% NO NO 1000 100 1 2 0.50000 500 50 500 50 39% 5% NO NO 1000 1000 1 2 0.50000 500 500 500 500 39% 49% NO NO 1000 10000 1 14 0.07143 71 714 71 714 6% 70% NO NO 1000 100000 1 8 0.12500 125 12500 125 768 10% 75% NO YES 10000 10 1 10 0.10000 1000 1 960 1 75% 0% YES NO 10000 100 1 11 0.09091 909 9 909 9 71% 1% NO NO 10000 1000 1 11 0.09091 909 90 909 90 71% 9% NO NO 10000 10000 1 14 0.07143 714 714 714 714 56% 70% NO NO 10000 100000 1 11 0.09091 909 9090 909 768 71% 75% NO YES 100000 10 1 8 0.12500 12500 1 960 1 75% 0% YES NO 100000 100 1 8 0.12500 12500 12 960 12 75% 1% YES NO 100000 1000 1 8 0.12500 12500 125 960 125 75% 12% YES NO 100000 10000 1 14 0.07143 7142 714 960 714 75% 70% YES NO

------------------------- Horizontal Screen Resolution=1280 Vertical Screen Resolution=1024 Previous Scale Factor=1 --------------------------

Horizontal Vertical Horizontal Vertical Scale Scale Effective Scaled Scaled Horizontal Vertical Horizontal Vertical Horizontal Vertical Image Image Factor Factor Scale Image Image Window Window Window Window Scrolling Scrolling Size Size Numerator Denominator Factor Size Size Size Size Fraction Fraction Required Required

10 10 1 1 1.00000 10 10 10 10 1% 1% NO NO 10 100 1 1 1.00000 10 100 10 100 1% 10% NO NO 10 1000 1 2 0.50000 5 500 5 500 0% 49% NO NO 10 10000 1 10 0.10000 1 1000 1 768 0% 75% NO YES 10 100000 1 1 1.00000 10 100000 10 768 1% 75% NO YES 100 10 1 1 1.00000 100 10 100 10 8% 1% NO NO 100 100 1 1 1.00000 100 100 100 100 8% 10% NO NO 100 1000 1 2 0.50000 50 500 50 500 4% 49% NO NO 100 10000 1 14 0.07143 7 714 7 714 1% 70% NO NO 100 100000 1 1 1.00000 100 100000 100 768 8% 75% NO YES 1000 10 1 2 0.50000 500 5 500 5 39% 0% NO NO 1000 100 1 2 0.50000 500 50 500 50 39% 5% NO NO 1000 1000 1 2 0.50000 500 500 500 500 39% 49% NO NO 1000 10000 1 14 0.07143 71 714 71 714 6% 70% NO NO 1000 100000 1 2 0.50000 500 50000 500 768 39% 75% NO YES 10000 10 1 10 0.10000 1000 1 960 1 75% 0% YES NO 10000 100 1 11 0.09091 909 9 909 9 71% 1% NO NO 10000 1000 1 11 0.09091 909 90 909 90 71% 9% NO NO 10000 10000 1 14 0.07143 714 714 714 714 56% 70% NO NO 10000 100000 1 11 0.09091 909 9090 909 768 71% 75% NO YES 100000 10 1 1 1.00000 100000 10 960 10 75% 1% YES NO 100000 100 1 1 1.00000 100000 100 960 100 75% 10% YES NO 100000 1000 1 2 0.50000 50000 500 960 500 75% 49% YES NO 100000 10000 1 14 0.07143 7142 714 960 714 75% 70% YES NO

------------------------- Horizontal Screen Resolution=1280 Vertical Screen Resolution=1024 Previous Scale Factor=8 --------------------------

Horizontal Vertical Horizontal Vertical Scale Scale Effective Scaled Scaled Horizontal Vertical Horizontal Vertical Horizontal Vertical Image Image Factor Factor Scale Image Image Window Window Window Window Scrolling Scrolling Size Size Numerator Denominator Factor Size Size Size Size Fraction Fraction Required Required

10 10 1 1 1.00000 10 10 10 10 1% 1% NO NO 10 100 1 1 1.00000 10 100 10 100 1% 10% NO NO 10 1000 1 2 0.50000 5 500 5 500 0% 49% NO NO 10 10000 1 10 0.10000 1 1000 1 768 0% 75% NO YES 10 100000 8 1 8.00000 80 800000 80 768 6% 75% NO YES 100 10 1 1 1.00000 100 10 100 10 8% 1% NO NO 100 100 1 1 1.00000 100 100 100 100 8% 10% NO NO 100 1000 1 2 0.50000 50 500 50 500 4% 49% NO NO 100 10000 1 14 0.07143 7 714 7 714 1% 70% NO NO 100 100000 8 1 8.00000 800 800000 800 768 63% 75% NO YES 1000 10 1 2 0.50000 500 5 500 5 39% 0% NO NO 1000 100 1 2 0.50000 500 50 500 50 39% 5% NO NO 1000 1000 1 2 0.50000 500 500 500 500 39% 49% NO NO 1000 10000 1 14 0.07143 71 714 71 714 6% 70% NO NO 1000 100000 1 2 0.50000 500 50000 500 768 39% 75% NO YES 10000 10 1 10 0.10000 1000 1 960 1 75% 0% YES NO 10000 100 1 11 0.09091 909 9 909 9 71% 1% NO NO 10000 1000 1 11 0.09091 909 90 909 90 71% 9% NO NO 10000 10000 1 14 0.07143 714 714 714 714 56% 70% NO NO 10000 100000 1 11 0.09091 909 9090 909 768 71% 75% NO YES 100000 10 8 1 8.00000 800000 80 960 80 75% 8% YES NO 100000 100 7 1 7.00000 700000 700 960 700 75% 68% YES NO 100000 1000 1 2 0.50000 50000 500 960 500 75% 49% YES NO 100000 10000 1 14 0.07143 7142 714 960 714 75% 70% YES NO

Actually my images under the "stable" 1.2.4 version of the gimp are already being initially scaled well outside of the 1/16 to 16/1 range, and have been for quite a while now (since at least October if not earlier).

Thanks a lot for the great tip regarding the "1" key. I wasn't aware of that. That will certainly be a significant help to me, assuming that my initial scaling proposal will not be accepted. Just goes to show you learn something new every day! Wish I had noticed that one in the docs or someone had told me about it months ago...

I do still have one question for you guys who are against my proposal though: Have any of you ever actually used the GIMP with images of the size and aspect ratio that I'm routinely working with??? I'm betting not. Perhaps you might consider putting more weight on someone's opinion who is ACTUALLY using the gimp with these types of images. However, please take that comment with a grain of salt. I'm not all that stuck up on my own opinions, even though I am stubborn as hell :-) But I am just a little frustrated right now, because I've put in a fair amount of time and effort into getting this issue resolved with a fix that will save me some time, and all of the negatives that folks are bringing up seem to be hypothetical, theoretical, and philosophical arguments rather than something that helps me to get real work done!

Never the less, as a programmer and application developer myself, and one who can appreciate a certain amount of consistency, elegance, and simplicity in a program, I do understand some of the arugments against my proposed change, even though that's still not the approach that I would choose.

Oh well, , I guess I will resign myself to losing this one. It's gonna be tough to give up on the modified version of the gimp that I built and have been using for the past week or so, after getting used to my documents automatically being displayed exactly the way that I would like to see them. But like I said before, I can't really afford to get into a mode of maintaining my own customized version of the gimp. So, I guess out the door my nice changes go :-(

s/KAM

----- Original Message ----- From:
To:
Sent: Thursday, January 16, 2003 5:33 AM Subject: [Bug 103547] Changed - Initial Display Scale Too Small for High Aspect Ratio Images

http://bugzilla.gnome.org/show_bug.cgi?id=103547

------- Additional Comments From quinet@gamers.org 2003-01-16

06:33 -------

Wow! Many comments since yesterday... I would just like to point out that I tend to agree with Sven: I think that some kind of consistency is important in the user interface, and most users would expect to see the image scaled to fit the screen (even if it is only 1 pixel wide) because this gives them a good idea of the aspect ratio and it is also easy to understand and predict how the GIMP will open an image.

The problem is the limitation to the 16:1 or 1:16 aspect ratio of the stable GIMP, which prevents very thin images from being scaled to the appropriate size for fitting entirely on the screen.

If we really want to change the stable GIMP in order to fix this bug, then I would prefer to invest some time in removing the 16:1 and 1:16 limits than to implement a different algorithm for the initial scaling factor. Note that even if the image is intially scaled in such a way that one a 1-pixel line or column is visible, it only takes one keystroke (pressing the "1" key) to get the 1:1 aspect ratio.