updating alpha layer

[webshaker]

How can I modify the alpha of a png file in order to put

if (alpha < 128)
alpha = 0
else
alpha =255

in order to keep transparency but not alpha ?

Thank's

By the way, to improve compression algorithme, is it possible to put pixel fully transparent pixel to (0, 0, 0, 0) ?
I've remark that RGB components a not alway 0 when alpha value is 0 !

[fmw42]

How can I modify the alpha of a png file in order to put

if (alpha < 128)
alpha = 0
else
alpha =255

in order to keep transparency but not alpha ?

Thank's

By the way, to improve compression algorithme, is it possible to put pixel fully transparent pixel to (0, 0, 0, 0) ?
I've remark that RGB components a not alway 0 when alpha value is 0 !

For your first question:

convert image -channel alpha -threshold 50% +channel resultimage

However, this will still have a binary alpha channel -- either full on for some pixels or full off for others. You would have to use gif (or possibly png) in 8-bit color mode with a transparency color to get rid of the alpha channel.


I don't understand your next question about making a pixel fully transparent. Is it just one pixel or every pixel? Please clarify! rgba(0,0,0,0) is fully transparent or just use colorname none or transparent

see color definitions at http://www.imagemagick.org/script/color.php

[webshaker]

Thank you for your reply.
Yes actually, I convert my png to gif and then convert to png again, but it was very long, and the quality was some time not very good due to gif conversion !

So I'll try your command.


For my remark, you can have pixel that have alpha value to 0, but R, G and B components to positive value (>0)
In this case, the pixel is fully transparent and the RBG values are not usefull.
I wonder if the compression could not be better if for those pixel I replace RGB value to 0. In all case they are fully tranparent !

[fmw42]

This command changes all transparent colors rgba(r,g,b,0) to pure black transparency rgba(0,0,0,0)

convert moon.png -background black -alpha background moon_alphaback.png

see
http://www.imagemagick.org/Usage/masking/#alpha
http://www.imagemagick.org/Usage/maskin ... background

[glennrp]

Try using output format PNG8:filename.png
The encoder internally does the threshold 50% on the alpha channel,
and also reduces the color count to 255 or 256 so it can be
written as an indexed PNG.

The PNG8 format doesn't require all of the underlying colors
of transparent pixels be merged into one transparent color, so that
would have to be done as a separate step.

Glenn

[anthony]

Yes actually, I convert my png to gif and then convert to png again, but it was very long, and the quality was some time not very good due to gif conversion !

Of course that would happen. PNG was originally designed to replace GIF as a "Practical Network Graphic" -- PNG.

GIF was originally designed for small limited color iconic symbolic images, not real practical images! As a consequence it has many problems: it is limited to 8 bit quality, boolean transparency, simplistic compression, but the worst was a 256 color limit. The only good point was that it can generate animations, and that was only a convention that was added to it later by the first popular web browser, Mosaic!

That 256 color limit is the worse problem it has, as it means it can take a lot of time to reduce the number of colors so an image (especially large real-world images) to something suitable for GIF, and then still come out horrible! The more colors in an image (because the image is larger) the worse it gets!

It is a bit like trying to fit a cow (real world image), though a small pipe (old network bandwidth), and putting it back together. The result can be recognised as coming from a cow, but you are more likely to just get sausages (a symbolic icon).

(I don't believe I came up with that as a metaphor!)

[glennrp]

The PNG8 format doesn't require all of the underlying colors
of transparent pixels be merged into one transparent color, so that
would have to be done as a separate step.
Glenn

Looking at the code in png.c for PNG8, it does try to merge
all of the transparent pixels into image->transparent_color, but
only if a semitransparent color is present in the original image.
Starting with SVN revision 5006 (IM-6.7.1-9), It will also merge
them if only multiple fully-transparent colors are present.

[fmw42]

The PNG8 format doesn't require all of the underlying colors
of transparent pixels be merged into one transparent color, so that
would have to be done as a separate step.
Glenn

Looking at the code in png.c for PNG8, it does try to merge
all of the transparent pixels into image->transparent_color, but
only if a semitransparent color is present in the original image.
Starting with SVN revision 5006 (IM-6.7.1-9), It will also merge
them if only multiple fully-transparent colors are present.

Glenn,

Do you mean also binary transparency (some full transparent and some full opaque) for 6.7.1.9 in addition to 8-bit transparency?

Fred

[glennrp]

Do you mean also binary transparency (some full transparent and some full opaque) for 6.7.1.9 in addition to 8-bit transparency?
Fred

If you convert to PNG8 format, the result is only binary transparency, in 6.7.1-9 and previously. It is conveyed
in the PNG tRNS chunk. What is fixed in 6.7.1-9 is that sometimes the tRNS chunk would contain more
than one fully transparent color. Now there is only one; if the input image contains only one then that is the
underlying color of the transparent pixel. If there are more than one, then the underlying color of all
transparent pixels is changed to image->background. I had attempted to implement this in IM-6.6.8-7 but
under some circumstances (multiple transparent colors but no semitransparent pixels in the input image)
a tRNS chunk with more than one transparent entry was written, along with extra PLTE entries to hold
them.

While working on this bugfix, I found that the -strip option was causing the encoder to exclude the tRNS
chunk, so that also is fixed in IM-6.7.1-9 and you can safely write

Code: Select all

 convert input.png -strip png8:output.png

and preserve the binary transparency. I am thinking that the PNG8 format ought to do -strip by default,
given that PNG8 was originally intended for writing images for the web.

[fmw42]

Glenn,

Thanks for the more in depth explanation. I understand better now what you are fixing.

Fred