possible bug -type truecolor PNG32: reports palettematte

[fmw42]

Glenn,

Sorry if this is still being worked on. But I am still seeing this problem in IM 6.6.8.4 Q16 Mac OSX Tiger


convert logo: -transparent white logot.png
convert logot.png -crop 300x300+200+200 +repage -type truecolormatte PNG32:logot_sub.png
identify -verbose logot_sub.png
Image: logot_sub.png
Format: PNG (Portable Network Graphics)
Class: DirectClass
Geometry: 300x280+0+0
Resolution: 72x72
Print size: 4.16667x3.88889
Units: Undefined
Type: PaletteMatte
Endianess: Undefined
Colorspace: RGB
Depth: 8-bit

Fred

[glennrp]

identify doesn't report on the characteristics of the formatted image. It reports on
the characteristics of the image data after it has been decoded. This image
has transparency and has 256 colors or less, so "identify" figures out that it
is PaletteMatte.

The PNG file is in fact an RGBA (color-type 6) image. If you really need
to see that TrueColorMatte type printed out, then use

Code: Select all

identify -verbose PNG32:logot_sub.png

for the final step. Then identify reports

Type: PaletteMatte
Base type: TrueColorMatte

Perhaps this is a bug but it's not a PNG bug.

[fmw42]

Anthony and/or Magick,

What do you think about this situation. I don't recall that it was this way before. Nevertheless, it is confusing to me and other users who also reported this. Can this be fixed. Seems like adding PNG32: to identify -verbose forces the information to show truetype, but is it really truetype. Should one not be able to make a truetype color PNG by either or both -type truetype PNG32: and get identify to report that without having to add PNG32:

Fred

[magick]

The image type is determined by checking the characteristics of the image. In your example the image has less than 256 unique colors and has an alpha channel so PaletteMatte is the correct image type. The image class is DirectClass that tells you the image is RGB and matte is true so the image is RGBA.

Currently ImageMagick supports 4 types of attributes associated with the original image, its name, width, height, and depth. We could add support for the original image type but it a bit of work since we would need to do this for all 100 of the image formats ImageMagick supports.

[fmw42]

It was my understanding that if you specify either or both -type truecolormatte or PNG32:, that one would then force the image to have those characteristics. Is this not the case? If so, then why not. What is the point of -type truecolormatte or PNG32, if not to force that format?

Pardon my confusion!

Fred

[imguser]

Thank you all for your efforts and answers.

Fred (board user fmw42) opened up this thread because of this thread which I started:
how to crop without changing type (viewtopic.php?f=1&t=18269)

I am not really an expert on this, please keep this in mind when reading this.

First let my try to see if I got this right:
If you have 2x2 and all 4 are just plain black color identify does not care wether the color information is stored in several bytes (many times) but just says:
"That is some black dot you have there. Since it is just 1 color it can not be true color really, I mean what self respecting true color image consists of only 1 color"

I was expecting that identify says:
"Woah, thats a nice true color dot you have there. Real high quality, best black color you can find these days. To see how many bytes are wasted to define it please check your format."

I would coin it as "declared vs. real".
I did not expect identify to analyze the image that far. If there is no single transperent point in the image anymore due to my cropping then it no longer qualifies for TrueColorMatte.
Usually I appreciate a behaviour like this, preferring the "real data". However, it is hard to be aware of this behaviour or to expect it.
Also, maybe at a different occasion I might be interested in the "declared" characteristics of an image.
Therefore I would suggest to add a setting to identify which controls whether the information returned by indentify is based on "after decoding" or "before decoding".
Alone the existance of such a setting would have made me aware of this issue.

[glennrp]

Information "before decoding" is not stored for use by "identify". However, you can learn
a lot about the input file by using the "-debug coder" option. You can learn even more
with third party applications like "pngcheck -v" or "pngcrush -n -v" or what I usually
use, "od -c".