169392 - can't display PNG images with short IDAT chunks

Status: VERIFIED DUPLICATE of bug 170352

(Core :: Graphics: ImageLib, defect)

Description

[jmorzins]

There are some PNG files that Mozilla can't display.  I've captured some of the
bad files and written a short write up at
  http://web.mit.edu/jmorzins/www/mozilla/png-bug.html

The only common element I've seen between the non-displaying files and the rest
of the PNGs in the world is that one of the IDAT chunks in the non-displaying
files is very short -- 1 byte and 3 bytes respectively, in the two bad files
I've found so far.  The files load in every other PNG application I've tried,
and "pngcheck" finds no problem with the files.

There may be a race condition involved; sometimes a bad image can load
partially, only to be replaced by a "broken image" icon when the page is reloaded.

I've seen this bug with multiple Mozilla versions, including the 1.1 release.

Comment 1

[Olivier Cahagne]

related: bug 160453.

Comment 2

[tenthumbs]

This is exactly bug 160453. Run pngcheck -vv and you'll see that the
last IDAT chunk contains no useful data. The chunk size doesn't really 
matter.

If you do pngcheck -qt you'll also see that the software is "gif2png 0.6
(beta)" which is ancient. It's not surprising it's broken.

Comment 3

[Olivier Cahagne]

*** This bug has been marked as a duplicate of 160453 ***

Comment 4

[Glenn Randers-Pehrson]

I don't think it's a dupe of 160453.  This one isn't exhibited by the rpng2-x
app that comes with libpng, for any version of libpng 1.0.9 through 1.2.5rc3,
and therefore might not be fixed by upgrading to libpng-1.2.5.

Comment 5

[Jason Summers]

Here's a more detailed test page:
http://entropymine.com/jason/testbed/pngshortidat/

The chunk size at which it stops working does not seem to be exactly the same
for all images.

Comment 6

[Olivier Cahagne]

Reopening as per comments. Will leave triage to the component owner.

Comment 7

[tenthumbs]

Using rpng2-x from libpng-1.2.4 I tested all the images from both pages
and found these errors.

schlock20020415b.png
rpng2-x:  pass 1 of 7readpng2 libpng error: Too much data in IDAT chunks
schlock20020916.png
rpng2-x:  pass 1 of 7readpng2 libpng error: Too much data in IDAT chunks
pngnow01.png
rpng2-x:  pass 1 of 7readpng2 libpng error: Too much data in IDAT chunks
pngnow02.png
rpng2-x:  pass 1 of 7readpng2 libpng error: Too much data in IDAT chunks
pngnow03.png
rpng2-x:  pass 1 of 7readpng2 libpng error: Too much data in IDAT chunks
pngnow04.png
rpng2-x:  pass 1 of 7readpng2 libpng error: Too much data in IDAT chunks
pngnow05.png
rpng2-x:  pass 1 of 7readpng2 libpng error: Too much data in IDAT chunks

All of the "bad" images from the first URL and some from the second
display the same symptoms as bug 160453 and these images are exactly the
ones which do not display in mozilla. All the others display, at least on
Linux. If Windows is different then there's more than one problem here.

All images work with rpng2-x from libpng-1.2.5rc1.

Comment 8

[Jason Summers]

As far as I can tell, bug 160453 is actually two different bugs:

(A) A request for a workaround for invalid PNG files that really do have "too
much data", in some way.

(B) Certain valid PNG files are erroneously identified as having "too much
data". This depends in some way on the byte counts of the IDAT chunks.

This bug is a duplicate of bug 160453(B), but not bug 160453(A).

Comment 9

[Jason Summers]

This is also a duplicate of bug 169105. Same image even.

Comment 10

[jmorzins]

Given that bug 169105 misdiagnoses the problem (it thinks the problem is that
the image has less than 64 colors), I would assign the "duplicate" label in the
opposite direction, listing it as a duplicate of this.

Yes, it does appear that bug 160453 can be classified into the divisions you
mention.  I suppose I'll have to wait and see whether the bugzilla triagers
think it's easier to have a broad bug 160453, or whether they prefer to narrow
160453 to just case (A) and let this bug handle case (B).

Comment 11

[Jason Summers]

I don't doubt that case (A) exists, but I'd like to suggest the possibility that
all the reported problems are really caused by case (B). Every testcase I've
looked at, I could make it work by divvying up the IDAT data differently.

But assuming that this will all be fixed by updating libpng (bug 170352), it's
probably not worth worrying about too much.

Comment 12

[tor]

The test images from comment 5 and the test URL load fine in moz compiled with
libpng-1.2.5rc3.

Comment 13

[tor]

*** This bug has been marked as a duplicate of 170352 ***