Closed
Bug 3013
Opened 26 years ago
Closed 24 years ago
[skins] PNG [alpha] transparency not supported
Categories
(Core Graveyard :: GFX, defect, P2)
Core Graveyard
GFX
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: dbaron, Assigned: pnunn)
References
()
Details
(Whiteboard: alpha still not supported correctly . (mac&win support only: 05-??-00))
Attachments
(4 files)
From the above, it seems PNG transparency is not supported. It would be nice
to have real alpha-channel support too, which I believe PNG offers.
Reporter | ||
Comment 1•26 years ago
|
||
By real alpha-channel support, I mean 8-bit transparency (I think those mean
the same thing...I'm not all that sure of this stuff). Someone commented on
www-style today that gamma-correction is also essential.
See the thread beginning at:
http://lists.w3.org/Archives/Public/www-style/1999Feb/0004.html
I concur with David- that was the purpose of creating PNG - making a new graphic
format solely for the Web. Being able to make use of PNGs many features,
requires a full implementation in the browsers.Here's the recommendation:
http://www.w3.org/TR/REC-png
see test pages for gamma and for transparency in PNG
http://www.w3.org/Graphics/PNG/Inline-img.html
http://www.w3.org/Graphics/PNG/all_seven.html
http://www.w3.org/Graphics/PNG/inline-alpha.html
http://www.w3.org/Graphics/PNG/inline-alpha-table
http://www.w3.org/Graphics/PNG/inline-alpha-table32.html
Updated•26 years ago
|
QA Contact: 1698
Reporter | ||
Comment 4•26 years ago
|
||
Yet another test page:
http://www.cdrom.com/pub/png/pngs.html
(I also filed bug 3195 on the progressive display of the interlaced PNG in this
page.)
kevin, you should coordinate wil pnunn to make sure that the interfaces to the
image lib can deliver a full alpha channel (i think that is the case) and then
augment the image rendering code/blender as necessary.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M7
Updated•25 years ago
|
Assignee: kmcclusk → dcone
Status: ASSIGNED → NEW
Updated•25 years ago
|
Status: NEW → ASSIGNED
Updated•25 years ago
|
Target Milestone: M7 → M8
Updated•25 years ago
|
Component: Compositor → Viewer App
Updated•25 years ago
|
Component: Viewer App → Compositor
Updated•25 years ago
|
Target Milestone: M8 → M10
Updated•25 years ago
|
OS: Windows 95 → All
Summary: PNG transparency not supported → PNG [alpha] transparency not supported
Comment 6•25 years ago
|
||
The URL above is misleading since the PNG smiley doesn't *have* transparency;
thus it will always look "wrong" compared to the GIF version. I've just sent
e-mail to Glenn suggesting he fix that; in the meantime, note that Mozilla has
supported binary PNG transparency since the 19980331 release.
As for 8-bit alpha transparency, Pamela has been recently updating imagelib to
handle that (possibly in conjunction with michaelp), and as soon as that's
working/checked in and we can come up with a reasonable RGB+A interface to
il_emit_row(), alpha PNGs will be looking good.
For testing with minimal interference from other effects (OBJECT bugs, etc.), I
recommend this page: http://www.cdrom.com/pub/png/pngs-img.html
Each of the four images at the bottom can be clicked for a larger, single-image
test page.
Comment 7•25 years ago
|
||
The PNG icon at the URL above is now fixed, and Mozilla displays it identically
to the GIF.
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Comment 8•25 years ago
|
||
The PNG's have transparency..
Reporter | ||
Comment 9•25 years ago
|
||
The 8-bit transparency still isn't working (see the toucans in the second test
page). Is there another bug on that or should this one be reopened?
Comment 10•25 years ago
|
||
The PNG do support transparency, there is another bug that not all depths show
the tranparency, but this bug should be ok because the tranparecy info is
getting into Gecko. The 8 Bit should show up as soon as the other bug is fixed.
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Whiteboard: alpha still not supported correctly
Comment 11•25 years ago
|
||
David is correct: this is the only PNG-alpha bug in Bugzilla, and it is not yet
resolved. Basic transparency has been there since the 31 March 1998 release.
Note that this has nothing whatsoever to do with the bit depth of the display;
it is about about displaying 8-bit (or 16-bit) alpha ("partial transparency")
correctly, on a per-pixel basis. Reopening...
Greg
Updated•25 years ago
|
Assignee: dcone → pnunn
Status: REOPENED → NEW
Comment 12•25 years ago
|
||
Pam, can you tell me if there is a diffent code path to reading in an 8 bit PNG,
and if the alpha or transparency would change. Does a different kind of image
(nsIImage) get created when the depths of the monitors change.
I do know that we do not support alpha very well at all the depths. Alpha has
been present since 98, but we have not completed all the code paths. Just
because 8 bit GIFS work does not mean that 8 Bit PNG's will work the same since
there are many more colors that can go transparent. I know that we do not
support multi apha at 8 bits properly today.
Assignee | ||
Comment 13•25 years ago
|
||
dcone:
whoa.
We need to clarify some terms here.
Alpha channel is supported. but the 8 bit value
of transparency for each pixel is THRESHOLDED to
be 100% transparent or 100% opaque. Any pixel can
have this channel applied to it.
In gifs, only one color is mapped as transparent.
In the current code base for windows, there is a
switch in the pngcom code that will turn on alpha for
an 8bit mask instead of a 1 bit mask. The alpha displays
for 256 levels of transparency....over any background.
IE, I believe doesn't even try to address the issue of
alpha transparency over a frame or window background.
The code to implement 8 bit masks is not yet checked in
on linux and Mac, because the Mac is giving me fits when
I create an 8 bit mask structure. (Any mac help would be appreciated.)
The code I have for linux, builds the 8 bit mask, but doesn't have
a nice mask functions like those available on mac and windows.
There are better solutions for this, but other projects have priority
over this one.
If you are on a wintel machine, try out the switch:
Change the ifdefs in mozilla/modules/libimg/pngcom/ipng.cpp, line 128.
-pn
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: WORKSFORME → INVALID
Comment 14•25 years ago
|
||
Could whoever marked this invalid please explain why?
Thresholded alpha is a bug; it's not fixed yet; and 3013 is the only Bugzilla
bug that addresses the problem. Ergo, nothing is resolved. What am I missing
here?
Assignee | ||
Comment 15•25 years ago
|
||
Thresholded alpha is NOT A BUG. It may be an
implementation you dont like, but it is not a
bug.
-p
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Comment 16•25 years ago
|
||
"It's not a bug, it's a feature!"
Thus, re-opening as a feature request, for after Pam has finished more critical
functionality.
Updated•25 years ago
|
Severity: normal → enhancement
Resolution: INVALID → ---
Summary: PNG [alpha] transparency not supported → [RFE] PNG [alpha] transparency not supported
Target Milestone: M10 → M20
Comment 17•25 years ago
|
||
[Re-opened as RFE, M20.]
Comment 18•25 years ago
|
||
Ask any user on the planet; I guarantee you that 99% of those who know what
alpha is will agree that thresholded alpha IS a bug. If users wanted their
images to look like crap, they'd have made them that way in the first place.
Call it whatever you want, but I intend to make sure it's working by M11.
Assignee | ||
Comment 19•25 years ago
|
||
Its a pleasure to work with you, Greg.
-p
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 20•25 years ago
|
||
Apologies to all for the unnecessarily strong language. (Private message sent
to Pam.)
Greg
Assignee | ||
Comment 21•25 years ago
|
||
*** Bug 2587 has been marked as a duplicate of this bug. ***
Comment 22•25 years ago
|
||
I sure hope the 8bit alpha is going to be unthresholded before beta.
It is absolutely important for writing nice XUL which considers
user preferences for UI-colors. (so button-images can be anti-aliased
and can have a drop-shadow)
Comment 23•25 years ago
|
||
*** Bug 14926 has been marked as a duplicate of this bug. ***
Comment 24•25 years ago
|
||
Updated•25 years ago
|
Comment 25•25 years ago
|
||
If you're wondering why this bug suddenly got such an insane number of votes,
it's because it just got Slashdotted ...
http://slashdot.org/article.pl?sid=99/10/31/1337238
Updated•25 years ago
|
OS: All → Linux
Comment 26•25 years ago
|
||
True alpha blending could be done post-layout if bitmapped information on the
current display is stored in layers with alpha support (similar to imlib).
Comment 27•25 years ago
|
||
...not that that should invalidate all these votes ... it's just an indicator
of
how badly this bug needs to be fixed, so that all of us can move to a better,
smaller, faster, etc, etc, web.
Updated•25 years ago
|
OS: Linux → All
Hardware: PC → All
Comment 28•25 years ago
|
||
Changing OS from Linux back to All since this is still a cross platform issue.
However, I believe there is a build switch to turn on 8 bit alpha in Windows.
I also heard that some work was done to get it to work on Mac. What is the
status of 8 bit alpha across the 3 main platforms? Is Linux the only platform
lagging now? Would it be possible to get this turned on by default for the
Windowss builds at least?
Comment 29•25 years ago
|
||
ssym: Of course the votes are valid. I'd like to see this bug fixed too, but all
my Browser votes are busy. :-)
Mozilla is making a great show of implementing the W3C standards of HTML, CSS,
and XML -- and more importantly, implementing them *correctly*. It's worth
reiterating that PNG is also a W3C standard. Whether the lack of 8-bit alpha
transparency is an `incorrect' or an `incomplete' implementation of PNG is a
semantic issue, but I think most people would call it `incorrect'.
Also, the PNG format is in the public domain whereas the GIF format (technically)
is not. The relevant article: http://slashdot.org/article.pl?sid=99/10/31/1337238
Comment 30•25 years ago
|
||
Here's the deal, folks: plain xlib and (last I checked) gtk provide no support
for alpha compositing, which means the current platform-dependent approach Pam
has implemented (under http://lxr.mozilla.org/seamonkey/source/gfx/src/) simply
will not work for Linux or other X platforms, nor for OS/2 and possibly BeOS.
The code that knows about Mozilla's layers of stuff (which, keep in mind, can be
moving around a la Demo 10) all lives up in the vicinity of
http://lxr.mozilla.org/seamonkey/source/view/src/nsView.cpp and similar regions;
*that's* where it has to be handled on X (calling back to the software
compositors in gfx/src, which, if they don't exist yet, are trivial to write).
The problem is that I have absolutely no clue what "kids" are (nsView.cpp), how
they relate to image containers
(http://lxr.mozilla.org/seamonkey/source/modules/libimg/), and how the code gets
from the high-level kids view down to the low-level image-container view (i.e.,
a call stack). This is something that other folks could help with (hint hint),
even folks who never download a shred of CVS'd code or compile anything--LXR
provides a real-time view of the code base. I simply don't have time to try to
trace through the code manually, and ongoing rewrites of the networking code and
other things broke my Linux/libc5 builds two or three months ago.
Further information (including comments on bug 3195, which is also directly
related to masks) is at http://www.cdrom.com/pub/png/pngmoz.html .
Greg
Comment 31•25 years ago
|
||
Folks, if you want this fixed --- please, just connect with newt, and help him
fix it. Lots of "we want this fixed" bug comments won't magically make the code
appear any faster!
Reporter | ||
Comment 32•25 years ago
|
||
Reporter | ||
Comment 33•25 years ago
|
||
Comment 34•25 years ago
|
||
are you volunteering to write some compositing code for linux us to use on
linux?
Comment 35•25 years ago
|
||
FWIW, I implemented code in nsImageMac.cpp to do 8-bit alpha blending on Mac.
This is not checked in yet.
Comment 36•25 years ago
|
||
Looking through the png application lists, the only web browser that supports
alpha 'properly' is arena. So I grabbed it and tried it. It's AMAZINGLY slow.
I think we have a tradeoff between a fast browser and a fully PNG compliant
browser.
I have withdrawn my votes from this bug, as there are many more important ones.
Comment 37•25 years ago
|
||
Pavlov: it's already there, just not totally enabled. See Do24BlendWithMask()
and Do8BlendWithMask() in
http://lxr.mozilla.org/seamonkey/source/gfx/src/nsBlender.cpp . That part is
easy (and so is adding Do32BlendWithMask() and Do16BlendWithMask, if there's any
need for them, which I assume there is). Getting aMImage (or mDestBytes in
Blend(), a.k.a. the background pixels) is the hard part--that's where the
high-level view/src code comes in, because apparently there's no callback for a
given piece of low-level code to say "give me the current background at this
location, with these dimensions, so that I can composite against it."
And it looks like there needs to be yet another variant of Blend() since
currently it isn't even given a pointer to the alpha mask, but that should be
pretty easy to write, too.
Yarn: Arena is slow at everything; alpha-blending is certainly not the (only)
reason. You can expect Demo10-like speed for Mozilla's alpha blending. Only a
few more cycles per pixel are required, and those temp conditionals can be
removed. In fact, a little MMX magic would do wonders for the blending code.
I'm kind of surprised that nobody's done it yet, since I recall someone else
suggesting it almost a year ago.
Btw, even WebTV (a very low-end platform) does 32-bit RGBA correctly--and unlike
Arena, it uses the specified web-page background. But for X, Arena is/was the
best approximation (RIP).
Greg
Comment 38•25 years ago
|
||
Another testcase: http://www.w3.org/Graphics/PNG/inline-alpha-table to test
compositing against different backgrounds
Comment 39•25 years ago
|
||
I see someone was saying that Arena does alpha PNG but is slow. It is slow, but
that is because dave Raggett wrot eht code in 2 weeks (its the first web browser
to support tables) as a demo, and bits got added and added - the code is ****,
basically, although by the time we stopped work on it the PNg support was pretty
good.
SVG viewers do support alpha compositing with PNG onto arbitrary backgrounds
(and hey, they have to support rotation, skewing, and bicubic resampling of the
PNG as well) so it isn't necessarily hard or slow.
Comment 40•25 years ago
|
||
*** Bug 19283 has been marked as a duplicate of this bug. ***
Comment 41•25 years ago
|
||
*** Bug 19539 has been marked as a duplicate of this bug. ***
Comment 42•25 years ago
|
||
*** Bug 19538 has been marked as a duplicate of this bug. ***
Comment 43•25 years ago
|
||
*** Bug 19538 has been marked as a duplicate of this bug. ***
Comment 44•25 years ago
|
||
Here's a possible cross-platform solution which would work with
the assumption that images only appear over a background region
(body or table cell). That is, they will not render over other
html elements. When the layout engine creates an image, it can
tag the image with a pointer to the underlying surface (solid
color or another image) and the relative offset of the origins.
At render time the image can be alpha composited to the
underlying surface and cached for later use.
Images will need "dirty bits" to note when the image data has
changed or the images have moved. At render time the image will
recomposite if either its own or parents dirty bits are set.
Before I attempt to write the code to implement this, could
someone tell me whether my original assumption is correct?
Reporter | ||
Comment 45•25 years ago
|
||
The assumption that the image will always be over a constant background is
definitely not correct. It could be over:
* a background image
* text or changes in background (by positioning or negative margins)
* borders between backgrounds (if its partly overflowing a container)
and there are also a number of cases where it's not trivial to determine what
the correct background color would be. In particular, when content overflows
its container, the relevant background wouldn't be (completely) that of the
container.
I'm not sure whether it would be better to have a solution like this or
threshholded transparency (as it is now).
Comment 46•25 years ago
|
||
Per e-mail from Greg, he has relinquished PNG component ownership; thus,
reassigning assigned bugs to ImageLib owner.
Assignee: newt → pnunn
Status: ASSIGNED → NEW
Comment 47•25 years ago
|
||
*** Bug 26894 has been marked as a duplicate of this bug. ***
Comment 48•25 years ago
|
||
Sorry to add a comment that doesn't actually contribute to the resolution of
this bug, but I would like to point out that a large number of web developers
(including, for example, a significant number of the participants in this
weekend's mozillaZine discussion on "most wanted feature") consider this bug to
be of very high importance.
There are so many obvious examples of where this would be incredibly useful,
from adding shadow effects against arbitrary backgrounds to producing
anti-aliased images that don't have to be created separately for every
background they may be rendered against. Even mozilla's *chrome* would benefit
from it - the use of alternating lines to give some sort of illusion of
semitransparency is a hack that just goes to show how much this is needed. Do
you want web page authors to have to require pixel-perfect alignment to get an
effect that is used in the browser's toolbar?
I'll draw these comments to a close now as I know bugzilla is not a place for
advocacy. But please bear these considerations in mind; scheduling this for M20
is not acceptable to the web developers who have been crying out for standards
support for so long -- and holding out Mozilla as the best hope for getting
them.
Comment 49•25 years ago
|
||
With all of the advantages PNG file formats bring to designers and users,
it is quite strange that it still doesn't work properly in todays browsers.
If antone was to win a browser war....this would be the ideal weapon, since
as you know, the designers deside of the winner when building the Sites to
be more compliant with one browser or the other. I have been one of the first
designers and web programmer anywhere, and i've been using PNG file formats
since its very first peek, and must tell you that it is as important as Flash
and Java can be. The fact that the user can download a plug-in that works
perfectly well, prooves that it isn't such a stretch for either browsers to
implement it. In conclusion, it's more then time someone did something about
this.
Styles
Comment 50•25 years ago
|
||
styles@ergonet.com: So, are you volunteering to write the code...?
Comment 51•25 years ago
|
||
So, any GIMP programmers out there, we need you! (I guess with the problems of
turing GPL into NPL we couldn't just copy the code straight out :)
Comment 52•25 years ago
|
||
elig@netscape.com ---> If they can afford it, and thats the only way it'll ever
be done, then i'll get the people needed and have it done. But i dought thats
the reason, its most likely because it is either too time consuming, too
expensive, or not in theyre priorities.
Comment 53•25 years ago
|
||
Stupid idea here....
Why not just implement PNGLive 2.0b5 for the time being.
let it be plug-in that comes included with Netscape for Win9x/NT/2000.
this might be a good start. if all it meens is that we have to
put it in <EMBED> when creating a site, it doesn't meen much more work for
designers and might be worth it.
Also, anyone out there have the source code for this plug-in ? and the version
1.0 ? Maybe theres still something to do with it, it was after all....the best
one yet.
Comment 54•25 years ago
|
||
Elig, I think what he's saying is that it's foolhardy for Netscape to release a
browser without PNG alpha at the time when they desperately need to regain
market share. If someone outside of Netscape doesn't do it, then Netscape
should do it, if only for Netscape's sake. It's up there with CSS support as a
necessity.
Comment 55•25 years ago
|
||
matty@box.net.au: So, are _you_ volunteering to write the code...? ;)
Comment 56•25 years ago
|
||
Is there some documentation available as to where one should poke?
Comment 57•25 years ago
|
||
Yes, see Greg's page <http://www.cdrom.com/pub/png/pngmoz.html>.
Comment 58•25 years ago
|
||
Some information is here: http://www.cdrom.com/pub/png/pngmoz.html
Unfortunately, figuring out how to translate from the highest-level structures
(which is where alpha is/should be handled, since that's the only place that can
do software alpha on X or bad Windoze boxes) down to the gory details in
ImageLib and gfx/* (which is where PNG and platform-dependent graphics code
lives) is non-trivial. What's needed is someone who understands the overall
structure and flow of control in Mozilla, or else someone who can take the time
to trace the flow across possibly megabytes of source code. It could probably
be done in a weekend, maybe even just a few hours, but I ran out of time before
I ever had a chance to try.
Btw, my knowledge of the code is a few months old, so it's vaguely possible that
things have gotten significantly better since I last looked.
Comment 59•25 years ago
|
||
My interpretation of this problem is somewhat different than Greg's.
This may be due a fundamental misunderstanding of mozilla on my part,
but maybe these comments will be useful to someone.
Greg argues that the alpha transparency needs to be done at a high level,
because not all the underlying graphics APIs are capable of doing compositing
themselves (X being the usual example). My thinking is that the gfx layer is
a more natural place for the alpha-blending responsibility, in that it should
take images with an 8-bit alpha mask and be capable of rendering them in a
composited fashion. This would make for simpler code and is really the only
way of dealing with the case of an image overlapping text.
From pnunn's comments on 1999-09-01 there is already some #ifdefed code that
will pass 8-bit alpha masks along with images. Looking at the code it
references I don't see the ifdefs anymore, but hopefully this code is still
around. Maybe pnunn can comment?
It looks like the win32 and mac gfx layers can deal with an 8-bit alpha mask
already by mapping it to alpha-capable API calls on those platforms. This
leaves gtk as the only tier-1 platform currently without this capability.
gdk doesn't have any function for reading back an rgb image, but it does
have gdk_image_get that returns the data in a visual specific format.
You'll need to map this through the associated colormap and visual
to recover an rgb image which can be software composited with the new image,
then written back to the window.
Comment 60•25 years ago
|
||
To be more specific: you can't composite anything until you have something to
composite against. The gfx code doesn't know anything about the various layers
in the page (some of which may be moving or animated, a la Demo 10); only the
higher-level code knows that. That's the part that really needs the work. Once
you have some way to send the alpha channel all the way back up (instead of
flattening it right away in gfx), you can then send it back down WITH background
info and do the compositing in gfx as you suggest. But the gfx code itself
needs very little work--the compositing code either already exists or else is an
obvious and simple extension of other code that exists. The hard work is making
the connection to the high-level code. There's no such thing as an image
container in nsView.cpp; just "kids."
Note that the Mac and Windows code can get away with the lazy approach since the
underlying graphics engine of the OS supports alpha blending--in effect, you can
use it to "remember" the underlying image layers at each frame. That's
impossible in X (which is the primary display system for all Unix and OpenVMS
systems), OS/2, and probably quite a few other operating systems.
If you still think I'm missing something, don't be shy about telling me/us!
I've been wrong before...
Greg
Comment 61•25 years ago
|
||
Comment 62•25 years ago
|
||
It's my impression that the viewmanager[2] sorts the objects in a back->front
order, so the gfx layer just has to composite atop what has already been drawn
into the framebuffer.
Reporter | ||
Comment 63•25 years ago
|
||
I was just trying to understand how the view manager works, and I noticed
there's some disabled code in ViewManager2 dealing with translucent views:
http://lxr.mozilla.org/seamonkey/search?string=SUPPORT_TRANSLUCENT_VIEWS
Anybody know what the status of this code is? It seems like it's written to do
part of what's needed here. (See in particular the code in
RenderDisplayListElement.)
Reporter | ||
Comment 64•25 years ago
|
||
Actually, it looks like that code might be for dealing with views of fixed
opacity (that's not 0 or 1). But it could be a good place to start, although
one would need to get the mask in the right place...
Assignee | ||
Comment 65•25 years ago
|
||
ok.
Here's the deal. I already had a alpha version working
on windows and simon had it working on mac.
Newt didn't like this solution and later made changes that
broke these versions that use the platform specific calls
for alpha. These changes were not meant as a permanent solution
but as a stop gap until the gfx code could be modified to deal
with true alpha blending rather than layer transparency as it does
now.
I can get these changes back in if I can get in the witness protection
program from other bugs,gripes&other time stealers.
Adding comments as to how much alpha transparency is desparately needed
doesn't help the cause. It just eats up time I could spend on code.
I want this in as much as anyone.
Alphatransparency is easy if you know exactly what the background is going
to be. We have dynamic layers. Any alphatransparency has to work with
the compositor because of dynamic layers. (and I don't mean layers tags here.)
-P
Comment 66•25 years ago
|
||
In responce to that.
Any half decent Web Designer should have the capacity of
adapting to certain bugs, I dont think we're asking
for something perfect, just for something that works
well enough for us to use. I call it cheating the programmers.
If something (inserting PNG Alpha images) cannot be done
because of the way other elements react or interact with it,
then the designer should adapt the element to avoid it without
killing the effect. So if we can use transparent PNG files in a
HTML document but we are restricted, It beats not being able
to use them at all. Of course, hoping that the restriction will
at some point be resolved.
Comment 67•25 years ago
|
||
Please do support transparency / real alpha channel for PNG images.
Thanks a lot
Peter Weustink
Comment 68•25 years ago
|
||
Wow. 100 votes.
Assignee | ||
Comment 69•25 years ago
|
||
wow. A bunch of verbose noise in the bug
report that doesn't help fix the problem
and in fact eats up cycles that could be
devoted to the problem.
-P
Comment 70•25 years ago
|
||
I believe whwat we need to do here is have nsImageFrame create views for images
that have more than 1 bit of alpha data in them. The view will need to be set
with a flag that tells the view manager that it has translucency (but a
different flag from the current one that specifies that the blender should blend
every pixel with a single value of opacity). The blender then needs to be able
to blend image data in to a drawing surface on a per-pixel basis. There are a
few things I am concerned about, such as blending bwtween two drawing surfaces,
because on X when we draw in our nsIImage implimentation to a drawing surface,
we will loose the alpha data that we would need to blend. I'm not entirely sure
how we should go about fixing this, but I'm hoping that someone can help put in
some ideas. adding kmcclusk, beard and dcone for view manager and blender
ideas.
Comment 71•25 years ago
|
||
*** Bug 19283 has been marked as a duplicate of this bug. ***
Comment 72•25 years ago
|
||
OK, I am adding the skins and beta 2 keywords here to raise visibility asap.
Professional level skins/themes/appearances have been made priority number 1 for
beta 2. In order to have decent professional level skins we need alpha channels
in PNG in order to:
- have controls with bitmap shapes other than rectangular blend smoothly onto a
background
- have the ability to have gradual drop shadows and hilites
GIF does have transparency on a pixel level but you can turn only on or off. Gif
only supports 256 colors max which is not sufficient to produce a photorealistic
appearance
JPEG supports more than 256 colors but is a lossy compression scheme such that
the images loose quality significantly. Furthermore no transparency or alpha
channels is supported here.
In a nutshell: If we want professionally looking stunning skins we oughta have
alpha channels in PNG.
Comment 73•25 years ago
|
||
Bumping Severity to reflect reality (and to see if the problem with the CC:
list truncating is NS 4.x-specific, or also occurs on Mac IE 5.)
Severity: enhancement → normal
Summary: [skins][RFE] PNG [alpha] transparency not supported → [skins] PNG [alpha] transparency not supported
Whiteboard: alpha still not supported correctly → alpha still not supported correctly . (mac&win support only: 05-??-00)
Comment 74•25 years ago
|
||
Mass-adding beta2 keyword to all skins bugs.
Comment 75•25 years ago
|
||
As a point of reference for the URL I referenced in the 1999-07-05 entry above
(which includes lots of transparent PNGs, most with RGBA-palettes), I've just
added a new page with screen shots here:
http://www.cdrom.com/pub/png/pngs-img-ie5mac.html
The full-scale versions are 24-bit PNGs, so they'll be a tad slow over a modem.
But at least they're interlaced, and the half-scale images embedded in the page
are much smaller JPEGs.
Comment 76•25 years ago
|
||
Looking at Chris Lilley's "alphatest.png" page, the compositing by Netscape 6
looks pretty terrible.
http://www.w3.org/Graphics/PNG/inline-alpha-table
http://www.w3.org/Graphics/PNG/inline-alpha.html
On the other hand, PNGs with binary transparency, even
if carried in the alpha channel, look OK.
Here's some code that you can use to help with the alpha compositing problem.
It's effect is to cause libpng to return to the application a PNG whose
alpha channel has been modified to contain only 0's and 255's, which
seem to be rendered properly with NN-6. This code uses the libpng "user
transform feature", whereby you only need to supply the transform function
and to name it in a call to png_set_user_transform(), which you can put
among any other png_set_whatever(). The code is open source freeware.
I sent this to Greg the other day, and he remarked that the appearance of
the transformed file was quite good, considering the simplicity of the
code. I've been using this method of dithering for many years with good
success.
#if defined(PNG_READ_USER_TRANSFORM_SUPPORTED)
/* Put this somewhere ahead of your main program */
*
* GlennRP_random_dither_alpha user transform function for libpng
*
* Dithers the alpha channel down to binary transparency
*
* Requires rand() function that generates a random number in the range
* 0 .. (2^15 -1)
*
* COPYRIGHT NOTICE, DISCLAIMER, and LICENSE:
*
* If you modify this file you may insert additional notices after this
* sentence.
*
* The "GlennRP_random_dither_alpha" function is supplied "AS IS".
* The author disclaims all warranties, expressed or implied,
* including, without limitation, the warranties of merchantability and of
* fitness for any purpose. The author assumes no liability for direct,
* indirect, incidental, special, exemplary, or consequential damages, which
* may result from the use of this function, even if advised of the
* possibility of such damage.
*
* Permission is hereby granted to use, copy, modify, and distribute this
* source code, or portions hereof, for any purpose, without fee, subject
* to the following restrictions:
*
* 1. The origin of this source code must not be misrepresented.
*
* 2. Altered versions must be plainly marked as such and must not
* be misrepresented as being the original source.
*
* 3. This Copyright notice may not be removed or altered from any
* source or altered source distribution.
*
* The Author specifically permits, without fee, and encourages the use of
* this source code as a component to supporting the PNG file format in
* commercial products. If you use this source code in a product,
* acknowledgment is not required but would be appreciated.
*/
void
GlennRP_random_dither_alpha(png_structp png_ptr, png_row_infop row_info,
png_bytep data)
{
png_bytep cp=data+1;
if(png_ptr == NULL || row_info == NULL || png_ptr->color_type < 4)
return;
if(row_info->bit_depth == 8)
{
int i;
if(row_info->color_type == 6)
{
for (i=0; i<row_info->width; i++,cp+=2)
{
cp += 2;
if (*cp < (rand()>>7))
*cp = 0;
else
*cp = 255;
}
}
else
{
for (i=0; i<row_info->width; i++,cp+=2)
{
if (*cp < (rand()>>7))
*cp = 0;
else
*cp = 255;
}
}
}
else /* bit_depth == 16 */
{
int i;
cp++;
if(row_info->color_type == 6)
{
for (i=0; i<row_info->width; i++,cp+=4)
{
cp+=4;
if (*cp < (rand()>>7))
{
*cp = 0;
*(cp+1) = 0;
}
else
{
*cp = 255;
*(cp+1) = 255;
}
}
}
else
{
for (i=0; i<row_info->width; i++,cp+=4)
{
if (*cp < (rand()>>7))
{
*cp = 0;
*(cp+1) = 0;
}
else
{
*cp = 255;
*(cp+1) = 255;
}
}
}
}
}
#endif
/* Put this in your main program after opening your read_ptr, to set
* a callback to the GlennRP_random_dither_alpha function after all other
* read transforms have been accomplished for a row. */
#if defined(PNG_READ_USER_TRANSFORM_SUPPORTED)
# if defined(PNG_READ_EXPAND_SUPPORTED)
/* This is required if you want to dither indexed-color PNGS with tRNS */
png_set_read_expand(read_ptr);
# endif
png_set_read_user_transform_fn(read_ptr, GlennRP_random_dither_alpha);
#endif
Assignee | ||
Comment 77•25 years ago
|
||
Bless you, randeg@alum.rpi.edu! for some Real Help.
I'll play with your patch today on the major 3 platforms.
-P
Comment 78•25 years ago
|
||
At Glenn's request, I merged his alpha-dither function with the existing code in
ipng.cpp and did some tiny cleanups left over from my ill-fated patch #10; the
unified diff is here:
http://pobox.com/~newt/test/moz/grr11.dif
The same thing with ".txt" appended also works, for those with deficient
browsers. (And grr10.dif is still there, too, but it no longer patches
cleanly.)
Comment 79•25 years ago
|
||
I should have mentioned that the patch (grr11.dif) is untested. I was pretty
careful, but one thing I did *not* do was verify that user transforms were
supported in libpng 1.0.2, which I believe is what Mozilla still uses.
Assignee | ||
Comment 80•25 years ago
|
||
thanks, GR. I already have it covered.
-P
Assignee | ||
Comment 81•25 years ago
|
||
*** Bug 35638 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 82•24 years ago
|
||
Big Progress:
1> Conversion from 8bit mask to 1bit dithered mask checked in.
This is great on platforms that don't support alpha blending.
Much thanks to Glenn Randers-Pehrson <randeg@alum.rpi.edu> for the idea
and the algorithm.
2> Tim Rowley <tor@cs.brown.edu> contributed blending code for Unix.
It works like a champ. Part of this
Currently the 8bit conversion to 1bit dithered mask is turned on
for all platforms.
To test full 8 bit alpha, you can change the ifdef in
mozilla/modules/libimg/pngcom/ipng.cpp, line 61, 62 so
CAN_SUPPORT_8_BIT_MASK is defined.
There are still crashes on window clean up, and resizing of images,
so I will leave this turned off for now. ...But feel free to test.
Currently, alpha channel looks great on mac ...thanks to Simon
<sfraser@netscape.com>
and on Unix ...thanks to Tim <tor@cs.brown.edu>. I have some work
to do on wintel, to get rid of color banding.
-pnunn@netscape.com
Comment 83•24 years ago
|
||
I grabbed a sourceball on the evening of 2000-04-14, compiled a completely stock
version, and made a few screenshots of the random-dithered alpha transparency
(mainly for developers of other browsers to see):
http://www.cdrom.com/pub/png/pngs-img-moz-dith.html
It's pretty good, though not in the same league as MSIE 5.0 for Mac. But then I
defined CAN_SUPPORT_8_BIT_MASK in ipng.cpp, recompiled libnspng.so, and fired it
up:
http://www.cdrom.com/pub/png/pngs-img-moz.html
It's gorgeous! Aside from the interlacing bug (bug 3195), it's the equal of
MacIE 5.0. Well done, Tim and Pam! It's truly a lovely thing to behold. I
look forward to seeing this bug closed out at last.
I do have one small patch to fix a minor bit of nonsense near line 300:
*** ipng.cpp.stock Thu Apr 13 12:47:18 2000
--- ipng.cpp Sat Apr 15 13:45:51 2000
***************
*** 291,301 ****
ipng_p->alpharow = NULL;
#if defined(CAN_SUPPORT_8_BIT_MASK)
! if(png_ptr->color_type || PNG_COLOR_MASK_ALPHA )
! ic->image->header.alpha_bits = 8/*png_ptr->pixel_depth*/; /*
8 */
! else
#endif
- ic->image->header.alpha_bits = 1;
ic->image->header.alpha_shift = 0;
ic->image->header.is_interleaved_alpha = TRUE;
}
--- 294,303 ----
ipng_p->alpharow = NULL;
#if defined(CAN_SUPPORT_8_BIT_MASK)
! ic->image->header.alpha_bits = 8;
! #else
! ic->image->header.alpha_bits = 1;
#endif
ic->image->header.alpha_shift = 0;
ic->image->header.is_interleaved_alpha = TRUE;
}
Greg
Comment 84•24 years ago
|
||
Forgot to mention that I opened a related performance bug: bug 36002. This has
to do with the large disparity between scrolling opaque images and scrolling
alpha-transparency ones (which sets it apart from bug 26502). I don't believe
this is directly related to ImageLib--it seems to cut across layout (which
should know whether there are any dynamic elements on the page), the compositor
(which is probably where the main fix would go), and gfx+libimg (which is the
source of the alpha-compositing code that gets called far too often).
Assignee | ||
Comment 85•24 years ago
|
||
Enabled 8 bit mask generation on all platforms.
If you find a bug, please create a new bug report
for it and don't reopen this one. This bug has
been drowned in verbage and has been less effective
in communicating technical details.
thanks,
pnunn
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Keywords: beta2
Resolution: --- → FIXED
Comment 86•24 years ago
|
||
Rubber-stamping as "verified that functionality is implemented
cross-platform".
So, if anyone would like to identify and report new bug reports containing
any holes in the PNG transparency implementation, please feel
empowered to do so. (we know Binary transparency doesn't work, 19283)
Status: RESOLVED → VERIFIED
Comment 87•24 years ago
|
||
8-bit transparency doesn't work on Windows, either. See bug 36694.
Comment 88•24 years ago
|
||
Please be the first ones to fully support the PNG transparency. I think it
would really be a big point to brag about, and we could all start creating much
better looking graphics/effects.
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•