84980 - PNG binary transparency is broken on win32

Status: VERIFIED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[Jason Summers]

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.

Comment 1

[Matthias Versen [:Matti]]

*** Bug 84979 has been marked as a duplicate of this bug. ***

Comment 2

[Stefan Huszics]

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

[Keyser Sose]

*** This bug has been marked as a duplicate of 75558 ***

Comment 4

[James Paige]

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

[Aaron Kaluszka]

confirmed WinXP/2001061204
adding keywords, dependency

reopening.. if somebody wants to dupe this against a different bug, feel free.

Comment 6

[Aaron Kaluszka]

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

Comment 7

[Vesa Halttunen]

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

Comment 8

[Aaron Kaluszka]

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

Comment 9

[Skewer]

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

Comment 10

[Jason Summers]

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

[Mike Young]

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

[Aaron Kaluszka]

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

Comment 13

[Jason Summers]

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.

Comment 14

[Aaron Kaluszka]

mozilla0.9.2->mozilla0.9.3
nsbeta2->nsbeta1

Comment 15

[Aleksander Adamowski]

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

[[e-mail]]

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

[basic]

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

Comment 18

[Skewer]

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.

Comment 19

[tor]

Attachment: probable fix (untested on win32)

Comment 20

[Aaron Kaluszka]

_basic: care to explain your changes??

Comment 21

[Skewer]

This looks fishy... Maybe there's a problem with Bugzilla?

Comment 22

[basic]

hmm... something went wrong. Skewer thanks for fixing

Comment 23

[Stuart Parmenter]

sweet.  r=pavlov

Comment 24

[Brendan Eich [:brendan]]

I heard about this on IRC last week.  sr=[e-mail].

/be

Comment 25

[Aaron Kaluszka]

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

Comment 26

[tor]

Checked in.

Comment 27

[tor]

Closing bug...

Comment 28

[Skewer]

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

Comment 29

[Keyser Sose]

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

Comment 30

[Terri Preston]

Verified Fixed w2k build 2001082303

Comment 31

[[e-mail]]

This persists!

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

(streck.png, down at the bottom)

Reopening.

Comment 32

[[e-mail]]

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

[Keyser Sose]

Marking WORKSFORME based on reporters comments..Dont worry it happens to the
best of us.

Comment 34

[Skewer]

v