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: