What does the "Alpha" key mean in identify output for a PNG?

[eben]

Hey all. I've got two 8-bit RGB PNG images that are nearly identical, exported with different versions of Adobe Illustrator. When I run "identify -verbose" on these images, they differ notably in an "Alpha" key which follows the general "Image Statistics" section in the output. I can't make good sense of it. It's value is a color, and for one image that color is "none"; for the other, it's "rgba (255, 255, 255, 0)". I should note, for clarity, that both images do have a proper 8-bit alpha channel.

I have a suspicion that this value is causing problems when this image is rendered using libPNG, because the latter image appears with an awful white halo in the anti-aliased regions. I'd like to confirm that by adjusting this value to see if the artifacts disappear, but I can't find information about the meaning of the "Alpha" key with respect to the PNG specification, nor what ImageMagick command would allow me to change it. It's not the background color or transparent color, and from the looks of it the alpha options all apply changes directly to the alpha channel of the image, not to this separate unique color value. Can someone point me in the right direction? Thanks!

Here are the relevant excerpts from the "good" image:

Code: Select all

Image statistics:
    Overall:
      min: 0 (0)
      max: 255 (1)
      mean: 63.1902 (0.247805)
      standard deviation: 15.8512 (0.0621616)
      kurtosis: 5440.35
      skewness: 387.7
  Alpha: none   #00000000

And the "bad" one:

Code: Select all

Image statistics:
    Overall:
      min: 0 (0)
      max: 255 (1)
      mean: 250.343 (0.981739)
      standard deviation: 32.176 (0.126181)
      kurtosis: 45.1909
      skewness: -6.8461
  Alpha: rgba(255,255,255,0)   #FFFFFF00

[glennrp]

the "Alpha:" property seems to appear for any image (PNG or otherwise) in which all non-opaque pixels have
the same RGBA values.
.
In your two images, the first has transparent pixels with RGB=000000 and the other has white ones (FFFFFF).

It is in fact the "transparent color" if you used "-transparent white" or some other color when creating the image.
Try for example "convert logo: -transparent white logo_white.png" and "convert logo: -fill black -opaque white -transparent black logo_black.png"
and run "identify -verbose" on the resulting PNGs.

[anthony]

It is set by -transparent-color and represents the color to set the 'transparent color index' to in GIF and PNG8 files.

That is one entry in the colortable represents transparency (boolean on/off transparency only), but it has a color, and this is the color to use.

See IM Examples, Formats, GIF Transparency Color
http://www.imagemagick.org/Usage/formats/#gif_trans

[eben]

Thanks for the replies, but unfortunately I'm still rather confused.

Here are the results of the logo manipulations:

Code: Select all

$ identify -verbose logo_black.png | grep -Ei "(transparent|alpha)"
  Transparent color: black

$ identify -verbose logo_white.png | grep -Ei "(transparent|alpha)"
    alpha: 1-bit
    Alpha:
  Alpha: rgba(255,255,255,0)   #FFFFFF00
  Transparent color: none

And then those of my two images:

Code: Select all

$ identify -verbose bag.png | grep -Ei "(transparent|alpha)"
    alpha: 8-bit
    Alpha:
  Alpha: rgba(255,255,255,0)   #FFFFFF00
  Transparent color: none

$ identify -verbose good.png | grep -Ei "(transparent|alpha)"
    alpha: 8-bit
    Alpha:
  Alpha: none   #00000000
  Transparent color: none

So, a few things to note:

1. The alpha channel of the logo is 1-bit, not 8-bit as in my images, and so bad edges are expected since there's no antialiasing whatsoever.
2. It still appears that the transparent color and the "alpha" value, whatever it is, are distinct. For instance, the black logo image doesn't even have a value for "Alpha", but has black as its transparent color. Meanwhile, in my two images, the one that works as expected has both Alpha and transparent color values of "none", while the one which fails has a transparent color of "none" but #FFFFFF00 as its Alpha value.

[anthony]

First in palette indexed images (images with a limited table of colors), one color is used to denote transparency.
This is the 'alpha color', or transparent index. GIF is famous for this style of image storage, but PNG can also do this.

However by only having one color to hold alpha, the transparency in the image is purely boolean. That is it is either ON, or it is OFF. This means that the alpha channel (not that it actually exists) would be a 1-bit depth (on or off) with no semi-transparency possible.

That is what you are seeing.

For information on dealing with Boolean Transparency see GIF Transparency
http://www.imagemagick.org/Usage/formats/#gif_trans

[eben]

First in palette indexed images (images with a limited table of colors), one color is used to denote transparency.
This is the 'alpha color', or transparent index. GIF is famous for this style of image storage, but PNG can also do this.

However by only having one color to hold alpha, the transparency in the image is purely boolean. That is it is either ON, or it is OFF. This means that the alpha channel (not that it actually exists) would be a 1-bit depth (on or off) with no semi-transparency possible.

That is what you are seeing.

I'm still experiencing this issue, and unfortunately none of these responses have fully explained the phenomena. My images are not PNG8 — they are PNG32. They have 8 bit, non-boolean alpha, as is easily confirmed by opening them in most image editors which display them properly without aliasing, and illustrated in the identify snippets above. The transparent-color field for both is set to "none", yet the inadequately specified "Alpha" field (as reported by identify) is set to something other than "none" in the bad image. All I'm looking for is a convert command which will allow me to set whatever property that field pertains to. "alpha", "transparent", and "transparent-color" do not seem to affect the value of that field.

Is there some means by which my PNG-32 could wind up with some property for 1-bit alpha set incorrectly despite the fact that the additional alpha info is also included within the image? If so, what is that property and how might I change it?

Thanks!

[snibgo]

Some experiments, creating new 32-bit PNG files under IM v6.8.6-0, confirm that ...

the "Alpha:" property seems to appear for any image (PNG or otherwise) in which all non-opaque pixels have the same RGBA values.

In my experiments, the "Alpha:" property only appears when all non-opaque pixels have the same RGBA value, and it is that RGBA value.

Can you put up your "good" and "bad" files? Put them on Dropbox or somewhere and post the URLs here.

[anthony]

PNG in index mode (PNG8), with boolean alpha, uses a color index to specify all the pixels that are all fully-transparent.
These transparent pixel can also have a color, and as such it has a alpha color value.

If a PNG only only has boolean alpha but multiple transparent colors, then it can not be saved in index mode (well not easily) so will need to be saved as a much much larger 32 bit PNG.

A simple way to ensure this is to threshold the alpha channel, then use -alpha background to set the color of al fully-transparent pixels. Actually doing the last for 32 PNG images is also a good idea as the uniform 'hidden' color makes the image compress a lot better.

See IM Examples, Masking & Background Removal, Alpha Background
http://www.imagemagick.org/Usage/maskin ... background

Also Better PNG Compression
http://www.imagemagick.org/Usage/formats/#png_compress

[snibgo]

Confirmed that, where ry.png has rgba(100%%,0,0,0) for all non-opaque pixels, hence shows "Alpha:" at that value, then ...

Code: Select all

convert ry.png -background Green -alpha background ry2.png

... changes "Alpha:" to "srgba(0,128,0,0) #0000808000000000".

If:

Meanwhile, in my two images, the one that works as expected has both Alpha and transparent color values of "none", while the one which fails has a transparent color of "none" but #FFFFFF00 as its Alpha value.

... then a cure would seem to be:

Code: Select all

convert bad.png -background Black -alpha background good.png

[fmw42]

convert bad.png -background Black -alpha background good.png

Not sure without testing, but that may only work with a binary alpha channel.

[snibgo]

Yes. An experiment suggests there is another condition for the "Alpha:" property to show, that the alpha channel is zero for all non-opaque pixels. Put another way, "Alpha:" will show only when the alpha is binary. This contradicts what eben says above, which is why I want to see the files.

[anthony]

Yes. An experiment suggests there is another condition for the "Alpha:" property to show, that the alpha channel is zero for all non-opaque pixels. Put another way, "Alpha:" will show only when the alpha is binary. This contradicts what eben says above, which is why I want to see the files.

Just remember that -alpha background operator however will work regardless of if the images alpha channel is boolean or not. It only touches fully transparent pixels.

[eben]

... then a cure would seem to be:

Code: Select all

convert bad.png -background Black -alpha background good.png

Partial success! I've confirmed that this does indeed restore a value of "none" to "Alpha:". Unfortunately, now that I know more, it doesn't completely solve my problem. It's possible that ImageMagick can't solve my problem at all, but for the sake of completeness, let me lay out the knowns and unknowns.

Things I understand:

• 1. Different versions of Adobe products produce PNGs with different "Alpha:" output for the same input file. Odd, but fine, given that...

• 2. Despite those differences, most image viewers display both identically, with full 8 bit translucency (or at least, NOT a 1 bit alpha mask)

• 3. My own image display pipeline, built atop LibPNG and OpenGL, displays these images incorrectly, with bad aliasing artifacts appearing in whatever color "Alpha:" is set to.

• 4. I can change the value of the "Alpha:" property with the command suggested by snibgo.

• 5. Even the output of such a conversion which sets "Alpha:" to Red appears normally with no aliasing and no hint of red in most image viewers.

Things I don't understand:

• 1. I don't know for sure, but my new suspicion here is that even the "good" image is being rendered improperly with my pipeline, and that it just wasn't evident given that the background was dark, and so the aliasing artifacts were black and didn't stand out against it.

• 2. It's clear that somehow or another, despite running the command suggested by snibgo, the image retains full 8-bit transparency, and the command does not in fact cause every non-opaque pixel be the same color in both hue and alpha.

Here are some test images:

https://dl.dropboxusercontent.com/u/108 ... /black.png
https://dl.dropboxusercontent.com/u/108 ... /white.png
https://dl.dropboxusercontent.com/u/108 ... ck/red.png

These are effectively identical except for the "Alpha:" value, which is set according to the filename. The file black.png is actually good.png from my initial post. white.png is effectively bad.png from my initial post, except that in this case I've produced both white.png and red.png using the command snibgo offered using black.png as input. If you open these in your image editor, I expect you will see no difference whatsoever among them, and that all three will have properly aliased edges with varied translucency. (Of course, they have obvious halos of the corresponding color when rendering with my pipeline.)

The remaining question is: what does "Alpha:" really mean given that these images do NOT have 1-bit alpha? A followup would be: why does my image pipeline render these images as though they had 1-bit alpha? It sounds like the latter question is more suited to an OpenGL forum at this point, but it would still be good to better understand how the image data is formatted and what properties are at play when it comes to the rendering. Thanks again for all the help!

[eben]

I know I've been long winded already, but I have one more detail of potential interest. I wanted to make it clear that my pipeline does not render everything with a 1 bit alpha. In fact, it's not even rendering these test images with 1 bit alpha. I created a variant of red.png in which the alpha channel was divided by two, such that all pixels are now translucent:

https://dl.dropboxusercontent.com/u/108 ... lf-red.png

Curiously, the red background halo still appears when rendered in my pipeline, but the "interior" pixels (those which were originally opaque in red.png) appear at their proper color and at 50% opacity. This strikes my as wholly weird. What makes those other semi-opaque pixels near the boundaries special such that they appear red while the remainder of the image appears as expected? I would suspect thresholding of some kind on the rendering end, but I tried this with 1/4 transparency as well and got the same result.

[fmw42]

I know I've been long winded already, but I have one more detail of potential interest. I wanted to make it clear that my pipeline does not render everything with a 1 bit alpha. In fact, it's not even rendering these test images with 1 bit alpha. I created a variant of red.png in which the alpha channel was divided by two, such that all pixels are now translucent:

https://dl.dropboxusercontent.com/u/108 ... lf-red.png

Curiously, the red background halo still appears when rendered in my pipeline, but the "interior" pixels (those which were originally opaque in red.png) appear at their proper color and at 50% opacity. This strikes my as wholly weird. What makes those other semi-opaque pixels near the boundaries special such that they appear red while the remainder of the image appears as expected? I would suspect thresholding of some kind on the rendering end, but I tried this with 1/4 transparency as well and got the same result.

Anthony's message above explains that:

Just remember that -alpha background operator however will work regardless of if the images alpha channel is boolean or not. It only touches fully transparent pixels.

So those pixels have not been fixed by -alpha background