possible PNG bug with string format %A

[fmw42]

IM 6.6.8.5 Q16 Mac OSX Tiger

%A image alpha channel (true/false)

The following two tests used to work, but now the second one fails.

# this is correct
convert -size 100x100 xc:white white.png
convert white.png -format "%A" info:
False

# this should produce True
convert white.png -alpha on white_alpha.png
convert white_alpha.png -format "%A" info:
False


Similarly:


# this works
convert -size 100x100 xc:white white.png
convert white.png -format "%[channels]" info:
gray

# this should be graya or grayalpha?
convert white.png -alpha on white_alpha.png
convert white_alpha.png -format "%[channels]" info:
gray

Nor does it work with -alpha set.


Similarly with a color image:

# this should be True
convert rose: -alpha set rose_alpha.png
convert rose_alpha.png -format "%A" info:
False

# this should be rgba
convert rose_alpha.png -format "%[channels]" info:
rgb

[glennrp]

It's different from before, in that the PNG encoder won't write an
all-opaque alpha channel, and the PNG decoder won't report one.

The files are consequently smaller. Some people thought it was
an error to write files that were larger than they needed to be. I
wouldn't say "it fails" but "it's better than it was".

You can force the encoder to write RGBA by using the PNG32
subformat or by using the "-define PNG:color-type=6" option.

Currently "-define PNG:color-type=4" is sometimes not effective
in forcing the encoder to write a Gray-alpha PNG with an all-opaque
alpha channel, but that is fixed in IM 6.6.8-6, SVN revision 3920.

Also, as mentioned previously in other threads, you can't use
"identify" or "convert ... info:" to find out about the way an
image was stored in the file. You can, however, find out some
things about a PNG file, including the bit-depth and PNG colortype
using "-debug coder".

[fmw42]

You can force the encoder to write RGBA by using the PNG32
subformat or by using the "-define PNG:color-type=6" option.

In IM 6.6.8.5 Q16 Mac OSX Tiger,

# does not work
convert white.png -alpha transparent white_alpha.png
convert white_alpha.png -format "%A" info:
False

# works
convert white.png -alpha transparent PNG32:white_alpha.png
convert white_alpha.png -format "%A" info:
True

# does not work
convert white.png -alpha set PNG32:white_alpha.png
convert white_alpha.png -format "%A" info:
False


# does not work
convert white.png -alpha transparent -define PNG:color-type=4 white_alpha.png
convert white_alpha.png -format "%[channels]" info:
gray


HOWEVER: Things work correctly with TIFF

convert white.png -alpha transparent white_alpha.tif
convert white_alpha.tif -format "%A" info:
True

I understand the idea of keeping the file size down, but I don't like the inconsistency with these operations for different types of images that support transparency.

I suggest that this should be discussed further and reconsidered!

[anthony]

I don't mind png: turning of unneeded alpha. GIF does that too!

But png32: should have alpha as it was specifically requested!

[glennrp]

I don't mind png: turning of unneeded alpha. GIF does that too!

But png32: should have alpha as it was specifically requested!

It does! It is the diagnostic method used here that doesn't see it.
As I have said before, use "identify -debug coder" or "pngcrush -n -v"
or "pngcheck -v" or "od -c" to find out what's actually in the PNG file.

[fmw42]

I don't mind png: turning of unneeded alpha. GIF does that too!

Sorry I don't understand this answer? What do you mean by "turning"?

I think PNG should be handled just like TIFF and GIF with respect to -alpha on or -alpha set or -alpha opaque.

[glennrp]

I don't mind png: turning of unneeded alpha. GIF does that too!

Sorry I don't understand this answer? What do you mean by "turning"?

I think PNG should be handled just like TIFF and GIF with respect to -alpha on or -alpha set or -alpha opaque.

I'm sure he meant "turning off".

What do you expect from a PNG8 or PNG24 with a tRNS chunk? with a tRNS chunk that only contains 255 (opaque)?
with a tRNS chunk that specifies a transparent value for a color that isn't present?

It seems reasonable to me to return no alpha if the image is fully opaque. We did it the other way
for a while but then the written images were larger than they needed to be.

[fmw42]

What do you expect from a PNG8 or PNG24 with a tRNS chunk? with a tRNS chunk that only contains 255 (opaque)?
with a tRNS chunk that specifies a transparent value for a color that isn't present?

It seems reasonable to me to return no alpha if the image is fully opaque. We did it the other way
for a while but then the written images were larger than they needed to be.

Well I don't understand tRNS chunks. But my concern is that TIFF and GIF behave differently now from PNG. They have the same issues with respect the 8-bit or less with transparency, do they not? I certainly don't understand image formats that well. But if one says to set the alpha channel to opaque (which is a user choice and one does not have to do that if you want to keep the image smaller), then the alpha channel should be there.

If one changes this behavior for PNG, then why not change it for GIF, TIFF or any other format that has transparency. Then -alpha set and -alpha opaque would not even be needed.

