PNG transparency/alpha issues

VERIFIED FIXED

Status

()

--
major
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: bugzilla.1.nrc, Assigned: jdunn)

Tracking

({regression})

Trunk
PowerPC
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

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

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

Comment 2

16 years ago
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.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
(Reporter)

Comment 3

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

Comment 4

16 years ago
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.
Summary: png transparency / alpha issues → PNG transparency/alpha issues

Updated

16 years ago
Flags: blocking1.4b?
(Reporter)

Comment 5

16 years ago
bleh, missed that one.

for me, 2003041603 works, 2003041610 breaks
Could one of you who sees this bug attach a screenshot of how these images look?

Comment 7

16 years ago
Created attachment 120874 [details]
what the weird PNG looks like to me

Comment 8

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

Comment 9

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

16 years ago
Created attachment 120892 [details]
Screen capture of http://manual.gimp.org/images/cover_img.png as displayed by FizzillaMach/2003-04-15-11-trunk

Comment 11

16 years ago
Glenn, all four of those images still display wrong using
FizzillaMach/2003-04-15-11-trunk, and identically so.
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

16 years ago
Not all. My <http://greg.tcp.com/Graphics/Desert,%20larger.png> works, for instance.
(Reporter)

Comment 14

16 years ago
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.)
(Reporter)

Comment 15

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

Comment 16

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

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

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

16 years ago
Checkin for bug 155941 backed out.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 24

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

Comment 25

16 years ago
v, OS X 2003041808 build

http://www.cingular.com/

now looks ok as well
Status: RESOLVED → VERIFIED

Comment 26

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

16 years ago
Created attachment 121047 [details]
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

16 years ago
Try the 4/19 build or later, Paul.

Comment 29

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

Updated

16 years ago
Flags: blocking1.4b?
You need to log in before you can comment on or make changes to this bug.