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. ***
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 =)
*** This bug has been marked as a duplicate of 75558 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
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)
confirmed WinXP/2001061204 adding keywords, dependency reopening.. if somebody wants to dupe this against a different bug, feel free.
Status: RESOLVED → UNCONFIRMED
Keywords: mozilla0.9.2, nsbeta2, regression, testcase
OS: Windows 98 → All
Resolution: DUPLICATE → ---
*** Bug 86079 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: PC → All
This bug is present in the Windows version but not in the Linux version. What about other platforms?
*** Bug 87153 has been marked as a duplicate of this bug. ***
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.
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)
*** Bug 87326 has been marked as a duplicate of this bug. ***
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
Keywords: mozilla0.9.2, nsbeta2 → mozilla0.9.3, nsbeta1
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)
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.
make sure we test http://overosa.dhs.org/information.html from dup bug
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
OS: All → Windows 2000
Hardware: All → PC
Summary: PNG binary transparency is broken → PNG binary transparency is broken on win32
_basic: care to explain your changes??
This looks fishy... Maybe there's a problem with Bugzilla?
hmm... something went wrong. Skewer thanks for fixing
I heard about this on IRC last week. firstname.lastname@example.org. /be
could the logic in this fix be applied to bug 78114?
Assignee: pavlov → tor
Status: NEW → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
In today's build, I can't find anything wrong with the PNG transparency in Win98.
*** Bug 50974 has been marked as a duplicate of this bug. ***
Verified Fixed w2k build 2001082303
Status: RESOLVED → VERIFIED
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 → ---
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.
Marking WORKSFORME based on reporters comments..Dont worry it happens to the best of us.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 17 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.