Am I missing something important here about all this. I certainly would appreciate a better understanding.

My concern is lack of consistency, which make things very confusing for users.

[glennrp]

All PNG files carry an alpha channel, either explicitly or implicitly,
and so does ImageMagick's image data.

Should the PNG decoder always report that alpha is present, then?
It doesn't seem to be very useful information. I'd rather know if there is
really some data there that I have to handle.

If you want to know the details about how the image was encoded
before png.c decoded it, you'll need to use something other than
"identify" to find that out.

[fmw42]

Perhaps I am looking at the wrong issue, then. So what then is the point of %A and %[channels] if they do not report the information correctly? Are those working reasonably for PNG. They behave differently for TIFF and GIF doing the same thing with -alpha set and -alpha opaque! Does identify -format %A and %[channels] need to be modified for PNG so that one gets meaningful information (or at least consistent with what one gets for GIF and TIFF)? Or do we need to modify the GIF and TIFF formats so they behave like you now have PNG?

Am I looking at this all wrong? Seems that for 32bit formats (24-bits plus alpha channel) and for grayscale with alpha channel, one should get consistent results between PNG, GIF and TIFF. I am not sure about 8-bit pseudocolor or less with some graylevel assigned to transparency. That is more of a mystery to me and may not be simple. But how is that handled with respect to PNG, GIF and TIFF? Are they consistent when trying to find out if there is real transparency?

Please forgive my ignorance on all this. I just want to understand how to deal with it all and hope that it would consistently handled so as not to confuse me or any other users.

P.S. Glenn, please note that I appreciate all the time and hard work you have put into improving PNG.

Fred

[glennrp]

The PNG encoder could return "alpha is present" always, since it is always present.

It could return "alpha is present" only when there is actual transparency in one or more pixels

Or it could return something else. Apparently you want something else.

Consider a PNG containing a 1x1 image, with just one opaque white pixel.

This could be conveyed many different ways.

64-bit RGBA
32-bit RGBA
48-bit RGB with no tRNS chunk
48-bit RGB with tRNS (any 48-bit RGB color but white)
24-bit RGB with no tRNS chunk
24-bit RGB with a tRNS any 24-bit RGB color but white
32-bit Gray-Alpha
16-bit Gray-Alpha
16-bit Gray with no tRNS chunk
16-bit Gray with a tRNS any 16-bit gray level but white
8-bit Gray with no tRNS chunk
8-bit Gray with tRNS, any 8-bit gray level but white
4-bit Gray with no tRNS
4-bit Gray with tRNS, any 4-bit gray level but white
2-bit Gray with no tRNS
2-bit Gray with tRNS, any 2-bitgray level but white
1-bit BW with no tRNS
1-bit BW with tRNS 1-bit black
8-bit indexed with no tRNS
8-bit indexed with tRNS, any palette index but white
4-bit indexed with no tRNS
4-bit indexed with tRNS, any 4-bit index but white
2-bit indexed with no tRNS
2-bit indexed with any 2-bit index but white
1-bit indexed with no tRNS
1-bit indexed with tRNS black index

I think that's the complete list of possiblities for an opaque image.
You tell me which of those should report alpha on and which
should report alpha off. They all represent the same image.
My personal opinion is that all of them should not report an
alpha channel.

