Menu ▾ ▴

#356 Wrong output width calculation

v1.0_(example)
open
nobody
None
5
2016-03-17
2016-03-02
Przemysław Sobala
No

I came across a weird situation:

$ gm convert http://i.wp.pl/a/i/tsw/webby_conf.png -resize 600x /tmp/tmp.jpg

produces 599x212 image:

$ gm identify /tmp/tmp.jpg 
/tmp/tmp.jpg JPEG 599x212+0+0 DirectClass 8-bit 15.6Ki 0.000u 0:01

I think it's not an expected result, I would expect gm to produce an image 600px width.

My gm version:

$ gm -version
GraphicsMagick 1.4 snapshot-20151212 Q8 http://www.GraphicsMagick.org/
Copyright (C) 2002-2015 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                 no
  Ghostscript (Library)    no
  JBIG                     no
  JPEG-2000                no
  JPEG                     yes
  Little CMS               yes
  Loadable Modules         no
  OpenMP                   yes (201107)
  PNG                      yes
  TIFF                     no
  TRIO                     no
  UMEM                     no
  WebP                     yes
  WMF                      no
  X11                      no
  XML                      yes
  ZLIB                     yes

Host type: x86_64-unknown-linux-gnu

Configured using the command:
  ./configure  '--prefix=/opt/WP/common.libs' '--without-tiff' '--without-ttf' '--with-x=no' 'LDFLAGS=-L/opt/WP/common.libs/lib' 'CPPFLAGS=-I/opt/WP/common.libs/include'

Final Build Parameters:
  CC       = gcc -std=gnu99
  CFLAGS   = -fopenmp -g -O2 -Wall -pthread
  CPPFLAGS = -I/opt/WP/common.libs/include -I/usr/include/libxml2
  CXX      = g++
  CXXFLAGS = -pthread
  LDFLAGS  = -L/opt/WP/common.libs/lib
  LIBS     = -lwebp -llcms2 -ljpeg -lpng16 -llzma -lbz2 -lxml2 -lz -lm -lgomp -lpthread

Related

Bugs: #356

