Closed Bug 3013 Opened 26 years ago Closed 24 years ago

[skins] PNG [alpha] transparency not supported

Categories

(Core Graveyard :: GFX, defect, P2)

Product:
Core Graveyard
Component:
GFX
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: pnunn)

References

(
URL
)

Details

(Whiteboard: alpha still not supported correctly . (mac&win support only: 05-??-00))

Attachments

(4 files)

A red to transparent ramp. Easy way to check alpha support.
2.82 KB, image/png
Details
image for simple testcase
817 bytes, image/png
Details
HTML for simple testcase, using attached image
709 bytes, text/html
Details
Demonstrates incorrect compositing in Mozilla up to M13
150 bytes, text/html
Details 
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.
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
Status: NEW → ASSIGNED
QA Contact: 1698
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.)
Assignee: michaelp → kmcclusk
Status: ASSIGNED → NEW
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.
Status: NEW → ASSIGNED
Target Milestone: M7
Assignee: kmcclusk → dcone
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: M7 → M8
Component: Compositor → Viewer App
Component: Viewer App → Compositor
Target Milestone: M8 → M10
OS: Windows 95 → All
Summary: PNG transparency not supported → PNG [alpha] transparency not supported
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.
The PNG icon at the URL above is now fixed, and Mozilla displays it identically
to the GIF.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
The PNG's have transparency..
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?
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.
Status: RESOLVED → REOPENED
Whiteboard: alpha still not supported correctly
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
Assignee: dcone → pnunn
Status: REOPENED → NEW
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.
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: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: WORKSFORME → INVALID
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?
Thresholded alpha is NOT A BUG. It may be an
implementation you dont like, but it is not a
bug.
-p
Status: RESOLVED → REOPENED
"It's not a bug, it's a feature!"

Thus, re-opening as a feature request, for after Pam has finished more critical
functionality.
Severity: normal → enhancement
Resolution: INVALID → ---
Summary: PNG [alpha] transparency not supported → [RFE] PNG [alpha] transparency not supported
Target Milestone: M10 → M20
[Re-opened as RFE, M20.]
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: pnunn → newt
Status: REOPENED → NEW
Its a pleasure to work with you, Greg.
-p
Status: NEW → ASSIGNED
Apologies to all for the unnecessarily strong language.  (Private message sent
to Pam.)

Greg
*** Bug 2587 has been marked as a duplicate of this bug. ***
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)
*** Bug 14926 has been marked as a duplicate of this bug. ***
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
OS: All → Linux
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).
...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.
OS: Linux → All
Hardware: PC → All
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?
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
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
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!
are you volunteering to write some compositing code for linux us to use on
linux?
FWIW, I implemented code in nsImageMac.cpp to do 8-bit alpha blending on Mac.
This is not checked in yet.
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.
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
Another testcase: http://www.w3.org/Graphics/PNG/inline-alpha-table to test
compositing against different backgrounds
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.
*** Bug 19283 has been marked as a duplicate of this bug. ***
*** Bug 19539 has been marked as a duplicate of this bug. ***
*** Bug 19538 has been marked as a duplicate of this bug. ***
*** Bug 19538 has been marked as a duplicate of this bug. ***
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?
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).
Per e-mail from Greg, he has relinquished PNG component ownership; thus, 
reassigning assigned bugs to ImageLib owner.
Assignee: newt → pnunn
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
*** Bug 26894 has been marked as a duplicate of this bug. ***
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.
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
styles@ergonet.com: So, are you volunteering to write the code...?

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 :)
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.

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.
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.
matty@box.net.au: So, are _you_ volunteering to write the code...? ;)

Is there some documentation available as to where one should poke?
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.
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.

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
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.

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.)
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...
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
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.

Please do support transparency / real alpha channel for PNG images.

Thanks a lot

Peter Weustink


Wow. 100 votes.
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
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.
*** Bug 19283 has been marked as a duplicate of this bug. ***
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.
Keywords: beta2, skins
Summary: [RFE] PNG [alpha] transparency not supported → [skins][RFE] PNG [alpha] transparency not supported
Blocks: 29160
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)
Mass-adding beta2 keyword to all skins bugs.
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.
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


Bless you, randeg@alum.rpi.edu! for some Real Help.
I'll play with your patch today on the major 3 platforms.

-P

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.)
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.
thanks, GR. I already have it covered.
-P
*** Bug 35638 has been marked as a duplicate of this bug. ***
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
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
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).
Keywords: nsbeta2
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
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
8-bit transparency doesn't work on Windows, either.  See bug 36694.
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.
Keywords: skins
Blocks: majorbugs
No longer blocks: majorbugs
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: