Incorrect transparency in .png image

RESOLVED FIXED in mozilla1.9.1a2

Status

()

RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: toobaz, Assigned: glennrp+bmo)

Tracking

({regression})

Trunk
mozilla1.9.1a2
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

11 years ago
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.

Updated

11 years ago
Status: UNCONFIRMED → NEW
Component: General → ImageLib
Ever confirmed: true
Keywords: regression
OS: Linux → All
Product: Firefox → Core
QA Contact: general → imagelib
Hardware: PC → All
Version: unspecified → Trunk

Comment 2

11 years ago
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.

Comment 3

11 years ago
Created attachment 314757 [details]
Original Image from Wikipedia

Comment 4

11 years ago
Created attachment 314758 [details]
Same image after convert
(Assignee)

Comment 5

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

Updated

11 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 6

11 years ago
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.
(Reporter)

Comment 7

11 years ago
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?!)
(Assignee)

Comment 8

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

Comment 9

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

Comment 10

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

Updated

11 years ago
Depends on: 418900

Comment 11

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

Comment 12

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

Comment 13

11 years ago
A patch to update the trunk to libpng-1.2.27beta01 is available in bug #418900, for testing of this transparency issue.
(Assignee)

Comment 14

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

Comment 15

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

Updated

10 years ago
Attachment #315528 - Flags: review?(pavlov)
(Assignee)

Comment 16

10 years ago
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.

Updated

10 years ago
Attachment #315528 - Flags: review?(pavlov) → review+
(Assignee)

Updated

10 years ago
Attachment #315528 - Flags: superreview?(tor)

Updated

10 years ago
Attachment #315528 - Flags: superreview?(tor) → superreview+
(Assignee)

Updated

10 years ago
Keywords: checkin-needed
http://hg.mozilla.org/index.cgi/mozilla-central/rev/4c61288079d2
Status: ASSIGNED → RESOLVED
Last Resolved: 10 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.