Closed Bug 9922 Opened 25 years ago Closed 21 years ago

Large JPEG images fail to display

Categories

(Core :: Graphics: ImageLib, defect, P3)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: azverkan, Assigned: tor)

References

Details

Attachments

(2 files)

The offending image, ignore the ftp link above
462.26 KB, image/jpeg
Details
we don't care about win16 anymore
648 bytes, patch
darin.moz
: review+
blizzard
: superreview+
asa
: approval1.6b+
Details | Diff | Splinter Review
Large JPEG images (10240x2048x32) download but fail to display, instead I see text saying http://-------.jpg where the image should be. IE3, IE4, and IE5 all correctly display the image No Netscape versions that I am aware of displays it correctly from 3.0 to 1999071108 Test platforms are x86 Redhat 6 Sparc Redhat 6 Win2000 Pro Win98 rel 2 Sample image at: ftp://24.95.39.29/Center_1999_07_13_15_11_GALAXSEE_4_100000.jpg
ImageLib currently supports a maximum image size of 8000x8000; I'm not sure if there are any plans to increase that limit. Pam?
This is related to bug 1971, where the browser crashed when it encountered JPEG images > 8000 px. That bug was marked resolved, since it no longer crashes. The browser is badly behaved though, since it gives no indication to the user that it won't display the image until its already been downloaded, nor does it ask the user for assistance, such as an offer to cancel the transfer, or a save dialog. If the browser is not going to support such large images, it should at least do something user -- and bandwidth -- friendly.
Is this a limitation of the image viewing code or is there just a limit that says not to display images greater than 8000x8000, but in theory we could? Seems to me, when you implement these restrictions its because you don't really know what your users need. I have always been in the habit of changing the restrictions to meet the users needs when I find its not good enough. So I ask can we get the limit upped? The images are only 500k big in their native jpeg format. One disadvanatage is that if your jpeg decompressor has to decompress the whole image before displaying it, you could possibly require 30 megs of ram to store the whole image, even though you can only look at 1600x1200 of it at any given time (or some value close to that). If this is a case, I would like to offer my services and implement a large image mode of jpeg viewing where it only decodes the part of the image that you need to display.
this issue should be dealt with later. -pn
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → LATER
Status: RESOLVED → VERIFIED
*** Bug 10133 has been marked as a duplicate of this bug. ***
*** Bug 21675 has been marked as a duplicate of this bug. ***
*** Bug 22394 has been marked as a duplicate of this bug. ***
*** Bug 50441 has been marked as a duplicate of this bug. ***
Reporting comments from dupe bug 50441 as it seems to be reproducible with a 3000X2000 img. From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m17) Gecko/20000807 BuildID: 2000080712 If image is larger X~3000 and Y~2000, the browser starts behave strangely - image is there during download, but as soon as download is complete it disappears. Also minimizing at this state is not possible, it only rezises this window or more precisely there seems to be no possibility to minimize all mozilla windows, at least one remains on screen despite all efforts. Reproducible: Always Steps to Reproduce: Drag or Open File a large image (3000X2000). Actual Results: Blank window (white), minimizing does not work properly. Expected Results: Shown me the picture and let me to minimize all mozilla windows. This seems to be some sort of buffer overflow (size) problem or actual image processor can't handle large images properly. ------- The image part of this bug is a dup of bug 9922 "Large JPEG images fail to display." (It is unrelated to the minimize problem, which is bug 46988 "browser window doesn't stay minimised")
*** Bug 49440 has been marked as a duplicate of this bug. ***
*** Bug 64793 has been marked as a duplicate of this bug. ***
I am seeing the same problem with a 4-bit GIF I have that is 810x55188. Keep in mind when you fix this that the GIF89a spec specifies height and width as an unsigned 16-bit integer (65535x65535 max size). Note that IE 5.5 does not display this image either. It does display properly in the graphics viewer I'm using, so it does appear to be a valid GIF. I don't see how you can say the status is VERIFIED when the complaint of this report is that the image does not display. The crashing bug (1971) is obviously a different behavior even if it is the same code. I tried to attach my file, but I don't think it worked...
It appears that somewhere along the line this bug has been fixed at least for the 10240x2048x32 image that's attached here. Not sure about all the other images that other people have found.
While this bug does appear to have been fixed for some definitions of large, it remains when we try to look at *very* large jpegs. http://visibleearth.nasa.gov/data/ev100/ev10031_Bolivia.A2001262.1445.250m.jpg (Image is nearly 4 MB) Build ID: 2002021503 on Windows 2000 SP2.
LATER is deprecated.
Status: VERIFIED → REOPENED
Resolution: LATER → ---
->pav. the last case WFM on Win NT 4.0, albeit slowly. I know I've had problems with Windows 98 before where both Mozilla and IE display only a blank background when viewing very large images over the network, suggesting it may not be a mozilla bug.
Assignee: pnunn → pavlov
Status: REOPENED → NEW
QA Contact: elig → tpreston
Image reference in Comment #15 WFM - Windows 2000;rv:1.1b;Gecko/2002080119
*** Bug 92413 has been marked as a duplicate of this bug. ***
*** Bug 163784 has been marked as a duplicate of this bug. ***
I noticed behavior like this on build 2002121215 of Mozilla 1.3a, on the following image: http://www.oqo.com/_images/H.jpg It's a 4577 x 3597 pixel image, 1.2 megabytes in disk size. I found this out from Internet Explorer 5.0 after Mozilla 1.3a froze up trying to load it. Internet Explorer 5.0 loads the image quickly (assuming a fast Internet connection) decompresses it completely into memory, taking about 20 MB of memory to do so, and succeeds in displaying it. Some time after decompressing the image, IE 5.0 seems to be able to release the memory even while keeping the image in the browser Window, reallocating it when necessary to decompress on the fly. Mozilla, on the other hand, just froze up within a few seconds of clicking on the link to load the image. I tried this several times... there were a few instances where if I could get Mozilla to respond to the mouse click to close the window, everything would come back and the program would keep operating as normal. Mostly, I tended to give up and force Mozilla out of memory via "End Task". I believe I was seeing the upper-left-hand corner of the image in the Mozilla window appearing probably about a minute after beginning to load the page;... I cannot be sure however, since I was unable to scroll the page to see any more of the image. Perhaps as much as 30 extra megabytes... I can't say for sure though whether it was more extra memory than IE 5.0 allocated at its peak allocation though. Operating System on my machine is Windows 2000. I'm not sure whether this information correctly applies to this bug, or to bug #100250, so I'm cross-posting this information to both bug reports. Thanks in advance for looking at it. --David
*** Bug 194016 has been marked as a duplicate of this bug. ***
*** Bug 194669 has been marked as a duplicate of this bug. ***
This bug seems to occur on very wide but "normally" high pictures (panorama pictures) too - but only sometimes. For example http://www.webeyes.at/panoramafotos/wienov/2002-01.2-1230_PAN-Leopoldsberg,RichtungKleineKarpaten!(x525)s.jpg (4699 by 525 pixel) will not display correctly, while http://www.webeyes.at/panoramafotos/wienwat/200203301407_PAN-Kaisermuehlenbruecke!(x525)s.jpg works (although the pic is 5635*525). ie6 displays all the pics.
*** Bug 203185 has been marked as a duplicate of this bug. ***
Attachment #891 - Attachment mime type: application/octet-stream → image/jpeg
All of the links in this bug work fine for me in 1.4a Linux (build 2003040105). Is this bug platform-specific?
All the images here also work for me using 2003050209/linux/gtk2 and memory consumption remains reasonable. Is this still a problem on windows? Does another bug have better / more demanding testcases (I couldn't find one, but that may be inefficient searching)? Can this be resolved fixed? If the issue applies only to certian platforms, can they be taken to a new bug, since the original problem reported here works?
I attempted to upload the large GIF file I had that will not display (at least in Moz 1.3, I don't have 1.4 yet), but received the error: "The file you are trying to attach is 4716 kilobytes (KB) in size. Non-patch attachments cannot be more than 300 KB. If your attachment is an image, try converting it to a compressable format like JPG or PNG, or put it elsewhere on the web and link to it from the bug's URL field or in a comment on the bug." I don't have anywhere on the web to put it where I could link to it, but if someone wants it and has a place to put it I would be happy to FTP it somewhere or if you contact me directly, I could open the port on my firewall long enough for you do FTP it off of my machine. If the large JPEG images are working and you want to take this one to a new bug (eg. "Large GIF images fail to display") I would have no problem with that.
The image that was causing me grief in 1.3 is working in 1.4b http://www.eightlines.com/neil/images/panaramic.jpg
Tested with 1.4b (2003050714) on Windows 2000. The first link reported in : Additional Comment #24 From Robert Kapeller 2003-04-01 02:51 still does not display correctly, but all of the other links do. My large GIF file still does not display. If I convert my large GIF file to JPEG it doesn't display in Mozilla either (still works in other programs, but it's still not less than 300K so I can't upload it), so it seems like some large JPEGs are still a problem at least on Windows...
Firebird 0.6 still does not display http://www.xs4all.nl/~jgurp/photos/2002dodecanese/kos_panorama_xxl.jpg, which is one of my holiday pictures. It's a 4443x527 pixels panorama photo (of the Greek island Kos), 110KB, jpeg format, saved from photoshop. Due to its small size this might be a good testcase. It's been attached to bug 163784 so there's no need to duplicate the attachment here probably. Oddly enough firebird does display the zoom mouse icon and if you click it a horizontal scrollbar appears. I can rightclick on the whitespace and even access the image properties. I have displayed images much larger than this in Mozilla. During the iraq crisis I looked at some satelite images size in the 10k x 10k range (40+MB). These displayed fine (though I did encounter some instability if I remember correctly).
*** Bug 217193 has been marked as a duplicate of this bug. ***
*** Bug 219818 has been marked as a duplicate of this bug. ***
*** Bug 221894 has been marked as a duplicate of this bug. ***
Flags: blocking1.6b?
Linux doesn't have any problems with these images. On MacOS the problem is that gfx can't handle images wider than 4095 pixels (bug 113406). On Win32 an old define for 16-bit windows was giving us grief. Patch follows.
Assignee: pavlov → tor
Attachment #135928 - Flags: superreview?(blizzard)
Attachment #135928 - Flags: review?(darin)
Attachment #135928 - Flags: approval1.6b?
Flags: blocking1.6b? → blocking1.6b+
Comment on attachment 135928 [details] [diff] [review] we don't care about win16 anymore r=darin
Attachment #135928 - Flags: review?(darin) → review+
Comment on attachment 135928 [details] [diff] [review] we don't care about win16 anymore a=asa (on behalf of drivers) for checkin to Mozilla 1.6 Beta.
Attachment #135928 - Flags: approval1.6b? → approval1.6b+
Attachment #135928 - Flags: superreview?(blizzard) → superreview+
Checked in.
Status: NEW → RESOLVED
Closed: 25 years ago → 21 years ago
Resolution: --- → FIXED
*** Bug 224123 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: