#296 Strange -resize WIDTH results with version 1.3.21

[Kasper Grubbe]

I have a PNG-file and I want to scale that to a width of 100, the original info is here:

PNG image data, 127 x 64, 8-bit colormap, non-interlaced

I then try to use the syntax described around the internet:

gm mogrify -resize 100
Result: PNG image data, 100 x 50, 8-bit/color RGB, non-interlaced (expected!)

gm mogrify -resize '100'
Result: PNG image data, 100 x 50, 8-bit/color RGB, non-interlaced (expected!)

gm mogrify -resize '100x'
Result: PNG image data, 99 x 50, 8-bit/color RGB, non-interlaced (UNEXPECTED!)

Okay I think, maybe it was wrong to use the 'x'-character with the resize-flag, so I get my next image and do the same as before:

The image:

PNG image data, 600 x 647, 8-bit/color RGBA, non-interlaced

The test:

gm mogrify -resize 100
Result: PNG image data, 93 x 100, 8-bit/color RGB, non-interlaced (UNEXPECTED!)

gm mogrify -resize '100'
Result: PNG image data, 93 x 100, 8-bit/color RGB, non-interlaced (UNEXPECTED!)

gm mogrify -resize '100x'
Result: PNG image data, 100 x 108, 8-bit/color RGB, non-interlaced (expected!)

I have created a 42 line test-script, with the images in question, it is hosted here: https://s3-eu-west-1.amazonaws.com/static-world/scaletest.zip (also attached) the output from my system is here:

kaspergrubbe@system ~/Desktop/scaletest$ bash run_test.sh
9icBm4ptTc3nRvz: PNG image data, 127 x 64, 8-bit colormap, non-interlaced
1: PNG image data, 100 x 50, 8-bit/color RGB, non-interlaced
2: PNG image data, 100 x 50, 8-bit/color RGB, non-interlaced
3: PNG image data, 99 x 50, 8-bit/color RGB, non-interlaced
P8dN9MNbfvD8Lkj: PNG image data, 600 x 647, 8-bit/color RGBA, non-interlaced
1: PNG image data, 93 x 100, 8-bit/color RGBA, non-interlaced
2: PNG image data, 93 x 100, 8-bit/color RGBA, non-interlaced
3: PNG image data, 100 x 108, 8-bit/color RGBA, non-interlaced
P8dN9MNbfvD8Lkj: PNG image data, 600 x 647, 8-bit/color RGBA, non-interlaced
1: PNG image data, 100 x 108, 8-bit/color RGBA, non-interlaced
2: PNG image data, 100 x 108, 8-bit/color RGBA, non-interlaced
3: PNG image data, 100 x 108, 8-bit/color RGBA, non-interlaced

Something seems wrong to me here, I am running the newest version on OSX, and my info is here:

GraphicsMagick 1.3.21 2015-02-28 Q8 http://www.GraphicsMagick.org/
Copyright (C) 2002-2014 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.
See http://www.GraphicsMagick.org/www/Copyright.html for details.

Feature Support:
Native Thread Safe yes
Large Files (> 32 bit) yes
Large Memory (> 32 bit) yes
BZIP yes
DPS no
FlashPix no
FreeType yes
Ghostscript (Library) no
JBIG no
JPEG-2000 no
JPEG yes
Little CMS no
Loadable Modules yes
OpenMP no
PNG yes
TIFF no
TRIO no
UMEM no
WebP no
WMF no
X11 no
XML no
ZLIB yes

Host type: x86_64-apple-darwin13.4.0

Configured using the command:
./configure '--prefix=/usr/local/Cellar/graphicsmagick/1.3.21' '--disable-dependency-tracking' '--enable-shared' '--disable-static' '--with-modules' '--disable-openmp' '--without-gslib' '--with-gs-font-dir=/usr/local/share/ghostscript/fonts' '--without-x' '--without-lcms' '--without-lcms2' 'CC=clang' 'CXX=clang++'

