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

[eben]

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

That's still not entirely consistent with the observed behavior, though, is it? If only fully-transparent pixels are touched by -alpha background, then why am I seeing a red halo at all? Those halo pixels would then, by definition, be fully transparent...yet I see them.

When I render the image, the pixels can be considered in three categories:

1. those which I expect to be fully transparent (the "background"), and which in fact render as such
2. those which I expect to be exactly 50% opaque (the "foreground"), and which in fact render as such, in their intended color
3. The set of pixels at the boundary (the "aliasing"), which must either be a) fully transparent or b) semi-opaque, but which for some reason exhibit the alpha color causing the halo, which is not consistent with pixels of type 1 or type 2.

My apologies if I'm missing something obvious. It's clear my understanding was a bit thin to begin with, but it seems that either the red alpha color should only apply to pixels which are actually invisible (which would result in no halo at all), or that it would somehow affect all pixels which aren't fully opaque eg. by matting them against it (which would result in an all-red image). It seems to do neither.

[fmw42]

That's still not entirely consistent with the observed behavior, though, is it? If only fully-transparent pixels are touched by -alpha background, then why am I seeing a red halo at all? Those halo pixels would then, by definition, be fully transparent...yet I see them.

I think those pixels are the ones that have only partial transparency. The full transparent ones now have a black background or whatever color background you specified.

[fmw42]

Your red.png image is an 8-bit palette png with alpha channel.

The IM verbose information shows that the underlying image is red and alpha is not binary. This is evident from the histogram information, where all rgb channel are rgb(27,28,38). Only the alpha varies.


Image: red.png
Format: PNG (Portable Network Graphics)
Class: DirectClass
Geometry: 256x192+0+0
Resolution: 28.35x28.35
Print size: 9.02998x6.77249
Units: PixelsPerCentimeter
Type: PaletteAlpha
Endianess: Undefined
Colorspace: sRGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 8-bit

Histogram:
677: ( 27, 28, 38,255) #1B1C26 srgba(27,28,38,1)
84: ( 27, 28, 38, 85) #1B1C2655 srgba(27,28,38,0.333333)
71: ( 27, 28, 38, 17) #1B1C2611 srgba(27,28,38,0.0666667)
31: ( 27, 28, 38,238) #1B1C26EE srgba(27,28,38,0.933333)
20: ( 27, 28, 38,221) #1B1C26DD srgba(27,28,38,0.866667)
19: ( 27, 28, 38,170) #1B1C26AA srgba(27,28,38,0.666667)
19: ( 27, 28, 38,153) #1B1C2699 srgba(27,28,38,0.6)
19: ( 27, 28, 38, 34) #1B1C2622 srgba(27,28,38,0.133333)
17: ( 27, 28, 38,187) #1B1C26BB srgba(27,28,38,0.733333)
16: ( 27, 28, 38,119) #1B1C2677 srgba(27,28,38,0.466667)
15: ( 27, 28, 38, 68) #1B1C2644 srgba(27,28,38,0.266667)
14: ( 27, 28, 38,136) #1B1C2688 srgba(27,28,38,0.533333)
14: ( 27, 28, 38,102) #1B1C2666 srgba(27,28,38,0.4)
13: ( 27, 28, 38,204) #1B1C26CC srgba(27,28,38,0.8 )
9: ( 27, 28, 38, 51) #1B1C2633 srgba(27,28,38,0.2)
8: ( 27, 28, 38, 64) #1B1C2640 srgba(27,28,38,0.25098)
48106: (255, 0, 0, 0) #FF000000 srgba(255,0,0,0)
Background color: red


Oddly, the background color is red and not rgb(27,28,38). In fact all your images have the same histogram. Only the background color parameter is different. Oddly your black.png has a white background color as does the white.png. Thus I suspect that you have only changed the background color parameter to red, black or white and not the actual data. That was why I thought that -alpha background did not work with 8-bit alpha, contrary to what Anthony said, or does not work unless you have 32-bit color.

It would appear that the background color is being ignored by all viewers other than your renderer, probably because it is 8-bit palette with an 8-bit alpha rather than a binary alpha. You are seeing the background color where the alpha value is partially transparent, which does not seem to happen with other viewers.

