possible PNG bug with string format %A

[fmw42]

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.

I would agree, but that is something different from %A and %[channels] or would require those to change.

It would be nice to have a means of knowing via IM if there was real transparency in PNG, GIF, TIFF or any format that supports transparency; other than looking at every pixel or histogram.

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.

Sorry I don't understand the tRNS chunk issue? Will %A return the same value for PNG8 with a transparent color as for GIF with a transparent color? Or if -alpha set is enabled on an opaque PNG8 or GIF image -- presumably from what Anthony said, the latter will report False for GIF.

However, I was originally more concerned that 32-bit or grayA in any compatible image format -- that they all behave consistently with regard to %A and %[channels].

[glennrp]

As of IM-6.6.8-7, SVN r3948, the PNG decoder sets image->matte=MagickTrue
when the PNG colortype is RGBA or GA, or if the tRNS chunk is present,
regardless of whether any pixel is transparent.

[glennrp]

Sorry I don't understand the tRNS chunk issue? Will %A return the same value for PNG8 with a transparent color as for GIF with a transparent color? Or if -alpha set is enabled on an opaque PNG8 or GIF image -- presumably from what Anthony said, the latter will report False for GIF.

However, I was originally more concerned that 32-bit or grayA in any compatible image format -- that they all behave consistently with regard to %A and %[channels].

In a PNG, the tRNS chunk is just a cheap way of conveying the alpha channel, similar to GIF. You can mark a single color as transparent, and then any pixel having that R,G,B value or Gray value is fully transparent. In the case of indexed-color PNGs, you can define a transparency (or partial transparency) value for each index. If you write a PNG8 and it actually has transparency, it will be like GIF. If it is opaque, no tRNS chunk will be written and it will be like an opaque GIF.

[fmw42]

In a PNG, the tRNS chunk is just a cheap way of conveying the alpha channel, similar to GIF. You can mark a single color as transparent, and then any pixel having that R,G,B value or Gray value is fully transparent. In the case of indexed-color PNGs, you can define a transparency (or partial transparency) value for each index. If you write a PNG8 and it actually has transparency, it will be like GIF. If it is opaque, no tRNS chunk will be written and it will be like an opaque GIF.

Glenn,

Thanks for the explanation.

Fred

[anthony]

It would be nice to have a means of knowing via IM if there was real transparency in PNG, GIF, TIFF or any format that supports transparency; other than looking at every pixel or histogram.

Except that is the ONLY way of knowing! That sort of detail is not recorded, and if it was, would be a pain to keep up-to-date after every operation! It is actually how the internal IM 'has actual transparency' type functions work!

At least you can abort the search immediately on finding a fully-transparent, more that 50% transparent, or just semi-transparent pixel (depending on your needs). Most images with transparency will abort on the first pixel, so it is generally fast for 'true', but slow for 'false'.

Note that for saves of image file formats with only boolean transparency, should use a 50% threshold on the transparency channel, for the determination on if a pixel is classed as transparent or not.

Now perhaps a special %[...] value can be added to do that test, but I would include a 'threshold' (for the abort) as part of the test, due to the users different needs and definition of transparency.

[glennrp]

It is only slow if image->matte is true and the image is opaque. If image->matte is false, then the pixels don't have to be examined; there might be data in pixel->opacity but if so it is garbage. I suggest using %B for this purpose (%B: image is opaque, true/false). The data is available to "identify"; first look at image->matte, then look at Max alpha. If the latter is 0 (or is less than the fuzz value) then the image is opaque.

[fmw42]

I presume you mean %A rather than %B (there is no %B in the list of string formats). But the concept is good and that is similar to what I have been doing to test in my scripts.

Thanks Glenn

Fred

[glennrp]

I presume you mean %A rather than %B (there is no %B in the list of string formats). But the concept is good and that is similar to what I have been doing to test in my scripts.

I meant %B (%A would report if there is an alpha channel and the new %B would report if the image is opaque).

[fmw42]

Thanks for the clarification. I did not realize you meant a new string format.

Fred

[anthony]

I suggest using %B for this purpose (%B: image is opaque, true/false).

%B is fine as a 'only opaque pixels in image' test. However you can not supply an argument to single character escapes. That is why I suggested a %[...] type escape.

It could also be a %[opaque] escape. Lets keep the single letter escapes reserved for 'primary' information about the image.

Perhaps %[transparent:{percent}] with 100 meaning only fully-transparent and 0 meaning any semi-transparency at all. Note "only fully-opaque pixels found" is always a false for this.

[magick]

Look for the %[opaque] escape in the next release of ImageMagick.