#280 Better documentation for spurious gm identify in Q8 compilation

[David N. Welton]

I haven't looked around too much, but I have seen Bob's comments about the Q16 vs Q8 results from gm identify, so you must know it's a problem for people that it gives bad answers. I suppose there is a good reason for not 'fixing' it, so that's not why I'm filing this bug.

I'm filing it because it should be way more widely advertised that gm identify will give a spurious answer, at the very least in the FAQ, and probably elsewhere in the documentation.

Thank you

[Bob Friesenhahn]

GM identify rarely gives "bad answers". Rather, it reports on the image that it has loaded into memory based on the properties of the image in memory. There are thousands of permutations given the 100+ image formats and the subformats for each image format. Not even the original depth is reported correctly, and not all formats can even be summarized in that way. Some formats are entirely rendered while some others are varying depth in the same image. If the input is read using some conversion tool (e.g. 'dcraw') then there is no reasonable way to report the properties of the input format.

In what ways can I document what identify reports so that it is less misleading and users will satisfied?

[David N. Welton]

Hi,

What we encountered was this:

• We have a 16 bit PNG. ImageMagick, which on Debian/Ubuntu, is compiled with Q16, confirms this.
• GraphicsMagick, which is compiled with Q8, says it's an 8 bit PNG.

That is incorrect.

I don't pretend to know 1% of what you know about how this all works, but I do know that sometimes these things are unavoidable, so I looked around quite a bit in the docs to see where this was pointed out, and I think I pieced it together via bug reports and forum comments before I found anything that clicked in the actual GM documentation.

Thank you!

[Bob Friesenhahn]

Added a FAQ entry regarding what 'identify' reports.