13627 - PNG transparency problems when transparent color == background color

Status: VERIFIED DUPLICATE of bug 19283

(Core :: Graphics: ImageLib, defect, P3)

Description

[Chris Hubick]

A PNG image with a palette color (gray) set to be transparent, when displayed
over a background the same color as is set transparent (gray), yeilds white
instead of the background color.

Comment 1

[Greg Roelofs]

Could you please provide a test case?  What version/date of Mozilla are you
using?

Comment 2

[Chris Hubick]

Attachment: Different background colors for the misc.png image

Comment 3

[Chris Hubick]

Attachment: A PNG image with a transparent gray background

Comment 4

[Chris Hubick]

Attachment: HTML Wich properly references the PNG attachment

Comment 5

[Chris Hubick]

This bug shows up with the nightly build D.L. on Sunday Sept 12.

Comment 6

[Greg Roelofs]

See http://pobox.com/~newt/test/moz/mozpng-13627-viewer.png for a screenshot
(sorry, attachments don't work for me).  Looks good to me...no white in sight.
I'm using the system libpng 1.0.2 and zlib 1.1.3, btw (i.e., not the ones in
Mozilla).  That's the only thing I can think that would explain the difference,
and I'm not sure how to debug it if I can't see it.

Oh yeah:  mine was built from a CVS pull on 19990911 10:00 PDT and was run as
root.  apprunner doesn't work at all, and viewer cores immediately when run as
non-root.

Greg

Comment 7

[Chris Hubick]

Attachment: Screenshot showing the problem

Comment 8

[Matthew Tuck [:CodeMachine]]

Guys, under Win98 in 8 bit colour mode I see it like Greg, in 32 bit colour mode
I see it as Chris, and in 16 bit colour mode I see the top image as per Greg and
the bottom as per Chris.

Comment 9

[Matthew Tuck [:CodeMachine]]

Greg, you appear to be running under Unix, it might be a Windows only problem?

Comment 10

[Greg Roelofs]

Yes, I'm running Linux, and on the basis of something dp told me last week, I
assumed both of you were, too.  (Sorry, I should have noticed the "Windows NT"
box above...)

This is good in the sense that we don't (necessarily) have still more Unix
cross-platform weirdness going on, but bad in the sense that I can't test
Windows builds myself.  My best guess at the moment is that this may have
something to do with the Windows-specific, DirectDraw alpha stuff Pamela was
doing; certainly there's nothing in the PNG code that cares about your display
depth.

Just for yuks, can one of you try a GIF version of the same thing and see what
happens?  I would have to look at the code to be sure, but I think the GIF code
does *not* expand the image data to RGB, which unfortunately means that the code
paths for PNG and GIF are different.  But I might be wrong, and if the same
problem happens with GIF, then it's definitely an imagelib or gfx bug.

Greg

Comment 11

[Matthew Tuck [:CodeMachine]]

I'd be happy to if you attach the test cases.

Comment 12

[Chris Hubick]

Attachment: The same PNG file as a GIF

Comment 13

[Chris Hubick]

Attachment: HTML showing the attached GIF images.

Comment 14

[Chris Hubick]

I have no problems with the image as a GIF file.  The GIF background appears
completely transparent, as opposed to the PNG version, which is only partially
transparent/translucent.  This machine is running under NT 4.00.1381, 24 bit
color depth.

Comment 15

[Matthew Tuck [:CodeMachine]]

Yes, the GIF test cases work OK on all colour depths.

Comment 16

[Matthew Tuck [:CodeMachine]]

If DirectDraw is on by default, can someone turn it off for a nightly build?  I
don't have compilation facilities on my Win box.

Comment 17

[Matthew Tuck [:CodeMachine]]

Are there any other image formats in the Moz code that use alpha?

Comment 18

[Greg Roelofs]

No, there are no other alpha formats in Mozilla--that's precisely why bug 3013
exists:  all existing transparency support assumed a palette image with
precisely one fully transparent color and everything else fully opaque.  Moz
does have support for full-image (or full-element) alpha transparency, but there
is still no consistent support for per-pixel, 8-bit alpha.

As for DirectDraw, I can't help with that, and it's 50% speculation at this
point anyway.  I need to do some digging to try to figure out what happens to
the image data after it leaves the PNG code.

Greg

Comment 19

[Ian Tommins ('thelem')]

They are the same bug, but 19283 is applied in more circumstances

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

Comment 20

[Eli Goldberg]

[pinged Greg to request his okay prior to marking this bug as verified.]

Comment 21

[Eli Goldberg]

Haven't heard back from Greg --- rubber-stamping as Verified.

---

Greg, please re-open if this resolution is erroneous.