PNG binary transparency is broken on win32




18 years ago
5 years ago


(Reporter: jason1, Assigned: tor)


({helpwanted, regression, testcase})

Windows 2000

Firefox Tracking Flags

(Not tracked)




(1 attachment)



18 years ago
Test images (T8) and (T9) at the listed URL are rendered incorrectly. The 
right half of the images should be completely transparent, but it is displayed 
as a reddish version of the background image. The problem is completely 
reproducible; observed in build 2001060908.

These are 24-bit RGB images that include a tRNS chunk to indicate that one 
specific RGB color should be transparent.

The exact behavior is somewhat complicated -- the displayed red value is always 
either 63, 127, 191, or 255, and the green and blue values are either correct or 
128 too high. The behavior for 48-bit RGB images is slightly different in the 
red component -- it will be either correct or 64 too high.

This is a regression. It used to work perfectly.
*** Bug 84979 has been marked as a duplicate of this bug. ***

Comment 2

18 years ago
The old bug is back.

Guessing this is not a dupe since the other one is closed =)

Comment 3

18 years ago

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

Comment 4

18 years ago
This bug was incorrectly marked DUP of bug 75558 which covers problems with the
background behind scaled alpha-transparent PNGs. This bug is about PNG binary
transparency problems. Please reopen.

(BTW, Jason, _excellent_ page of test-cases you have there)

Comment 5

18 years ago
confirmed WinXP/2001061204
adding keywords, dependency

reopening.. if somebody wants to dupe this against a different bug, feel free.
Blocks: 66965
OS: Windows 98 → All
Resolution: DUPLICATE → ---

Comment 6

18 years ago
*** Bug 86079 has been marked as a duplicate of this bug. ***


18 years ago
Ever confirmed: true
Hardware: PC → All

Comment 7

18 years ago
This bug is present in the Windows version but not in the Linux version. What
about other platforms?


18 years ago
Target Milestone: --- → mozilla1.0

Comment 8

18 years ago
*** Bug 87153 has been marked as a duplicate of this bug. ***

Comment 9

18 years ago
Simplified testcase is attachment 39549 [details]. I'm seeing this in 2001062004 Win98.

Comment 10

18 years ago
But 87153 is not exactly a duplicate of this bug as reported, because the image 
in the testcase is a palette image, not an RGB image. It's now clear that there 
are also problems with 100% transparent pixels in palette images (and probably 
in all image types). Sometimes it works correctly and sometimes it doesn't. I 
haven't pinned down the exact circumstances under which problems occur -- there 
are a lot of things it could depend on.

Comment 11

18 years ago
This bug has parallels with bug 78114 which discusses the same binary
transparancy background problems but with Animated GIFs. I'd be inclined to
believe that the logic to fix the two bugs is the same. It seems that both bugs
involve adding the transparent color to the color behind the image. (so 999999
and 00FF00 become 99FF99) and both are only affected by higher RGB values so the
background can only be lighter (so 999999 and 88FF88 become 99FF99 as well)

Comment 12

18 years ago
*** Bug 87326 has been marked as a duplicate of this bug. ***

Comment 13

18 years ago
Some details... If a palette PNG image has any partially transparent pixels (1 
<= opacity <= 254), then everything works. I assume a different code path is 
being used in that case. That's why my test page didn't catch this problem (I've 
added a testcase for it to the bottom of the page).

If the image has no partially transparent pixels, then any completely 
transparent pixels will usually be displayed wrong. The color that is displayed 
is the bitwise logical OR of the pixel color and the background color. So it 
will only be right if (background-color | pixel-color) == background-color.
Summary: PNG RGB binary transparency is broken → PNG binary transparency is broken

Comment 14

18 years ago
Confirming this on w98, build 2001062420.
Some other URLs: (Tux image at the top of the page) ("OLO" logo,
"Betonowe Berety" caption and Uncle Sam poster at the bottom of the page)
My problem has been made a duplicate of this bug, so I would want some
verification of the problem I'm having, see


Comment 17

18 years ago
make sure we test from dup bug

Comment 18

18 years ago
Updating keyword to mozilla0.9.4. I strongly suggest that this bug be
reprioritized to catch this release, since it's a major imglib bug.


18 years ago
OS: All → Windows 2000
Hardware: All → PC
Summary: PNG binary transparency is broken → PNG binary transparency is broken on win32

Comment 19

18 years ago


18 years ago
Keywords: patch


18 years ago
No longer blocks: 66965
QA Contact: tpreston → lchiang
Summary: PNG binary transparency is broken on win32 → MIME support for content-transfer-encoding: binary

Comment 20

18 years ago
_basic: care to explain your changes??

Comment 21

18 years ago
This looks fishy... Maybe there's a problem with Bugzilla?
Blocks: 66965
QA Contact: lchiang → tpreston
Summary: MIME support for content-transfer-encoding: binary → PNG binary transparency is broken on win32

Comment 22

18 years ago
hmm... something went wrong. Skewer thanks for fixing

Comment 23

18 years ago
sweet.  r=pavlov
I heard about this on IRC last week.


Comment 25

18 years ago
could the logic in this fix be applied to bug 78114?

Comment 26

18 years ago
Checked in.
Assignee: pavlov → tor

Comment 27

18 years ago
Closing bug...
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 28

18 years ago
In today's build, I can't find anything wrong with the PNG transparency in Win98.

Comment 29

18 years ago
*** Bug 50974 has been marked as a duplicate of this bug. ***

Comment 30

18 years ago
Verified Fixed w2k build 2001082303
This persists!

See (on 0.9.3).

(streck.png, down at the bottom)

Resolution: FIXED → ---
TURBO fooled me. Had 0.9.3 running in the background. Oh, that is confusing.

I am confusing myself now.

Closing, a nightly shows it correctly.

Ooops I can't close.

My apologies. I'll refrain from bug-reporting for a while, I think.

Comment 33

18 years ago
Marking WORKSFORME based on reporters comments..Dont worry it happens to the
best of us.
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 34

18 years ago
You need to log in before you can comment on or make changes to this bug.