Legacy ImageMagick Discussions Archive

using ImageMagick 7.0.2-6 (and some previous versions) built with "--with-quantum-depth=32" on ArchLinux (x86_64) fails to convert from xwd to png.

eg "convert foo.xwd foo.png" produces a png of the correct dimensions but blank.

If rebuilt with the default quantum depth of 16 then the conversion works successfully.

cheers
mark

If you link to an XWD that shows the problem, that would increase the chance of someone looking at the problem.

If you link to an XWD that shows the problem, that would increase the chance of someone looking at the problem.

I would have attached a file, but can't do that here so you can get an XWD that demonstrates the problem at the below url:

http://homepages.ecs.vuw.ac.nz/~mark/20 ... 630-02.xwd

What was your exact command line that failed? NOTE that IM 7 uses "magick" in place of "convert"

What do you get from regarding features and delegates? Please show everything returned.
IM 7 default install is HDRI. Q16 should be adequate for any needs. Why do you need a Q32 HDRI install?

PNG does not support 32-bit files. On Q32 with or without HDRI, you need to add -depth 16 to your convert command.

Tiff will support 32-bit files. See -define quantum:format=floating-point at http://www.imagemagick.org/script/formats.php

I have tested on IM 7.0.2-7 with Q16, Q16 HDRI, Q32 and Q32 HDRI. Without the -depth 16, you get results as described for Q32 HDRI. Q32 works mostly but gives black in the smaller window.

If I add -depth 16, it works fine for all above versions.

What do you get from regarding features and delegates?

% convert -version
Version: ImageMagick 7.0.2-6 Q32 x86_64 2016-08-11 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2016 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC HDRI
Delegates (built-in): bzlib fftw fontconfig freetype gslib jng jpeg lcms openexr png ps tiff webp x xml zlib

IM 7 default install is HDRI. Q16 should be adequate for any needs. Why do you need a Q32 HDRI install?

Our graphics group asked for it. I don't know why.

If I add -depth 16, it works fine for all above versions.

OK, I'll pass that on.

Perhaps your graphics group is confused about 32-bit and 64-bit computers vs needing 32-bit graphics. Q32 tries to make 32-bits per channel not 32-bits per image. 32-bits per image is 8-bits for each RGBA channels. So all you would need would be Q8. But it is better to work with Q16 for better accuracy. Some image formats support 16-bits per channel so 48-bits per image. But PNG is not one of them. Tiff will support 32-bits per channel, but I doubt your graphics group needs that. You probably don't even need HDRI. But default IM 7 comes with Q16 and HDRI.

No, they were aware of what Q32 was and had some applications when they cared about the extreme accuracy, but didn't expect that enabling it would break other simple operations.

I suppose the surprising thing is that if png doesn't support 32-bit and something tries to do that, that you get a bogus output file rather than a "can't do that" error message.

Anyway, think I'll build the graphics guys a special Q32 version of imagemagick and revert the default one to Q16.

This seems to be a bug in IM v7, or perhaps a delegate.

When saving an image to PNG (or any other format), IM should never need telling to reduce the image depth. It should do so by itself.

Using IM v7.0.1-0 Q32 HDRI, Cygwin build on Windows 8.1: The result is bad, a constant colour, almost white (238/255).
This is the same bad result.
The result looks good (a screen shot).

Using the same three commands with IM 6.9.3-7 Q32 HDRI, Cygwin build on Windows 8.1, "convert" instead of "magick", gives a good result.

Even if IM has (accidentally?) changed so bit-reduction is no longer automatic, this wouldn't explain why "-depth 8" gives a bad result.

EDIT: Another test: This is the same bad result. I conclude there is certainly a bug.

I expect to fix this bug sometime.

This seems to be a bug in IM v7, or perhaps a delegate.

This is the same bad result. I conclude there is certainly a bug.

I would like to see more words about this.
Is it a confirmed bug in IM v7?

glennrp has said it was a bug (I presume in PNG) and will fix it at some point when he gets time

glennrp has said it was a bug (I presume in PNG) and will fix it at some point when he gets time

Thanks.

Sorry, I do not know the details of the issue. Glen is the PNG expert.