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).
My linux build from yesterday seems to display it fine (it's blue, in any case). Can you try a newer build?
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".
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?
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?
Reassign to ImageLib
Assignee: beard → pnunn
Component: Compositor → ImageLib
QA Contact: petersen → elig
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
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
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
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.
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
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.