png image not displayed

VERIFIED DUPLICATE of bug 48790

Status

()

Core
ImageLib
P3
minor
VERIFIED DUPLICATE of bug 48790
18 years ago
18 years ago

People

(Reporter: Dave Corrie, Assigned: pnunn)

Tracking

({pp})

Trunk
Future
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

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

Comment 2

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

18 years ago
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?
Keywords: pp
(Reporter)

Comment 4

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

18 years ago
Reassign to ImageLib
Assignee: beard → pnunn
Component: Compositor → ImageLib
QA Contact: petersen → elig

Comment 6

18 years ago
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. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M16
(Reporter)

Comment 7

18 years ago
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.
Severity: normal → minor
(Assignee)

Comment 8

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

18 years ago
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.
(Assignee)

Updated

18 years ago
Target Milestone: M16 → M17

Updated

18 years ago
Target Milestone: M17 → M18
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
(Assignee)

Updated

18 years ago
Target Milestone: M18 → Future

Comment 11

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


*** This bug has been marked as a duplicate of 48790 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 12

18 years ago
Verified dupe.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.