To be honest I am not sure what is going on. The best advice would probably come from the PNG developer (glennrp) as to what is actually set here.

[snibgo]

I see that red.png etc are counter-examples to

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

For these files, the "Alpha:" property takes the value of fully transparent pixels, but there are other non-opaque pixels with different RGBA values.

Perhaps the rule applies only to non-palette files.

EDIT: That was reading the rule as saying "seems to appear only for ...". Red.png etc show that it appears for other images.

[eben]

Your red.png image is an 8-bit palette png with alpha channel.

Oddly, the background color is red and not rgb(27,28,38). In fact all your images have the same histogram. Only the background color parameter is different. .

Right, that's because I actually created red.png from black.png by changing the background color value to red. I did notice something more while looking at the verbose output for red.png. The following:

Code: Select all

convert black.png -background Red -alpha background red.png

Actually has side effects we don't want. In particular, the png:IHDR.color_type gets converted from 6 (RGBA) in the input to 3 (Indexed) in the resulting output. Oddly, Photoshop displays the output file with 1 bit alpha, while other viewers I've tried still preserve full alpha. We can fix this, it seems, by using:

Code: Select all

convert black.png -background Red -alpha Background PNG32:red.png

This results in output with the red background color, but retains the RGBA color type. Regardless, I see the halo when rendering them. By the way, I've updated the files in dropbox with the RGBA versions.

It would appear that the background color is being ignored by all viewers other than your renderer, probably because it is 8-bit palette with an 8-bit alpha rather than a binary alpha. You are seeing the background color where the alpha value is partially transparent, which does not seem to happen with other viewers.

That was what I thought was going on, but my experiments with half-red.png seem to indicate otherwise! Since no pixels in that image are opaque, I would expect to see a reddish color for every non-transparent pixel. Yet I still see the halo, with all of the "interior" non-opaque pixels displaying properly.

To be honest I am not sure what is going on.

We can certainly agree on that!

[fmw42]

Perhaps we need to hear further from glennrp, the PNG developer. He may be able to shed more light on this issue.

The problem is only you can see the red halo or do you have an example that anyone can see with most viewers.

[eben]

The problem is only you can see the red halo or do you have an example that anyone can see with most viewers.

I've spent a little more time digging into the details, and believe I've finally discovered a perfectly logical explanation for the effects I've been seeing. I printed out the decoded image data pixel by pixel in a small sample image to confirm that it is correct, and that only fully transparent pixels contain the unwanted halo color. Since the images we've been testing with are relatively small, we had been enlarging them in order to see the artifacts more clearly. What I hadn't realized until moments ago was that the artifacts only appear when the image has been scaled (up or down). It's the resampling algorithm that's to blame! The algorithm apparently used by OpenGL does not ignore the RGB values of the fully transparent pixels when resampling, thus tinting the interpolated pixels with their color which is otherwise meant never to be visible.

This also explains the previously perplexing results with half-red.png. The edge pixels were "special" in the sense that they were adjacent to fully transparent pixels. It had nothing to do with whether or not the pixel itself was fully opaque. There is no matting against the background color going on either. It's just the interpolation.

I had also tried a variety of image viewers, which of course didn't reveal the artifacts since when zooming in with these tools no interpolation is performed. The image is merely upscaled with a nearest-neighbor algorithm, which preserves the integrity of the RGBA values of the source image data. If, on the other hand, you were to take one of these images (say, red.png) and actually resize it in a tool like Photoshop, as opposed to zooming in on it, you will in fact see the halo. I have also seen other tools, such as Processing (in 2D mode, not 3D, as the 3D mode uses OpenGL and exhibits the same artifacts!) properly up-sample the image without resulting in the halo, presumably by ignoring the RGB values of the transparent pixels when resampling.

With these answers in hand, I'm off to some OpenGL forums to learn more about their resampling algorithms. Thanks, all!

[holden]

Is the OP getting similar results to this? http://blender.stackexchange.com/questi ... rt-blender

For example in 3D work textures using transparency can have straight alpha or premultiplied alpha as a render option. A video http://vimeo.com/11064139

*cross posted

[fmw42]

