367 bytes, image/png
321 bytes, image/png
35.36 KB, image/png
2.49 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008040514 Firefox/3.0b5 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008040514 Firefox/3.0b5 In Firefox 3.0b5, I see the linked image as a completely white (with grey borders) grid; more precisely, it is drawn as a grid with some squares white and some other transparent. Instead, the image should have some black, not transparent, squares. It's correctly shown in other programs, and in older Firefox versions too. This happens both as stand-alone image and encapsulated in an html page. Reproducible: Always Steps to Reproduce: 1. just take a look at the link 2. to see it inside a page, click here: http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life?uselang=en#Algorithms Actual Results: See a grid with 9 white (actually, 5 of them transparent) checkers. Expected Results: See a grid with 4 white and 5 black checkers.
Regression range here seems to be between 2007.11.06 and 2007.11.07. The only png related bugs I see are Bug 386585 and Bug 399630.
Status: UNCONFIRMED → NEW
Component: General → ImageLib
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
QA Contact: general → imagelib
Hardware: PC → All
Version: unspecified → Trunk
I see the same issue on Windows too. Toggling gfx.color_management.enabled has no effect. If I use ImageMagick on that .png (convert FPENTO.PNG FPENTO_after_convert.PNG) the resulting image is rendered correctly.
I'll take this bug. I don't have a bugfix yet, but here is an explanation for why it is happening: $ pngcheck -v FPENTO.PNG | grep tRNS chunk tRNS at offset 0x00025, length 6: red = 65280 green = 65280 blue = 65280 Observe that the tRNS chunk conveys the "transparent color" which is a 16-bit value 65280,65280,65280. This is almost white but does not match any pixels in the image. When reduced to 8-bit it is 255,255,255, which is exactly white and matches five of the squares in the image. Apparently we are reducing the image to 8-bit precision *before* checking for transparency. I'm not sure at this point whether that error is in libpng or in libpr0n. You may recall that this was one of the problems with implementing MNG -- we could not reduce the library size by immediately reducing 16-bit images to 8-bit precision, because the transparency would not work, exactly as it is not working here.
Assignee: nobody → glennrp
The explanation wasn't exactly correct. The tRNS value 65280 is 0xff00, and in libpng's png_handle_tRNS() we have png_ptr->trans_values.red = png_get_uint_16(buf) & bit_mask; bit_mask is 255, so the result is a trans_values.red == 0x00, so the transparent pixel value is 0,0,0 (black). So, as mentioned in the original comment, it is the black pixels that are incorrectly rendered transparent. This is actually in accordance with the PNG specification! The tRNS chunk in FPENTO.PNG is incorrect, and the other applications are rendering it incorrectly.
Ouch... instead than to Firefox, I'll have to file a bug against every other app! Seriously, I did suspected it, but I filed the bug because on previous Firefoxes it looked "good". If it's producer (ULead iPhoto-Plus 4)'s fault, we can probably close this. But please let me understand: it is an incorrect image AND it's incorrectly rendered by other apps? (in other words: PNG specs say how to render PNGs that do not follow PNG specs?!)
(In reply to comment #7) > But please let me understand: it is an incorrect image AND it's incorrectly > rendered by other apps? (in other words: PNG specs say how to render PNGs that > do not follow PNG specs?!) The incorrect image is indeed the producer's fault. About rendering, The PNG spec says "if the image bit depth is less than 16, the least significant bits are used and the others are 0.", and it says "An unexpected value in an ancillary chunk can be handled by ignoring the whole chunk as if it were an unknown chunk type." It looks as though libpng is wrong here. I think it should be discarding the invalid tRNS chunk rather than salvaging it by ignoring the nonzero high bits. We can revisit that decision in the libpng mailing list.
I've put a page for exploring this issue at <http://www.simplesystems.org/users/glennrp/tRNS/>. It's based on the original test image, with other images having the tRNS values replaced with legitimate values 0x00 and 0xff and invalid value 0xffff, and one with the tRNS chunk removed.
Libpng-1.2.27 will discard the invalid tRNS chunk, and the image display will be opaque, similar to previous behavior. Libpng-1.2.27beta01 was released this morning (April 12) and libpng-1.2.27 is scheduled for release on or about April 26.
Created attachment 315273 [details] comparing good/bad image details i also see a similar fact, but can't decide, if it has the same reason. Take a look at http://upload.wikimedia.org/wikipedia/commons/e/eb/Dakhla.png With ff3b (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041104 Minefield/3.0pre) there are white lacks within the image. I will add an attachment, that shows good/bad in the same picture.
Yes, it's the same reason. pngcheck -v Dakhla.png says chunk tRNS at offset 0x00025, length 6: red = 65280 green = 65280 blue = 65280 It is also a Ulead-generated file with the weird "0xff00" transparency values. I am afraid there may be a large legacy of such files. I suspect that Ulead intends for them to be opaque, by setting a transparency value that cannot appear in the image data. Checking in a libpng-1.2.27 patch from bug #418900 (patch does not exist yet!) will fix this problem. Glenn
A patch to update the trunk to libpng-1.2.27beta01 is available in bug #418900, for testing of this transparency issue.
Created attachment 315528 [details] [diff] [review] Check tRNS values for out-of-range samples This patch takes care of out-of-range tRNS samples within libpr0n and does not depend on any particular libpng version. It avoids setting up a useless opacity channel and checking each pixel for transparency when the tRNS chunk has an out-of-range sample.
Removing dependence on bug #418900. The libpng group has decided to simply issue a warning and not fix the erroneous tRNS chunk in libpng-1.2.27. While that will restore the browser display to the previous opaque condition as in Firefox 2.0, it is inefficient because we will generate a useless opacity channel and check each pixel for transparency, as in the past. It is better to simply discard the bad tRNS chunk.
No longer depends on: 418900
The "original image" at Wikipedia seems to have been updated. It no longer contains a tRNS chunk and therefore no longer exhibits the problem. But the test cases linked to comment #9 still do exhibit the problem with FF-3.0.
Attachment #315528 - Flags: superreview?(tor)
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1a2
You need to log in before you can comment on or make changes to this bug.