[Bug 914285] [NEW] "convert -resize @area" sometimes creates image with incorrect dimensions
Hrvoje Nikšić
hniksic at gmail.com
Tue Jan 10 14:13:19 UTC 2012
Public bug reported:
I want to resize a number of images to the resolution of 2200x1650 or
1650x2200, depending on whether the image is 4:3 or 3:4 (all source
images are in one of those aspects). I have tried a number of geometry
specifications and found that the best way to achieve this is to specify
the pixel count, i.e. 3630000 (2200*1650) pixels.
However, specifying pixel count of 3630000 sometimes creates a 2200x1649
image. An example is shown below:
$ convert -size 2304x3072 xc:white x.jpg
$ identify x.jpg
x.jpg JPEG 2304x3072 2304x3072+0+0 8-bit PseudoClass 256c 27.8KB 0.000u 0:00.000
$ convert -resize @3630000 x.jpg y.jpg
$ identify y.jpg
y.jpg JPEG 1649x2200 1649x2200+0+0 8-bit PseudoClass 256c 14.4KB 0.000u 0:00.000
I would expect a 1650x2200 image to be created. (Note that the source
image has an exact 3:4 aspect ratio.) The bug occurs on 64-bit builds
of ImageMagick, but apparently not on 32-bit ones.
A workaround is to specify one pixel more, @3630001, which creates the
correct 1650x2200 image.
Version of ImageMagick used for testing is:
$ convert --version
Version: ImageMagick 6.6.2-6 2011-03-16 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features: OpenMP
In addition to this version, I have also verified that the bug occurs in
the newer ImageMagick 6.7.4-0 2011-12-13 on 64-bit ArchLinux.
** Affects: imagemagick (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
I want to resize a number of images to the resolution of 2200x1650 or
1650x2200, depending on whether the image is 4:3 or 3:4 (all source
images are in one of those aspects). I have tried a number of geometry
specifications and found that the best way to achieve this is to specify
the pixel count, i.e. 3630000 (2200*1650) pixels.
However, specifying pixel count of 3630000 sometimes creates a 2200x1649
image. An example is shown below:
$ convert -size 2304x3072 xc:white x.jpg
- $ identify x.jpg
+ $ identify x.jpg
x.jpg JPEG 2304x3072 2304x3072+0+0 8-bit PseudoClass 256c 27.8KB 0.000u 0:00.000
- $ convert -resize @3630000 x.jpg y.jpg
- $ identify y.jpg
+ $ convert -resize @3630000 x.jpg y.jpg
+ $ identify y.jpg
y.jpg JPEG 1649x2200 1649x2200+0+0 8-bit PseudoClass 256c 14.4KB 0.000u 0:00.000
+
+ I would expect a 1650x2200 image to be created. (Note that the source
+ image has an exact 3:4 aspect ratio.) The bug occurs on 64-bit builds
+ of ImageMagick, but apparently not on 32-bit ones.
+
+ A workaround is to specify one pixel more, @3630001, which creates the
+ correct 1650x2200 image.
+
+ Version of ImageMagick used for testing is:
$ convert --version
Version: ImageMagick 6.6.2-6 2011-03-16 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features: OpenMP
+
+ In addition to this version, I have also verified that the bug occurs in
+ the newer ImageMagick 6.7.4-0 2011-12-13 on 64-bit ArchLinux.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to imagemagick in Ubuntu.
https://bugs.launchpad.net/bugs/914285
Title:
"convert -resize @area" sometimes creates image with incorrect
dimensions
Status in “imagemagick” package in Ubuntu:
New
Bug description:
I want to resize a number of images to the resolution of 2200x1650 or
1650x2200, depending on whether the image is 4:3 or 3:4 (all source
images are in one of those aspects). I have tried a number of geometry
specifications and found that the best way to achieve this is to
specify the pixel count, i.e. 3630000 (2200*1650) pixels.
However, specifying pixel count of 3630000 sometimes creates a
2200x1649 image. An example is shown below:
$ convert -size 2304x3072 xc:white x.jpg
$ identify x.jpg
x.jpg JPEG 2304x3072 2304x3072+0+0 8-bit PseudoClass 256c 27.8KB 0.000u 0:00.000
$ convert -resize @3630000 x.jpg y.jpg
$ identify y.jpg
y.jpg JPEG 1649x2200 1649x2200+0+0 8-bit PseudoClass 256c 14.4KB 0.000u 0:00.000
I would expect a 1650x2200 image to be created. (Note that the source
image has an exact 3:4 aspect ratio.) The bug occurs on 64-bit builds
of ImageMagick, but apparently not on 32-bit ones.
A workaround is to specify one pixel more, @3630001, which creates the
correct 1650x2200 image.
Version of ImageMagick used for testing is:
$ convert --version
Version: ImageMagick 6.6.2-6 2011-03-16 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features: OpenMP
In addition to this version, I have also verified that the bug occurs
in the newer ImageMagick 6.7.4-0 2011-12-13 on 64-bit ArchLinux.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/914285/+subscriptions
More information about the foundations-bugs
mailing list