GNOME Bugzilla – Bug 103030
Exceeding 187.7 feet physical dimension on single axis causes lockups and seg violations
Last modified: 2009-08-15 18:40:50 UTC
I work with scanned document images that are very long (up to several hundred feet) and relatively narrow (roughly 6 to 12 inches). These are typically scanned at 200 to 400 dpi, resulting in files with up to 600M pixels, being around 2K pixels on the narrow axis and up to 300K pixels on the long axis. Images of these dimensions are extremely important in the oil and gas industry, and the GIMP is one of the very few public domain programs in existence that can even begin to work with them. In the course of working with these images, I have run into a bug in the GIMP that seems to be triggered by exceeding a certain threshold in the physical size of the image. It is important to note that this limit is NOT a file size limitation nor a pixel count limit. By decreasing the image resolution, I can cause this problem to occur in relatively small image files with fairly low pixel counts, while by increasing the image resolution I can avoid the problem with much larger files sizes and pixel counts. The following simple test scenarios illustrate these problems. The results here are from using GIMP 1.2.4 under Win 2K on a machine with a 2GHz P4 and 1.5GB of RAM. However, it is my impression from email threads with several other folks that the same problems also occur under Linux and probably on other platforms as well. 1. Start the GIMP. 2. Select File->New from the menu. 3. Select Grayscale. 4. Enter each combination of Width, Height, and Resolution shown below, then hit ok and observe the results. Use the same resolution for both X and Y axes. My results are provided below. Similar problems (including lock ups, segmentation violations, application crashes, etc.) occur when attempting to load existing images with similar dimensions rather than creating new images from scratch. Width Height Resolution Image Size pixels pixels pix per in kilobytes Result 2 2252 1 4 image appears quickly 2 2253 1 4 no image, no disk I/O, CPU at 100% 1000 225200 100 214800 image appears quickly 1000 225250 100 214800 no image, no disk I/O, CPU at 100% 1000 450450 200 429600 image appears after small delay 1000 450500 200 429600 no image, no disk I/O, CPU at 100% 1000 900950 400 859200 image appears after small delay 1000 901000 400 859300 no image, no disk I/O, CPU at 100% Note that regardless of resolution, file size, or pixel count, problems occur when the physical length of a single axis exceeds approximately 187.7 feet. Please don't hesitate to contact me if any of this needs further discussion or explanation. I would also be very interested in testing any fixes that are made available. Thanks! s/KAM
I can observe some incoherent behaviour on gimp 1.2.3 on Linux too. It might be possible that this is related to the very extreme ratio of the image. I did open an 1000x225250 px image in 50dpi and the Gimp did not allow me to view the image pixel-for-pixel (100%), the initial zoom ratio was at 0%... 100x225200 with 100dpi failed for me too, i did not try higher resolutions because I don't have the memory for that available. The 1dpi images both worked for me.
The small images worked for me too but the larger ones seem to cause gimp-1.2 to go into an endless loop. I'd say it's this particular piece of code in interface.c: /* Limit to the size of the screen... */ while (n_width > s_width || n_height > s_height) { if (scaledest > 1) scaledest--; else if (scalesrc < 0xff) scalesrc++; n_width = width * (scaledest * SCREEN_XRES (gdisp)) / (scalesrc * gdisp->gimage->xresolution); n_height = height * (scaledest * SCREEN_XRES (gdisp)) / (scalesrc * gdisp->gimage->xresolution); } This loop tries to calculate the initial display scale ratio. And indeed, if I enter a debugging printf() there, I can verify that gimp gets stuck in that while loop if I try to reproduce your second example (1000 x 225200).
Created attachment 13470 [details] [review] simple patch to break out of the loop
The different behaviour for the reporter in the 1 dpi images might be dependant on the screen resolution. I did my tests with 1024x768.
The attached patch seems to fix the problem. I haven't yet tested all cases since I lack the physical RAM here but I will commit the change to CVS since it's definitely fixing a problem. After this change, I can create the image of 1000 x 225200 pixels at 100 dpi. It doesn't fit on screen (since that's what the loop tries to achieve) but at least it gets displayed at all.
We should test how this change affects bug #94979.
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.
I am running at 1600 x 1200 resolution, so that may explain the differences in behavior with the lowest resolution tests noted by others here who were running at lower resolutions.
Fixed in the HEAD branch as well: 2003-01-10 Sven Neumann <sven@gimp.org> * app/display/gimpdisplayshell.c (gimp_display_shell_new): merged fix for bug #103030 from stable branch.
The fix is part of the stable release 1.2.4. Closing this bug.