PNG binary transparency is broken on win32

VERIFIED WORKSFORME

Status

()

Core
ImageLib
VERIFIED WORKSFORME
16 years ago
3 years ago

People

(Reporter: Jason Summers, Assigned: tor)

Tracking

({helpwanted, regression, testcase})

Trunk
mozilla1.0
x86
Windows 2000
helpwanted, regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 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

16 years ago
The old bug http://bugzilla.mozilla.org/show_bug.cgi?id=19283 is back.

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

Comment 3

16 years ago

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

Comment 4

16 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

16 years ago
confirmed WinXP/2001061204
adding keywords, dependency

reopening.. if somebody wants to dupe this against a different bug, feel free.
Blocks: 66965
Status: RESOLVED → UNCONFIRMED
Keywords: mozilla0.9.2, nsbeta2, regression, testcase
OS: Windows 98 → All
Resolution: DUPLICATE → ---

Comment 6

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

Updated

16 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: PC → All

Comment 7

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

Updated

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

Comment 8

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

Comment 9

16 years ago
Simplified testcase is attachment 39549 [details]. I'm seeing this in 2001062004 Win98.
(Reporter)

Comment 10

16 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

16 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

16 years ago
*** Bug 87326 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 13

16 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

16 years ago
mozilla0.9.2->mozilla0.9.3
nsbeta2->nsbeta1
Keywords: mozilla0.9.2, nsbeta2 → mozilla0.9.3, nsbeta1

Comment 15

16 years ago
Confirming this on w98, build 2001062420.
Some other URLs:
http://www.libpng.org/pub/png/pngs-img.html (Tux image at the top of the page)
http://office.altkom.com.pl/olo/domowa/betonowe/Berety.htm ("OLO" logo,
"Betonowe Berety" caption and Uncle Sam poster at the bottom of the page)

Comment 16

16 years ago
My problem has been made a duplicate of this bug, so I would want some
verification of the problem I'm having, see
http://bugzilla.mozilla.org/show_bug.cgi?id=87326

Thanks.

Comment 17

16 years ago
make sure we test http://overosa.dhs.org/information.html from dup bug

Comment 18

16 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.
Keywords: mozilla0.9.3 → mozilla0.9.4, nsCatFood
(Assignee)

Updated

16 years ago
OS: All → Windows 2000
Hardware: All → PC
Summary: PNG binary transparency is broken → PNG binary transparency is broken on win32
(Assignee)

Comment 19

16 years ago
Created attachment 45631 [details] [diff] [review]
probable fix (untested on win32)

Updated

16 years ago
Keywords: patch

Updated

16 years ago
No longer blocks: 66965
Keywords: mozilla0.9.4, nsbeta1, nsCatFood, regression, testcase → helpwanted
QA Contact: tpreston → lchiang
Summary: PNG binary transparency is broken on win32 → MIME support for content-transfer-encoding: binary

Comment 20

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

Comment 21

16 years ago
This looks fishy... Maybe there's a problem with Bugzilla?
Blocks: 66965
Keywords: mozilla0.9.4, nsbeta1, nsCatFood, regression, testcase
QA Contact: lchiang → tpreston
Summary: MIME support for content-transfer-encoding: binary → PNG binary transparency is broken on win32

Comment 22

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

Comment 23

16 years ago
sweet.  r=pavlov
I heard about this on IRC last week.  sr=brendan@mozilla.org.

/be

Comment 25

16 years ago
could the logic in this fix be applied to bug 78114?
(Assignee)

Comment 26

16 years ago
Checked in.
Assignee: pavlov → tor
(Assignee)

Comment 27

16 years ago
Closing bug...
Status: NEW → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 28

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

Comment 29

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

Comment 30

16 years ago
Verified Fixed w2k build 2001082303
Status: RESOLVED → VERIFIED

Comment 31

16 years ago
This persists!

See http://overosa.dhs.org/musik.html (on 0.9.3).

(streck.png, down at the bottom)

Reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 32

16 years ago
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

16 years ago
Marking WORKSFORME based on reporters comments..Dont worry it happens to the
best of us.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 34

16 years ago
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.