Closed
Bug 55918
Opened 24 years ago
Closed 23 years ago
Some GIF images are incorrectly parsed and displayed
Categories
(Core :: Graphics: ImageLib, defect, P1)
Core
Graphics: ImageLib
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: barzee, Assigned: dr)
References
Details
(Whiteboard: [imglib])
Attachments
(3 files)
14.21 KB,
image/gif
|
Details | |
1.55 KB,
patch
|
Details | Diff | Splinter Review | |
71.64 KB,
image/jpeg
|
Details |
GIF images that do not contain a "clear code" immediately after the code tables fills up are not displayed properly. Unfortunately, I don't have an external web site where I can post such an image so that you can load it and see the problem. However, if you want such an image, I can email you one. Here is an excerpt from the GIF 89a specification that explains deferred clear code problem in a little more detail: DEFERRED CLEAR CODE IN LZW COMPRESSION There has been confusion about where clear codes can be found in the data stream. As the specification says, they may appear at anytime. There is not a requirement to send a clear code when the string table is full. It is the encoder's decision as to when the table should be cleared. When the table is full, the encoder can chose to use the table as is, making no changes to it until the encoder chooses to clear it. The encoder during this time sends out codes that are of the maximum Code Size. As we can see from the above, when the decoder's table is full, it must not change the table until a clear code is received. The Code Size is that of the maximum Code Size. Processing other than this is done normally. Because of a large base of decoders that do not handle the decompression in this manner, we ask developers of GIF encoding software to NOT implement this feature until at least January 1991 and later if they see that their particular market is not ready for it. This will give developers of GIF decoding software time to implement this feature and to get it into the hands of their clients before the decoders start "breaking" on the new GIF's. It is not required that encoders change their software to take advantage of the deferred clear code, but it is for decoders. I isolated the bug in the Mozilla 6 pre release 3 source, and here is the fix to mozilla/modules/libimg/gif.cpp in "diff -c" format: *** gif.cpp.orig Thu Apr 6 15:51:58 2000 --- gif.cpp Mon Oct 9 22:39:51 2000 *************** *** 485,507 **** } - /* Define a new codeword in the dictionary. */ *stackp++ = firstchar = suffix[code]; - prefix[avail] = oldcode; - suffix[avail] = firstchar; - avail++; - if(avail >= MAX_BITS) - return -1; ! /* If we've used up all the codewords of a given length ! * increase the length of codewords by one bit, but don't ! * exceed the specified maximum codeword size of 12 bits. ! */ ! if (((avail & codemask) == 0) && (avail < 4096)) { ! codesize++; ! codemask += avail; } oldcode = incode; /* Copy the decoded data out to the scanline buffer. */ --- 485,510 ---- } *stackp++ = firstchar = suffix[code]; ! /* Define a new codeword in the dictionary. */ ! if (avail < 4096) { ! prefix[avail] = oldcode; ! suffix[avail] = firstchar; ! avail++; ! ! /* If we've used up all the codewords of a given length ! * increase the length of codewords by one bit, but don't ! * exceed the specified maximum codeword size of 12 bits. ! */ ! if (((avail & codemask) == 0) && (avail < 4096)) ! { ! codesize++; ! codemask += avail; ! } } + oldcode = incode; /* Copy the decoded data out to the scanline buffer. */ If you have any questions, please send me email. I will gladly respond. I really want this bug fixed, so I can view my tightly compressed GIF images with Mozilla. Thank you.
Comment 1•24 years ago
|
||
Rex Barzee, if you revisit your bug report (see the link at the top of this notice) you can attach a test image to the report itself. See under the Assigned To:, URL:, Summary: and Keywords: fields the Attachements: Create a new attachement link. Click that link ad attach a test GIF to this report. If it is still a problem in current Mozilla builds I will set this bug status to New and hopefully we can get it fixed. Thanks for your help in testing Mozilla and reporting bugs.
Reporter | ||
Comment 2•24 years ago
|
||
Comment 3•24 years ago
|
||
setting bug status to New. attachement from 10/28/00 09:05 fails to display with 103004 mozilla trunk build on NT. This attachment also fails to display on Navigator 4.7 (loads the first couple of rows of pixels at the top of the image and then stops) IE 5.5 displays the image fine.
Status: UNCONFIRMED → NEW
Ever confirmed: true
All pnunn bugs reassigned to Pav, who is taking over the imglib.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW
Comment 6•23 years ago
|
||
sounds like a bug for mr gif
Assignee: pavlov → saari
Target Milestone: mozilla1.0 → ---
Comment 7•23 years ago
|
||
I'll test the patch, thanks!
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Comment 8•23 years ago
|
||
Comment 9•23 years ago
|
||
Also see: http://www.dilbert.com . On my machine, the right ad is broken until I scroll or resize the Mozilla window. Generally, some images (or half of them) are missing. I will add a screenshot as attachment. I'm running SuSE 7.1, M0.9, BID 2001050521 .
Comment 10•23 years ago
|
||
Comment 11•23 years ago
|
||
r=pavlov
Comment 12•23 years ago
|
||
->dr to take patch
Assignee | ||
Comment 13•23 years ago
|
||
patch is all greek to me, but i'll get sr and checkin...
Severity: major → normal
Status: NEW → ASSIGNED
Priority: P3 → P1
Comment 14•23 years ago
|
||
sr=hyatt
Assignee | ||
Comment 15•23 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 16•23 years ago
|
||
Verified fixed mac build 2001052405 Verified fixed linux build 2001052310 Verified fixed w2k build 2001052404
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•