Page 1 of 1

compare exits with a non-zero exit code when no error

Posted: 2013-07-10T13:42:02-07:00
by Hubbitus
Please see report from one of our Fedora users: https://bugzilla.redhat.com/show_bug.cgi?id=981944

Re: compare exits with a non-zero exit code when no error

Posted: 2013-07-10T13:46:31-07:00
by fmw42
It works fine if you specify a metric in IM 6.8.6.4 Q16 Mac OSX

compare rose: rose: null:
returns nothing

compare -metric rmse rose: rose: null:
0 (0)

I do not know if there is supposed to be a default metric or not. I always specify one (mostly rmse).

Re: compare exits with a non-zero exit code when no error

Posted: 2013-07-10T14:04:19-07:00
by magick
Have the user add -metric RMSE to the command line until we can get a patch for the default metric, normalized cross correlation distortion. If two images are identical, -metric RMSE returns 0 as expected.

Re: compare exits with a non-zero exit code when no error

Posted: 2013-07-10T14:05:17-07:00
by fmw42
A perfect match for -metric ncc is 1 and not zero. If the user wants that default, then just add -metric ncc until the issue is resolved

see http://www.imagemagick.org/Usage/compare/#statistics

Re: compare exits with a non-zero exit code when no error

Posted: 2013-07-15T11:42:17-07:00
by Hubbitus
Thank you.
I have repost you answer as workaround and wait fix in one of update.

Re: compare exits with a non-zero exit code when no error

Posted: 2013-07-15T13:16:53-07:00
by TomH
Hi. I'm the original reporter of this issue, and the test case I gave in my bug was actually a simplified version of the real code. The actual inspiration for the report was this code:

https://github.com/mapbox/tilelive-mapn ... ert.js#L22

which is part of the test suite for some software I was packaging.

It runs the compare tool (with a metric switch) to compare two images, and then first checks the exit code (to see if the tool worked) and then if that is zero is looks at the metric that was output to see if the two images matched.

The metric in use was PSNR and in the case I was dealing with the result was "inf" which is treated as a match, except that the new exit code of 1 was being treated as a failure. If the change in exit code is expected then that's fine, but I'll need to pass that information on to the authors of the test suite.