Legacy ImageMagick Discussions Archive

glennrp wrote:The "verbose" outputs show that your "transparent" PNG is color-type 2, and does not have
a tRNS chunk, so it's opaque. But it has 16-bit samples, so maybe GWS has trouble
reading 16-bit PNGs. The other output is 8-bit RGBA, which could be transparent but
only if any of the pixels have a non-255 alpha sample.

You could try adding "-depth 8" as the final option while writing the "transparent" one,
and see if the 8-bit result gets read properly.

You're right. I tried
and Graphic Workshop read the resulting PNG file with no problem, the background was white, and the text was not degraded.

Now that the crisis is over, let me ask a stupid, newbie question:

Since 8-bit color gives us 16M unique colors, which is way more than the human eye can discern, why go to 16-bit color?

8 bits is sufficient for a final colour output. It isn't enough for a final grayscale output.

If image processing is performed with 8 bit precision, the output will have less than 8 bits of precision. It might have 7 or 6. So you need to process with more than 8 bits. Processing with 16 bits generally works fine. For extreme processing, you need even more. I recently showed an example command that creates correct 8-bit output only when processed at 64-bit HDRI.

EDIT: There are other reasons for needing loads of bits. I'm curently writing code for histograms, which count the number of pixels of different colours. If my input images have 35 million pixels, I need to count up to 35 million. 8-bit files can have counts of only 256. Even 16-bits isn't enough. (2^16 = 65536.) I need 32-bits.