When resizing it's not using the first images bit depth. Is it possible to read the incoming bit depth and use that?

[fmw42]

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.

[snibgo]

At the command line, IM 6.9.5-3:

Code: Select all

convert test_layer.png -resize 77x77 -unsharp 1.5x1.2+1.0+0.10 PNG00:t.png

... t.png is "bit depth: 32 bit" according to Windows Explorer.

@i73: I suggest you try this. If it doesn't work, perhaps to need to update to the current version.

[i73]

Thanks guys, I've already written up something myself. This is a great community thanks for all your help, no rush for the PNG dev just tell him to PM me if he needs to, I can assume my problem is extremely rare.

[fmw42]

It would be nice to know if snibgo's suggestion worked or not?

[i73]

It would be nice to know if snibgo's suggestion worked or not?

No it did not. It is the exact same command I was doing myself before.

[glennrp]

pngcheck says Test_Layer.png is 32-bit RGBA while Test_Layer_200.png is 8-bit palette_tRNs.

Sorry for not answering sooner. I'm not subscribed to Magick++ so didn't see it.

[fmw42]

pngcheck says Test_Layer.png is 32-bit RGBA while Test_Layer_200.png is 8-bit palette_tRNs.

Sorry for not answering sooner. I'm not subscribed to Magick++ so didn't see it.

Glenn, if you do

Code: Select all

convert test_layer.png -resize 77x77 -unsharp 1.5x1.2+1.0+0.10 PNG00:t.png

What do you get for t.png? If not 32-bit RGBA, then why is PNG00: not preserving it?

P.S. I have moved this topic to the User's forum, since at this point it is about CLI and not Magick++

[glennrp]

IM refuses to do that due to not having a colormap. However, if you use "-sample" instead of "-resize" and omit the -unsharp directive, then it succeeds because the -sample operation doesn't destroy the colormap.

[fmw42]

IM refuses to do that due to not having a colormap. However, if you use "-sample" instead of "-resize" and omit the -unsharp directive, then it succeeds because the -sample operation doesn't destroy the colormap.

Out of curiosity, then since his image has only one color and an alpha, it is really not 32-bits color, except for the fact that there is no color map. Is that correct?

When imagemagick processed the image with -resize and -unsharp, it should create more colors. Assuming that the number of colors is greater than 256, should it not end up 32-bits?

Is ImageMagick seeing that it the input only has one color and alpha an overriding the 32-bit designation and treating the input as palettealpha and so PNG00: makes the output the same?