GNOME Bugzilla – Bug 94979
Zoom is broken for very large images
Last modified: 2009-08-15 18:40:50 UTC
I have a large gray scale TIFF image, roughly 9 inches wide (1800+ pixels) by 40+ feet long (112,000+ pixels), sampled at 200dpi, tiled in strips with 512 rows per strip. Am running the Windows installer versions of both GIMP and GTK which I just downloaded this evening. My machine has 640MB of RAM and a 768MB swap file, with about 20GB of free disk space, running under Windows XP. When I open the image, it loads fine, and displays as a very narrow, small strip in the image window, with the total height of the image sized to fit in the window. The image is FAR too small to see any useful detail at this extremely tiny size. I've tried zooming in with every possible method - zoom tool, menu options, keyboard shortcuts, etc. No matter how many times I try, and no matter which approach I use, the image still stays exactly the same size. I can't find any way to zoom into the image so that I can do anything useful. In the docs, it mentions that the minimum and maximum zoom factors supported by GIMP are 16 fold reductions and enlargements. At the initial size in which this image is desplayed, it is significantly smaller than a 16 fold reduction from actual size. I'm wondering if the lack of zoom functionality is triggered by such a small initial display size. Apparantly the initial display size is selected to force the entire image to fit within a window on the screen. But perhaps additional logic needs to be applied to insure that the 16X limit isn't exceeded when attempting to fit the image into the window. If that isn't the problem, then I can't think of what else might be triggering it, or any reasonable way to work around it. By the way, I'm NOT having and problems zomming in or out on images of more normal sizes. If anyone can let me know whether this problem is something that can be duplicated, and whether there is any chance that it might be fixed in the near future, I would sure appreciate it. Thanks in advance for any fix or other help that you may be able to provide. Kevin M. Round Rock, Texas
I found that if I drag across an area of the image no more than a few display pixels across using the zoom tool, that I CAN in fact zoom in on the image after all. However, there still appears to be a problem with at least some of the other zoom methods. For example, you can click the zoom tool in the image (without dragging), at the image NEVER zooms in any further while it is at the initial extremely small size. Not only that, but each time you click with the zoom tool and nothing happens gimp seems to leak a large amount of memory. HOWEVER, if you use the drag technique to zoom in on the image to a reasonable zoom factor first, then just clicking with the zoom tool works fine after that.
In the last entry, it should have said "... and the image NEVER zooms in any further...", rather than "... at the image ...".
I can confirm this bug, and it affects all systems. Basically, if you load an image that is larger than 64K pixels (I think), then the zoom options are broken. In 1.2.x, this happens because the view_zoom*() functions in app/commands.c call change_scale() in app/scale.c. This function computes the new zoom ratio for the image, but it does nothing if the new width or height is larger than 0xffff (64K). Here is the relevant piece of code: /* The slider value is a short, so make sure we are within its range. If we are trying to scale past it, then stop the scale */ if (sx < 0xffff && sy < 0xffff) { ... } This test should probably be removed.
This check looks like a motif artefact. Gtk/GIMP don't have short slider values. I guess we should just remove it, which will most probably work.
That's what I thought. I don't know which "slider value" this comment was refering to, but I did not find any shorts in the places that I checked (maybe some old gtk-0.x constraints?). So I think that the test should be removed. In addition, it would be nice if the initial zoom ratio of the image could be set to a more reasonable value. It starts at 1:147 on my display. I haven't checked which part of the code is responsible for that, though.
The image is initially scaled so as to fit in the screen. The code that does that (in 1.2) is in app/interface.c in create_display_shell. In brief, the scale is set such that neither the width nor the height of the display window are more that 0.75* the screen width or height (respectively), and it displays the entire image by default. It's kind of complicated code, and it's hard to tell exactly what's going on, but the logic is there. Cheers, Dave.
Created attachment 13472 [details] [review] patch to remove a useless check and to fix range checks
The check for (sx < 0xffff && sy < 0xffff) is indeed a historical artefact from Motif times and can be safely removed. The code in change_scale() also clamps scale_dest and scale_src between 0 and 0xf while they should actually be clamped between 0 and 0xff. We should probably not fix the latter in 1.2 since it might have unforeseen implications.
Applied the following changes to the stable branch. Needs to be fixed in 1.3 as well: 2003-01-10 Sven Neumann <sven@gimp.org> * app/interface.c (create_display_shell): break out of the loop that calculates the initial zoom ratio in case we hit our limits. Seems to fix bug #103030. * app/scale.c (change_scale): removed a check that dates back to the times when we used Motif for our user interface and scrollbars used short values. Fixes bug #94979.
Fixed in the HEAD branch as well: 2003-01-10 Sven Neumann <sven@gimp.org> * app/display/gimpdisplayshell-scale.c (gimp_display_shell_scale): merged fix for bug #94979 from stable branch. Go even further and don't limit the zoom ratio between 1:16 and 16:1.
The fix is part of the stable release 1.2.4. Closing this bug.