Closed
Bug 55918
Opened 24 years ago
Closed 24 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•24 years ago
|
||
sounds like a bug for mr gif
Assignee: pavlov → saari
Target Milestone: mozilla1.0 → ---
Comment 7•24 years ago
|
||
I'll test the patch, thanks!
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Comment 8•24 years ago
|
||
Comment 9•24 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•24 years ago
|
||
Comment 11•24 years ago
|
||
r=pavlov
Comment 12•24 years ago
|
||
->dr to take patch
Assignee | ||
Comment 13•24 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•24 years ago
|
||
sr=hyatt
Assignee | ||
Comment 15•24 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 16•24 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
•