#387 resize method is off by a few pixels

[Peter Frivalszky]

This "bug" seems kind of random to me. Here are all the details I know.

• I usually convert JPEGs using GM
• I usually use the -size "WWWWxHHHH" option for decoding my input files
• But that doesn't seem to affect the probability of this bug occurring
• Most of the time, if I execute the same command immediately after running it, I get a different result
• Most of the time I use the -resize "WWWWx>" method

I cannot find a common pattern between the occurrences of this bug. Here's a command that produced an image that was 726 pixels wide instead of 727, but when I executed it again right after first try, it did fine.

gm convert path/to/inputfile -colorspace 'RGB' -resize '727x>' -quality 95 +profile '*' path/to/outputfile

In this case, the input file was a 1600x1141 JPEG.

I am running GM on a linux debian server. I execute the commands via PHP exec(). Once I executed the command on a Windows machine with the same GM version, nothing happened. I use GraphicsMagick 1.3.20 2014-08-16 Q8 version in production, but I tested and got the same results in a developer environment using GraphicsMagick 1.3.23 2015-11-07 Q8.

Since I wasn't able to find any bug reports on the internet regarding this very issue, I assume this has to do something with my local hardward/o.s. configuration that I have. I have no idea.

I attached a file with the details of my architecture. I hope that info is helpful.

It is quite hard to reproduce the bug, but I can sometimes reproduce it over and over again under certain circumstances.

I did a verbose run and this is what I got:

The command was this:

gm convert -verbose -size '1504x201' path/to/inputfile -colorspace 'RGB' -resize '1108x>' -quality 95 +profile '*' path/to/outputfile

path/to/inputfile JPEG 6016x804=>1504x201+0+0 DirectClass 8-bit 1.2Mi 0.050u 0:01 path/to/inputfile JPEG 6016x804=>1107x148+0+0 DirectClass 8-bit 0.060u 0:01 path/to/inputfile=>/path/to/outputfile JPG 6016x804=>1107x148+0+0 DirectClass 8-bit 40.0Ki 0.010u 0:01

See? I told GM to resize to 1008 pixels in width, but GM somehow did a resize to 1107 pixels. Sometimes I think it has got to do something with the height of the image. GM has to do some rounding with the numbers, and something goes wrong in there. No idea why or how. Especially because most of the time, when I execute the same command again, it produces the expected (good) result.

Hope I was clear enough, and hope there's something that can be done with this problem!

[Peter Frivalszky]

Correction:

I told GM to resize to 1008 pixels in width
I meant 1108 pixels here, just in case.

[Bob Friesenhahn]

I was expecting to see a complaint similar to bug 356 (https://sourceforge.net/p/graphicsmagick/bugs/356/).In that bug, the user obtains an unexpected size because the feature is described to produce an image with the same aspect ratio which best fits the specified size.

Random seeming results are not good and not something I have seen before.

[Bob Friesenhahn]

Please verify that you are not actually encountering the problem described in bug 356 and perhaps it just feels random to you.

[Peter Frivalszky]

Thanks for the tip. It seems more than likely that it's the same issue with me. I was already suspecting some kind of rounding error. At least I'll be able to do some kind of hotfix for this. It probably just feels random to me, you might be right. Sorry for the duplication!

[Bob Friesenhahn]

Looking at this issue again, I see that the geometry (-resize option) does not include the exclamation mark (!) that is documented to be required in order for -resize to change the image aspect ratio. This means that the command line usage was incorrect.