Closed Bug 428045 Opened 12 years ago Closed 12 years ago

Incorrect transparency in .png image


(Core :: ImageLib, defect)

Not set





(Reporter: toobaz, Assigned: glennrp+bmo)




(Keywords: regression)


(4 files)

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:
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.
Component: General → ImageLib
Ever confirmed: true
Keywords: regression
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

$ 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-> = png_get_uint_16(buf) & bit_mask;

bit_mask is 255, so the result is a == 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
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.
Depends on: 418900
i also see a similar fact, but can't decide, if it has the same reason. Take a look at

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.

A patch to update the trunk to libpng-1.2.27beta01 is available in bug #418900, for testing of this transparency issue.
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
Attachment #315528 - Flags: review?(pavlov)
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: review?(pavlov) → review+
Attachment #315528 - Flags: superreview?(tor)
Attachment #315528 - Flags: superreview?(tor) → superreview+
Keywords: checkin-needed
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1a2
You need to log in before you can comment on or make changes to this bug.