Now consider a 1x1 image with one fully transparent white
pixel. This can also be represented in a number of ways, but
not quite so many (essentially the same list as above without
the "no tRNS chunk cases):

64-bit RGBA
32-bit RGBA
48-bit RGB with tRNS (tRNS color is white)
24-bit RGB with a tRNS white chunk
32-bit Gray-Alpha
16-bit Gray-Alpha
16-bit Gray with a tRNS white
8-bit Gray with tRNS 8-bit white
4-bit Gray with tRNS, 4-bit white
2-bit Gray with tRNS, 2-bit white
1-bit BW with tRNS 1-bit white
8-bit indexed with tRNS, palette index to white
4-bit indexed with tRNS, 4-bit index to white
2-bit indexed with 2-bit index to white
1-bit indexed with tRNS white index

I consider all of those to have an alpha channel, although
only four of them (RGBA and Gray-alpha) have one
explicitly.

Now consider a 1x1 image with one 50% transparent white
pixel. This can also be represented in a number of ways, but
still fewer (essentially the same list as above without
the RGB+tRNS and Gray+tRNS cases):


64-bit RGBA
32-bit RGBA
32-bit Gray-Alpha
16-bit Gray-Alpha
8-bit indexed with tRNS, palette index to white
4-bit indexed with tRNS, 4-bit index to white
2-bit indexed with 2-bit index to white
1-bit indexed with tRNS white index

and I also consider all of this group to have an alpha channel,
although only the first four have one explicitly.

[fmw42]

It could return "alpha is present" only when there is actual transparency in one or more pixels

This certainly makes sense.

But then I am confused about -alpha set and -alpha opaque in combination with %A and %[channels]. What should they be returning for PNG, GIF and TIFF and why should they not all be consistent? Is PNG that much different from GIF or TIFF with respect to how transparency is reported?

As I said above, perhaps it is not a PNG issue, but a general issue of how IM deals with opaque transparency and reporting!

convert rose: -alpha set rose.png
identify -format %A rose.png
False

convert rose: -alpha set rose.gif
identify -format %A rose.gif
False

convert rose: -alpha set rose.tif
identify -format %A rose.tif
True

So it seems that both GIF and PNG have been modified so as to not enable the alpha channel if perfectly opaque, but TIFF does? It is inconsistent! Why should that be?


Either -alpha set and -alpha transparent should be removed if one is not going to enabling opaque alpha channel for all format that deal with transparency/alpha channel. (And also -alpha on when there is no transparency already disabled)

OR %A and %[channels] should be modified to so as to know the difference between a perfectly opaque alpha (or no alpha) vs real alpha/transparency data. That is treat perfectly opaque alpha the same as no alpha.



Anthony or Magick,

Am I missing something here or some situation where one needs -alpha set or -alpha opaque if all image formats that support transparency ignore the command to enable a perfectly opaque alpha channel?

Or Is there some way to make %A and %[channels] to be consistent across the various image formats that support transparency?


Any one else out there have an opinion or concern about this inconsistency?

[anthony]

First I am not going to use the term 'alpha' as really internally IM uses 'matte' values.

The %A I believe reports weather a transparency channel was defined by the image.

Remember this is optional. An image may not need transparency, but may have a transparency channel that is fully opaque,

In terms of image file formats.

GIF images may have a 'transparent index' color. this is a special setting in the GIF file format and its presence or absence determines if a transparency channel is created or not, even if NO actual pixel in the image is using a transparency index value.

HOWEVER when IM is saving a GIF file, IM will not set a transparent index IF the image is fully-opaque. that way it has 256 colors available for an opaque image, rather that 255 colors + transparency. It does not matter if the image has a transparency channel of not in memory, if it is not using transparency IM does not give the GIF a transparency index.

The same is true of PNG8: and by default PNG images that have less that 256 colors

HOWEVER when saving using PNG32: you are specifically requesting the PNG coder to save transparency into the file, weather it is used or not. On read a 32bit PNG should then always contain a transparency channel. while reading a 24bit PNG should not have a transparency channel created. It does not matter is transparent pixels is present or not.

This means that when reading any PNG image, you may get transparency, or you may not get transparency. Depends on the file being read.

The %A then if used immediately after reading the image should represent if the image file format allowed the image have some transparent pixels. It does not mean it actually did contain transparent pixels.

So if you MUST HAVE transparency channel, read the image and add -alpha set.
-alpha set takes out that guesswork and ensures a transparency channel is present and thus should force %A to be true. Same does for almost all the -alpha methods except -alpha off.

NOTE: channel images created using -separate also has alpha off. %A => false
Though in reality alpha channel data is actually still present and can be turned 'on' again

Here hand_point.gif has transparency...

Code: Select all

  convert im/images/hand_point.gif -format '%A' -write info: \
              -channel R -separate +channel -write info: \
               -alpha on info:
  True
  False
  True

here tree does not..

Code: Select all

  convert im/images/tree.gif -format '%A' -write info: \
              -channel R -separate +channel -write info: \
               -alpha on info:
  False
  False
  True

At the end it was true, as the result has a transparency channel defined, but the image was still fully-opaque, with no actual transparent pixels.

Images are found http://www.imagemagick.org/Usage/images/

[glennrp]

So, the PNG decoder should return True if the input was RGBA, GA, or has a tRNS
chunk, whether there is actual transparency or not, and False for RGB, Gray, or
indexed wthout a tRNS chunk? Or should it just always return True?

The PNG encoder is going to write RGBA or GA if you request it with PNG32 or
with -define PNG:color-type=4 (or 6), but there isn't a way to force it to write a
tRNS chunk when there is no transparent pixel in the image, so in this case
if you write a PNG with tRNS and read it back, the %A will change from true
to false because the tRNS chunk doesn't get copied.

I still think the usefulness of knowing whether there is actual transparency
present outweighs the usefulness of knowing whether the image was once
encoded in a format that supports transpararency, but that's just me.

[glennrp]

What the "xc:" format does seems to be consistent with what you are asking for:

• identify -format %A xc:white
  False
  identify -format %A xc:"#ffffff"
  False
  identify -format %A xc:"#ffffffff"
  True
  identify -format %A xc:"#ffffff00"
  True
  identify -format %A xc:none
  True

So I'll revise the PNG decoder to act similarly. "%A" will be True if the image format
is RGBA or GA or if the tRNS chunk is found.

I won't change the encoder; it writes RGBA or GA if explicitly requested, but
otherwise drops the alpha channel if it is all-opaque.