28616 - png image not displayed

Status: VERIFIED DUPLICATE of bug 48790

(Core :: Graphics: ImageLib, defect, P3)

Description

[Dave Corrie]

Mozilla (M13;Win98) seems unable to display the png image from the URL above, 
giving the following error in the debug window:

nspng libpng error: Bad adaptive filter type

Netscape 4.7 fails to display this image also, but IE4 succeeds.

I have tried using a variety of programs to generate this image, including 
"Paint Shop Pro v5.03" and "gif2png v2.3.1". I have also run the image through 
"PNGcheck v1.99.2", which did not find any errors. The image does not contain 
any transparency and is interlaced.

Strange Observations:
* The image is visible (in both Mozilla and NS4.7) if you change every pixel to 
be the same colour.
* Mozilla (and NS4.7) are able to display slightly larger versions of this image 
(5 pixels wide or above).

Comment 1

[Richard Zach]

My linux build from yesterday seems to display it fine (it's blue, in any
case).  Can you try a newer build?

Comment 2

[Dave Corrie]

I've tried looking at this page with the Win32 nightly build from 
"2000-02-20-17-M14" (build ID == 2000022016) and the problem is still apparent. 
Just to clarify, you should see a thin blue rectangle between each of the arrow 
heads --> <--. The first one is not visible - it is replaced by it's ALT tag 
text: "a stripe".

Comment 3

[Richard Zach]

Both display blue on Linux build 2000.02.21.08.  The second has a few white
pixels in the upper left corner.

Can you display the images by themselves, ie, what does
http://www.verbal.nildram.co.uk/stripe.png
look like?

Do you still get the libpng error?

Comment 4

[Dave Corrie]

Using win32 build 2000022016, trying to view the first image directly 
(http://www.verbal.nildram.co.uk/stripe.png) does not show the graphic, but 
shows the location as text, in it's place. The second image 
(http://www.verbal.nildram.co.uk/stripe5.png) is still shown correctly.

As I cannot work out how to show the debug window when running mozilla.exe from 
this nightly build, I cannot confirm whether the libpng error occurs. When 
running viewer.exe from this same nightly build, the debug window does show the 
libpng error when trying to display stripe.png.

I downloaded the same Linux nightly build which Zach mentioned (2000.02.21.08) 
and agree that the page and it's images load correctly with this Linux build. I 
have witnessed this bug on two different machines (one running Win98 and the 
other NT4). Maybe this is a win32 only bug?

Comment 5

[Richard Zach]

Reassign to ImageLib

Comment 6

[Sean Richardson]

Confirmed with the 2000-02-22-08-M14 nightly binary on WinNT.
Viewing http://www.verbal.nildram.co.uk/stripe.png shows "Image 4by20 pixels"
in the Titlebar, but no image in the canvas area. 

Comment 7

[Dave Corrie]

I'm wondering is this is related to the infamous bug 3195?

A non-interlaced version of stripe.png is displayed correctly.
See: http://www.verbal.nildram.co.uk/stripe_ni.png

The only difference between this bug and 3195 is that 3195 documents incorrect 
rendering of interlaced png's, whereas this bug documents an interlaced png 
which is not shown at all.

Comment 8

[pnunn]

Notes:
error: stripe.png    4x20, interlaced,   1 bit color
ok:    stripe5.png   5x20, interlaced,   1 bit color
ok:    stripe_ni.png 4x20, non interlaced, 1 bit color

-p

Comment 9

[Greg Roelofs]

pngcheck is not designed to test the compressed image data in a PNG file. 
Nevertheless, pngcheck -vv gives:

File: moz-bug28616-stripe.png (94 bytes)
  chunk IHDR at offset 0x0000c, length 13
    4 x 20 image, 1-bit colormap, interlaced
  chunk PLTE at offset 0x00025, length 6: 2 palette entries
  chunk IDAT at offset 0x00037, length 19
    zlib:  deflated, 32K window, maximum compression
    zlib line filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
      0 0 0 0 0 0 0 128 0 0 0 0 0 0 0 0 0 192 0 0 0 0 0 0 0
      0 0 0 0 0 0 0 0 0 0 0 0 (37 out of 38)
  chunk IEND at offset 0x00056, length 0
No errors detected in moz-bug28616-stripe.png (-370.0% compression).

128 and 192 are bogus filter values, and if pngcheck's decoding can be trusted,
then Navigator, Mozilla et al. are correct to barf on it.

However, I'm not certain pngcheck's zlib decoding is trustworthy--we've had a
few other oddball images that pngcheck failed to flag as questionable, and two
libpng-based image viewers I just tried (both linked with a recent version of
libpng) displayed this image (stripes.png) without any errors or warnings.

I'll cc Glenn so he can test it with some of his home-grown tools, too.

Comment 10

[Glenn Randers-Pehrson]

I can't find anything wrong with the filter bytes (all are zero).  I did find
and fix a bug in pngcheck, though; it was failing to account for the fact
that the second pass is empty and therefore doesn't have any filter bytes.

Glenn

Comment 11

[tor]

This problem is fixed by the checkin imminent on bug 48790.


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

Comment 12

[John Unruh]

Verified dupe.