After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 62313 - zooming fails on super-wide images
zooming fails on super-wide images
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
1.x
Other All
: Normal normal
: ---
Assigned To: GIMP Bugs
Daniel Egger
Depends on:
Blocks:
 
 
Reported: 2001-10-14 18:08 UTC by Jamie Zawinski
Modified: 2003-04-17 14:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jamie Zawinski 2001-10-14 18:08:33 UTC
I have a bunch of 103600 x 256 gzipped PBM files that
I need to look at (they are histograms and analysis of
audio files, which is why they're so wide.)

When I load one into Gimp, it shows up zoomed all the
way out, so it looks like a horizontal line.

At this point, none of the zooming commands work: 
not "+", "-", or "1"; they do nothing.  Nor do those 
do anything when selected from the menu.

But then it gets strange -- if I select "Zoom 1:16"
from the menu, that works.  And after I have done 
that, I can use "+" and "-" to zoom in and out -- 
but it will never zoom in more than 16 times (it 
says "6%") 

But worst, it won't zoom *out* all the way -- I can't
get it to display at 100%, it will only come out as 
far as 50%.

So I'm guessing that the fact that the image came up
by default zoomed to outside of the normal range that
the zoomer tools try to constrain things to is what
confused matters.

I've seen this behavior on 1.2.2 on Linux, as well as
1.2.1 on Irix.

Though these PBM files are very wide, the files themselves
aren't all that large (only 3M uncompressed, 250k gzipped)
so I don't see evidence pointing to this being an 
out-of-memory situation.
Comment 1 Jamie Zawinski 2001-10-14 18:31:03 UTC
If I crop it down to a sane size, then do "1:1", then "undo",
everything seems to work fine: I'm then able to see the original
image at 100%.  So gimp is able to display/edit these images, 
it just gets stuck in a weird state when it loads them.
Comment 2 Branko Collin 2001-10-24 22:46:57 UTC
I do not seem to be able to confirm this in WinGIMP 1.2.0, then again
I do not seem to
have the ability to open or save PBM files. I tried XCF and PNM,
though, on images of exactly 30000x256 pixels.

With these files I am able to zoom in right away (not out). On
opening, the image is zoomed in to 2%. I cannot zoom out. When I zoom
in till past 6% (i.e. 7% or better), I can zoom back out to 6%, but
not to the original 2%. If that is not a bug, it seems like a UI
design error. By letting GIMP zoom to 2% on opening, the suggestion is
made to the casual user that (s)he also will be able to zoom out to 2%
later on.
Comment 3 Raphaël Quinet 2001-10-30 17:19:09 UTC
I can confirm this bug.  I tried it with 1.2.2 (Solaris) and I had
these strange problems with the zoom functions.

The initial zoom factor is shown as "0%".  Although I haven't tried
to debug the code, it looks like there is a rounding error in the
calculation of gdisp->scale (SCALEDEST and SCALESRC) when loading
the images and this causes some problems later.

By the way, the GTK rulers are not very pretty when the all numbers
have 5 or 6 digits.
Comment 4 Sven Neumann 2003-01-15 14:47:27 UTC
This is addressed but probably not solved completely by the changes I
did lately in order to fix bug #103030.
Comment 5 Sven Neumann 2003-04-17 14:35:39 UTC
This problem seems to be fixed reasonably in 1.3 and there is no way
we are going to change the code in 1.2 because that would very likely
introduce new bugs.

The rulers are indeed ugly but that should be handled in a different
bug report.