202376 - PNG transparency/alpha issues

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Eric Lawrence]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030416
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030416

The PNG given in the URL looks like there is something wrong with an alpha
channel (don't know much about these things, so maybe that's the wrong term). 
It looks like some parts are in negative, and the red channel is off (ie, looks
cyan).  Works with a slightly older build (4/11) and in other browsers.  See
also http://www.w3.org/ -- all the images there are goofy too.

Tried trashing profile, no dice.

Reproducible: Always

Steps to Reproduce:
1. Click on the link above, see the trippy kitten image.
2.
3.

Comment 1

[Olivier Cahagne]

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

Comment 2

[Olivier Cahagne]

what was the last build working correctly, can you track it closer to the last
one working ? It seems to be a MacOSX specific bug.
20030411: works.
20030416: doesn't work.
possible culprit: bug 155941.

Comment 3

[Eric Lawrence]

2003041511 works, 2003041610 breaks.  Seems very likely that the checkin for bug
155941 caused a regression.

Comment 4

[Greg K.]

Also causing problems in chrome. MailNews Splitters in the Pinstripe Theme are
now bright cyan.

Problem introduced between 2003-04-16-03-trunk and 2003-04-17-03-trunk.

Comment 5

[Eric Lawrence]

bleh, missed that one.

for me, 2003041603 works, 2003041610 breaks

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

Could one of you who sees this bug attach a screenshot of how these images look?

Comment 7

[Chris Nandor]

Attachment: what the weird PNG looks like to me

Comment 8

[tor]

Could you do a shot of the URL from this bug?  The other image has some
other attributes that might confuse matters.

Comment 9

[Glenn Randers-Pehrson]

The "camino-colors.png" file is 4-bit indexed-color and interlaced.
I've rewritten it as 8-bit interlaced, 4-bit noninterlaced, and
8-bit noninterlaced, along with the original 4-bit interlaced, all
cropped down to a smaller size, to help narrow down the cause.

See http://libpng.sf.net/bugzilla/bug202409.html

Glenn

Comment 10

[Greg K.]

Attachment: Screen capture of http://manual.gimp.org/images/cover_img.png as displayed by FizzillaMach/2003-04-15-11-trunk

Comment 11

[Greg K.]

Glenn, all four of those images still display wrong using
FizzillaMach/2003-04-15-11-trunk, and identically so.

Comment 12

[Glenn Randers-Pehrson]

The cover_img.png is a 24-bit opaque RGB image, so it seems
that just about all types of PNG image are bolluxed.

Glenn

Comment 13

[Greg K.]

Not all. My <http://greg.tcp.com/Graphics/Desert,%20larger.png> works, for instance.

Comment 14

[Eric Lawrence]

here's an indexed one that works too:

http://www.w3.org/Icons/WWW/graphics_48x48.png

(I think this the only png that works on the w3 page though.)

Comment 15

[Eric Lawrence]

sorry for the spam; strike the last line in my previous comment

Comment 16

[tor]

For the cat image, the channels appear to have gone through this mapping:

  red = inverse of original blue
  green = washed-out version of original red
  blue = washed-out version of original green

Comment 17

[Glenn Randers-Pehrson]

I added JPG and uncompressed GIF conversions of the image
to http://libpng.sf.net/bugzilla/bug202409.html

They look OK, right?   ...Glenn

Comment 18

[tor]

The png_get_channels() after the png_read_update_info() is returning 4 for a
RGB image if png_set_filler() has been called, which causes some problems.
Is this the expected behavior?

Comment 19

[Glenn Randers-Pehrson]

tor, try PNG_SET_FILLER_AFTER instead of PNG_SET_FILLER_BEFORE in
http://bugzilla.mozilla.org/attachment.cgi?id=120310&action=view
of bug #155941.  That may rectify the cat image but I don't see
how it would affect the indexed images.

Glenn

Comment 20

[Glenn Randers-Pehrson]

Yes, 4 channels is correct after you use png_set_filler to add an
alpha channel. The color type should also be updated to type 6, RGBA.

Glenn

Comment 21

[tor]

That just causes all RGB pngs to disappear, as they're being tagged as
4-channel images (comment 18) and the alpha channel is now zero (the filler).

Comment 22

[Glenn Randers-Pehrson]

Sorry, that's PNG_FILLER_AFTER not PNG_SET_FILLER_AFTER.
Note, I'm just grasping for straws, and don't have a Mac to
actually try this out.  Also, make sure the filler byte is
the alpha value for opaque, to avoid making the pixels transparent.

Glenn

Comment 23

[tor]

Checkin for bug 155941 backed out.

Comment 24

[Greg K.]

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

Comment 25

[Chris Casciano]

v, OS X 2003041808 build

http://www.cingular.com/

now looks ok as well

Comment 26

[paul beard]

I just grabbed the 20030418 build of Camino and this bug is still around. The
screenshot above is exactly what I see: a blue-green overlay on PNG format
graphics. 

Comment 27

[paul beard]

Attachment: This is a screen grab of some crummy looking PNG files in camino 20030418

This is a screen grab of  some crummy looking PNG files in camino 20030418. I
saved it a JPG to work around the PNG rendering/translation issue.

Comment 28

[Greg K.]

Try the 4/19 build or later, Paul.

Comment 29

[Derek Schrock]

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