LinuxQuestions.org - imagemagick problem: height-and-width not deterministic when I crop an png file.

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - imagemagick problem: height-and-width not deterministic when I crop an png file. (https://www.linuxquestions.org/questions/linux-software-2/imagemagick-problem-height-and-width-not-deterministic-when-i-crop-an-png-file-753685/)

imagemagick problem: height-and-width not deterministic when I crop an png file.

After spending a few hours and having some little sleep,
I am very puzzled and disturbed by the fact that new-new-02-5-1.png does not have the intended 818x788. It must have to do with cropping with
nonzero offsets.

Can anyone please tell me what is wrong ? I have the following
simple steps to illustrate my problem.

Quote:

identify 01-5-1.png
01-5-1.png PNG 1280x1024 1280x1024+0+0 DirectClass 3.4e+02kb

zero offsets
convert 01-5-1.png -crop 1091x788+0+0 new-01-5-1.png
identify new-01-5-1.png
new-01-5-1.png PNG 1091x788 1091x788+0+0 DirectClass 3.6e+02kb

convert new-01-5-1.png -crop 818x788+0+0 new-new-01-5-1.png
identify new-new-01-5-1.png
new-new-01-5-1.png PNG 818x788 818x788+0+0 DirectClass 2.7e+02kb

nonzero offsets
convert 01-5-1.png -crop 1091x788+99+113 new-02-5-1.png
identify new-02-5-1.png
new-02-5-1.png PNG 1091x788 1280x1024+99+113 DirectClass 4.4e+02kb

convert new-02-5-1.png -crop 818x788+0+0 new-new-02-5-1.png
identify new-new-02-5-1.png
new-new-02-5-1.png PNG 719x675 1280x1024+99+113 DirectClass 2.2e+02kb

On Fedora 10,

Quote:

Version: ImageMagick 6.4.0 07/27/08 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC

The output is slightly different, but the final sizes are consistent with the previous test:

Quote:

identify 01-5-1.png
01-5-1.png PNG 1280x1024 1280x1024+0+0 DirectClass 8-bit 341.168kb 0.120u 0:02

zero offsets
convert 01-5-1.png -crop 1091x788+0+0 new-01-5-1.png
identify new-01-5-1.png
new-01-5-1.png PNG 1091x788 1280x1024+0+0 DirectClass 16-bit 360.328kb 0.140u 0:02

convert new-01-5-1.png -crop 818x788+0+0 new-new-01-5-1.png
identify new-new-01-5-1.png
new-new-01-5-1.png PNG 818x788 1280x1024+0+0 DirectClass 16-bit 271.461kb

nonzero offsets
convert 01-5-1.png -crop 1091x788+99+113 new-02-5-1.png
identify new-02-5-1.png
new-02-5-1.png PNG 1091x788 1280x1024+99+113 DirectClass 16-bit 444.352kb

convert new-02-5-1.png -crop 818x788+0+0 new-new-02-5-1.png
identify new-new-02-5-1.png
new-new-02-5-1.png PNG 719x675 1280x1024+99+113 DirectClass 16-bit 224.748kb

With some reservations, I conclude that the first crop mess up the origin in the output png file (or some meta information mess up). The dimension of the second crop will be totally wrong because of that. With my colleague's help (a good pair of extra eyes and
intelligent guess work), the problem goes away if the first crop is stored in a bmp format (we just tried that format, can't say with other format), and the second crop crops perfectly. It seems this is a subtle bug in ImageMagick. Well, I get what I want. Hopefully some
ImageMagick developer will reproduce this error and fix it for the goodness of the community.