Re: When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?
Posted: 2017-07-07T13:55:19-07:00
No offense taken. We are just trying to understand the issue better.
Any time you do processing such as resize and unsharp, you interpolate pixels, which cause a change in the number of colors. So you could possible go from 1-bit or 8-bits to 24-bits of color and from 1-bit alpha to 8-bit alpha. I am not sure that PNG00: will prevent that. So you might have to do something like using -type or -threshold to ensure you get something compatible. I do not know what "smarts" are built into PNG00:. Going the other way where you start with more colors and somehow reduce the number of colors, I would assume that PNG00: might prevent that. Honestly, I am puzzled why you might get a lower color depth when minimizing with -resize (let alone adding in -unsharp). Either of these processes, typically increase the number of colors, not decrease them.
I think one of the issues is that in your red example, your image is solid one color red and only the alpha channel has any variation. The creating software may think it is 32-bits, but since the base image only has one color, ImageMagick processes it as a 1 color pseudo color image. So ImageMagick thinks the input is pseudo color and so keeps it pseudo color on output. In this case, the resize is not adding any new colors, but the resize might be changing the depth of your alpha channel from 1-bit to 8-bits. I forget whether that image already has 8-bits for alpha. If it does, then it is not increasing the bit depth of the alpha channel. Other tools may not care about the number of colors in the base image and think that it is 32-bit color, just because it is color and has an alpha channel. You could check the colorspace, type and class of the image before processing to decide if what color depth you want to treat the image and assign PNG8, PNG24 or PNG32 to the result. I suspect you do not want to go to this trouble. But it is possible.
Unfortunately, I do not see anything in the ImageMagick verbose information that leads me to believe the output is not the same as the input. But snibgo has pointed out that IM is telling you what it interprets the image color depth to be once it reads the image. I would have expected EXIFTOOL to say that the two are the same.
I sent a message to the PNG developer, but he has not answered yet. Perhaps he is on vacation. But he always answers promptly when available. So please wait. He is the expert on PNG00: and knows more about under what situations it might or might not preserve the color depth. Perhaps he can tell us what is different about the output PNG compared to the input PNG that allows other software such as yours to see them differently.
Any time you do processing such as resize and unsharp, you interpolate pixels, which cause a change in the number of colors. So you could possible go from 1-bit or 8-bits to 24-bits of color and from 1-bit alpha to 8-bit alpha. I am not sure that PNG00: will prevent that. So you might have to do something like using -type or -threshold to ensure you get something compatible. I do not know what "smarts" are built into PNG00:. Going the other way where you start with more colors and somehow reduce the number of colors, I would assume that PNG00: might prevent that. Honestly, I am puzzled why you might get a lower color depth when minimizing with -resize (let alone adding in -unsharp). Either of these processes, typically increase the number of colors, not decrease them.
I think one of the issues is that in your red example, your image is solid one color red and only the alpha channel has any variation. The creating software may think it is 32-bits, but since the base image only has one color, ImageMagick processes it as a 1 color pseudo color image. So ImageMagick thinks the input is pseudo color and so keeps it pseudo color on output. In this case, the resize is not adding any new colors, but the resize might be changing the depth of your alpha channel from 1-bit to 8-bits. I forget whether that image already has 8-bits for alpha. If it does, then it is not increasing the bit depth of the alpha channel. Other tools may not care about the number of colors in the base image and think that it is 32-bit color, just because it is color and has an alpha channel. You could check the colorspace, type and class of the image before processing to decide if what color depth you want to treat the image and assign PNG8, PNG24 or PNG32 to the result. I suspect you do not want to go to this trouble. But it is possible.
Unfortunately, I do not see anything in the ImageMagick verbose information that leads me to believe the output is not the same as the input. But snibgo has pointed out that IM is telling you what it interprets the image color depth to be once it reads the image. I would have expected EXIFTOOL to say that the two are the same.
I sent a message to the PNG developer, but he has not answered yet. Perhaps he is on vacation. But he always answers promptly when available. So please wait. He is the expert on PNG00: and knows more about under what situations it might or might not preserve the color depth. Perhaps he can tell us what is different about the output PNG compared to the input PNG that allows other software such as yours to see them differently.