Does this help your situation. Your image under the transparency in black.png is a solid color but not black. This changes the background parameter to black and also the pixels under the transparency to black. You can do the same with red and see what happens.


convert black.png -background black -alpha background -alpha off -fill black -colorize 100 -alpha on black2.png

convert black.png -background red -alpha background -alpha off -fill red -colorize 100 -alpha on red2.png

In the red case, the opaque and semi transparent pixels are red rather than black and the full transparent pixels are still fully transparent.

[eben]

Is the OP getting similar results to this? http://blender.stackexchange.com/questi ... rt-blender

For example in 3D work textures using transparency can have straight alpha or premultiplied alpha as a render option. A video http://vimeo.com/11064139

*cross posted

Yes, that's similar to the effect I see. I'll have to take the time to watch that video; thanks for the link!

Does this help your situation. Your image under the transparency in black.png is a solid color but not black. This changes the background parameter to black and also the pixels under the transparency to black. You can do the same with red and see what happens.

convert black.png -background black -alpha background -alpha off -fill black -colorize 100 -alpha on black2.png

convert black.png -background red -alpha background -alpha off -fill red -colorize 100 -alpha on red2.png

This results in an image whose actual visible color is black or red, respectively. I'm not out to change the visible color at all. My goal is to retain the actual color of the source image, without getting the halo effect when the image is resampled. Most importantly, I won't have control over all input images — I'm interested in finding a solution to this problem which causes any given image to appear properly when resampled for display with OpenGL.

[fmw42]

If you resize in IM do you still have the same problem when viewing in OpenGL

I took your red.png image and resized by 170% and do not see any red halo when viewing in several tools and zooming on my resized image.

[eben]

No, if the image is displayed at native resolution without the need for resampling then it appears fine even in OpenGL. Scaling the image via IM does not yield artifacts. Also, I think I got confused earlier when I suggested using Photoshop — more recent tests indicate that no artifacts appear when scaling an image there either.

So far the issue only appears when rendering such a PNG at a non-native resolution within OpenGL. That said, I've reproduced the problem across several platforms which use OpenGL as a rendering engine, including Processing. Here's a link to a minimal processing sketch which illustrates the problem:

https://dl.dropboxusercontent.com/u/108 ... k/halo.zip

It renders an image of a white circle with a transparent background that happens to have red fully transparent pixels. The image is shown at 2x scale on a white background (and, being white on white, shouldn't be visible at all), but you'll see a red ring. If you change the size of the sketch to 64x64 (same size as the image) the ring will go away. If you keep the larger size but cut the OPENGL bit from the size call to run in 2D mode (which avoids OpenGL), the ring will go away. It seems, so far, that only OpenGL's interpolation algorithms are to blame.

Does anyone know more about the resampling algorithms used internally by ImageMagick? Do they consciously ignore the R, G, and B values of fully transparent pixels when computing the interpolation?

[fmw42]

Anthony could explain it best, -resize comes from Paul Heckbert's Zoom. You might look that up on Google.

see resizeImage() in resize.c in the Magick folder of your IM source download

I believe it does some kind of alpha weighting on each channel when resizing.

[eben]

Well, to round out this discussion, pre-multiplied alpha seems to be just the trick I was looking for. Thanks for that link! The video was helpful as a starting point, but I actually learned about the more useful technical aspects of the format at the link below. It's nothing a naive Google search wouldn't turn up, but I'll link to it anyway for convenience. The "further reading" links on this page are even more helpful and a bit more technical.
http://blog.rarepebble.com/111/premulti ... in-opengl/

My next goal was to learn how to premultiply alpha in a PNG (which technically doesn't support it since it's lossy, although you can obviously stuff whatever pixel values you want into the format) using ImageMagick. I was slightly surprised there isn't a shortcut flag for achieving this transformation, but this thread proved helpful:
viewtopic.php?f=1&t=23463

Unfortunately, not all of the suggested solutions in that thread produced the expected output for me. This is what worked best in my tests:

Code: Select all

convert foo.png -write mpr:temp -background black -alpha Remove mpr:temp -compose Copy_Opacity -composite PNG32:foo-premult.png

Thanks again!