Discussion

  • Przemysław Sobala

    Przemysław Sobala - 2016-03-02

    Strange things happen when I use C++ API:
    image.resize(Geometry(600,0)) produces 600x212 image while image.resize(Geometry(600,212)) produces 599x212 image.

     

    • Bob Friesenhahn

      Bob Friesenhahn - 2016-03-02

      On Wed, 2 Mar 2016, "Przemysław Sobala" wrote:

      Strange things happen when I use C++ API: image.resize(Geometry(600,0)) produces 600x212 image while
      image.resize(Geometry(600,212)) produces 599x212 image.

      Please read the documentation. The specified size is a maximum limit
      and by default the original aspect ratio is preserved.

      The resize geometry in the gm utility is different than in Magick++.
      In Magick++ there are fewer geometry "features". Please see the
      documentation for Geometry in Magick++. I think that it is pretty
      well specified.

      Bob

      --
      Bob Friesenhahn
      bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
      GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

       

  • Bob Friesenhahn

    Bob Friesenhahn - 2016-03-02

    On Wed, 2 Mar 2016, Przemysław Sobala wrote:

    [bugs:#356] Wrong output width calculation

    Status: open Group: v1.0_(example) Created: Wed Mar 02, 2016 03:45 PM UTC by Przemysław Sobala Last Updated: Wed Mar 02, 2016
    03:45 PM UTC Owner: nobody

    I came across a weird situation:

    $ gm convert http://i.wp.pl/a/i/tsw/webby_conf.png -resize 600x /tmp/tmp.jpg

    produces 599x212 image:

    There was previously a bug report regarding this. The reason is
    because GraphicsMagick preserves the aspect ratio of the original
    image.

    Bob

    --
    Bob Friesenhahn
    bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
    GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

     

    Related

    Bugs: #356

  • Przemysław Sobala

    Przemysław Sobala - 2016-03-02

    There was previously a bug report regarding this. The reason is
    because GraphicsMagick preserves the aspect ratio of the original
    image.

    Original image:
    260x92 = 2,82608695652
    Ouput image:
    599x212 = 2,82547169811
    I don't call it 'preserved'.
    I would suspect GraphicsMagick, after supplying only the width, to do something like:
    outHeight = round(92 / 260 * 600) = 212

     

    Last edit: Przemysław Sobala 2016-03-02

  • Przemysław Sobala

    Przemysław Sobala - 2016-03-02

    Another question regarding C++ API:
    image.resize(Geometry(600,600)) produces 600x212
    image.resize(Geometry(600,212)) produces 599x212
    image.resize(Geometry(600,0)) produces 600x212
    Where does this inconsistency come from?

     

    • Bob Friesenhahn

      Bob Friesenhahn - 2016-03-02

      On Wed, 2 Mar 2016, "Przemysław Sobala" wrote:

      Another question regarding C++ API: image.resize(Geometry(600,600)) produces 600x212 image.resize(Geometry(600,212)) produces
      599x212 image.resize(Geometry(600,0)) produces 600x212 Where does this inconsistency come from?

      Geometry(600,0) is equivalent to Geometry(600,600) so the width of the
      bounding box is larger.

      Bob

      --
      Bob Friesenhahn
      bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
      GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

       

  • Przemysław Sobala

    Przemysław Sobala - 2016-03-02

    OK, but I still don't understand why does Geometry(600,600) give a valid size of 600x212 when Geometry(600,212) give 599x212 (just like 600x212 was invalid - wrong aspect).
    I can handle this by turning off keeping aspect in Geometry and calculate output height from:
    outHeight = outWidth / inAspect, but it should be a default behaviour.

    And returning back to gm utility, to quote documentation:

    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.

    From the user view, if I set a width of 600 and leave height unspecified I can assume that the output image would have a width of 600 (not 599).

     

    • Bob Friesenhahn

      Bob Friesenhahn - 2016-03-02

      On Wed, 2 Mar 2016, "Przemysław Sobala" wrote:

      And returning back to gm utility, to quote documentation:

        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.

      From the user view, if I set a width of 600 and leave height unspecified I can assume that the output image would have a width of
      600 (not 599).

      I agree that this would be the user's expectation. The user may
      expect the value they specify to take priority over preserving the
      aspect ratio. Currently the aspect ratio seems to have priority.
      Remember that the unit of dimension is in pixels.

      The current math may be found in the function
      GetMagickGeometry() in magick/utility.c.

      I am at work right now and there are other outstanding issues which
      might keep me from looking at this for weeks. Please take a look at
      the existing code and suggest a change which meets the documented
      requirements.

      Bob

      --
      Bob Friesenhahn
      bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
      GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

       

  • Przemysław Sobala

    Przemysław Sobala - 2016-03-17

    One more question about decoder hinting: Why does image size increses sometimes after hinting:

    $ gm convert -size 175x175 -verbose http://media.abczdrowie.pl/files/a3/35/a335927eb257bd3b48848784ca8c1070.jpg 175x175 /tmp/tmp.jpg
//media.abczdrowie.pl/files/a3/35/a335927eb257bd3b48848784ca8c1070.jpg=>/tmp/gmoXnXR2 JPEG 104x150=>208x300+0+0 DirectClass 8-bit 17.5Ki 0.000u 0:01
//media.abczdrowie.pl/files/a3/35/a335927eb257bd3b48848784ca8c1070.jpg=>175x175 JPEG 104x150=>208x300+0+0 DirectClass 8-bit 20.0Ki 0.000u 0:01

    And the output has 208x300 but I would expect it fits inside a 175x175 rectangle

     

    • Bob Friesenhahn

      Bob Friesenhahn - 2016-03-17

      On Thu, 17 Mar 2016, "Przemysław Sobala" wrote:

      One more question about decoder hinting: Why does image size increses sometimes after hinting:

      $ gm convert -size 175x175 -verbose http://media.abczdrowie.pl/files/a3/35/a335927eb257bd3b48848784ca8c1070.jpg 175x175 /tmp/tmp.jpg
      //media.abczdrowie.pl/files/a3/35/a335927eb257bd3b48848784ca8c1070.jpg=>/tmp/gmoXnXR2 JPEG 104x150=>208x300+0+0 DirectClass 8-bit 17.5Ki 0.000u 0:01
      //media.abczdrowie.pl/files/a3/35/a335927eb257bd3b48848784ca8c1070.jpg=>175x175 JPEG 104x150=>208x300+0+0 DirectClass 8-bit 20.0Ki 0.000u 0:01

      And the output has 208x300 but I would expect it fits inside a 175x175 rectangle

      When used with JPEG, the size hint causes the JPEG library to return
      the next larger resolution it supports which is no smaller than the
      size specified (if it can), otherwise it returns what it has. The
      effect is the opposite of GraphicsMagick -resize, which tries to fit
      the image into the resize geometry (i.e. "no larger than" rather than
      "larger than").

      Bob

      --
      Bob Friesenhahn
      bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
      GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

       

Log in to post a comment.

MongoDB Logo MongoDB