Some GIF images are incorrectly parsed and displayed

VERIFIED FIXED in mozilla0.9.1

Status

()

P1
normal
VERIFIED FIXED
18 years ago
7 years ago

People

(Reporter: barzee, Assigned: dr)

Tracking

Trunk
mozilla0.9.1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [imglib])

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
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

18 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

18 years ago
Created attachment 18214 [details]
An autumn scene with leaves, mountains, and sky

Comment 3

18 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

Updated

18 years ago
Status: NEW → ASSIGNED

Updated

18 years ago
Blocks: 61525

Updated

18 years ago
Blocks: 66959

Updated

18 years ago
Target Milestone: --- → mozilla1.0

Comment 4

18 years ago
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW

Comment 5

18 years ago
Still an issue on W2k build 2001041104
Whiteboard: [imglib]

Comment 6

18 years ago
sounds like a bug for mr gif
Assignee: pavlov → saari
Target Milestone: mozilla1.0 → ---

Comment 7

18 years ago
I'll test the patch, thanks!
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1

Comment 8

18 years ago
Created attachment 32992 [details] [diff] [review]
updated patch to fix this bug

Comment 9

18 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

18 years ago
Created attachment 33515 [details]
How Mozilla renders the Dilbert home page

Comment 11

18 years ago
r=pavlov

Comment 12

18 years ago
->dr to take patch
Assignee: saari → dr
Status: ASSIGNED → NEW
Keywords: patch
(Assignee)

Comment 13

18 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

18 years ago
sr=hyatt
(Assignee)

Comment 15

18 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 16

18 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.