Final Build Parameters:
CC = clang
CFLAGS = -g -O2 -Wall -D_THREAD_SAFE
CPPFLAGS = -I/usr/local/Cellar/freetype/2.5.5/include/freetype2
CXX = clang++
CXXFLAGS = -D_THREAD_SAFE
LDFLAGS = -L/usr/local/Cellar/freetype/2.5.5/lib
LIBS = -lfreetype -lbz2 -lz -lltdl -lm -lpthread

[Glenn Randers-Pehrson]

GraphicsMagick's documentation does not say what happens if the "x" is omitted. My experiments show that it treats "100" as "100x100".

We need to update the documentation. Note that this behavior is different from ImageMagick, which treats "100" as "100xMAXVAL" and does not document what "100x" is supposed to do.

[Bob Friesenhahn]

It is true that the documentation does not address what should happen if the 'x' is omitted and it does not imply that it may be omitted. GraphicsMagick does not behave based on Internet lore since it provides fairly accurate documentation of its own. The documentation for the function which does the work (GetMagickGeometry) only says this:

"If only the width is specified, the width assumes the value and the height is chosen to maintain the aspect ratio of the image. Similarly, if only the height is specified (e.g., -geometry x256), the width is chosen to maintain the aspect ratio."

Testing shows that the GetGeometry function sets height to width if height is missing and no 'x' was present. This is a workhorse function used for many things in GraphicsMagick (e.g. for parsing resolution values such as via '-density 72') and if we change this behavior, many things will break

[Bob Friesenhahn]

How about this description:

      If only the width is specified,  without  the  trailing
      'x',  then  height is set to width (e.g., -geometry 100
      is the same as -geometry 100x100).  If only  the  width
      is  specified  but  with  the  trailing 'x', then width
      assumes the value and the height is chosen to  maintain
      the  aspect ratio of the image.  Similarly, if only the
      height is specified prefixed by  'x'  (e.g.,  -geometry
      x256),  the  width  is  chosen  to  maintain the aspect
      ratio.

[Bob Friesenhahn]

I have submitted documentation updates which make it clear when an 'x' is needed and what happens if the 'x' is omitted.

Since some other popular software still works as expected with the 'x' then it makes sense to supply the 'x' both for GraphicsMagick and the other software.

[Kasper Grubbe]

Hey, thanks for your answers, it is very appreciated.

Sorry, but I am still confused.

If only the width is specified but with the trailing 'x', then width
assumes the value and the height is chosen to maintain
the aspect ratio of the image.

If that is true, shouldn't the width be 100 in the third example:

gm mogrify -resize '100x'
Result: PNG image data, 99 x 50, 8-bit/color RGB, non-interlaced

Or am I misreading the docs?

[Glenn Randers-Pehrson]

The 99 is incorrect. Using geometry 100x100 does produce the expected result, 100x50.

[Glenn Randers-Pehrson]

Sorry, it was not "incorrect"; it's just not the same as 100x100. It is the closest size fitting inside 100x100 that maintains the aspect ratio of the input image, which is about 1.98, not 100x50 which has an aspect ratio of 2.00 and not 100x51 which has an aspect ratio of 1.96. It is, however, incorrect according to the new documentation.

[Bob Friesenhahn]

Re-opened to fix the 99x50 bug.

[Bob Friesenhahn]

127/64 is 1.984375

99/50 is 1.98

100/50 is 2.0

100/51 is approximately 1.96078431372549019607843137254901960784313725490196.

GM is clearly more closely preserving the original aspect ratio (what it is documented to do without a !) than the other software, even though the width dimension does not match the requested width. I do not know what the other software (of lore) is supposed to do.

[Bob Friesenhahn]

I have studied the code, and discussed this issue with Glenn, and while I agree that the result seems non-intuitive, GraphicsMagick is working as documented. The requirement is that the resized image fit within the specified bounds without altering its aspect ratio (as much as possible). The missing height bound is computed by multiplying the existing image's aspect ratio with the specified width while assuring that appropriate numeric rounding is used.

If we were to change this, then there would be additional unpredictable impact when > and < specifiers are also used.

A simple solution when you do not care about the image height is to specify the desired image width, and a very large height.