Imagemagick: Compare metric AE returns 0 (no fuzz) on differing images

[Galland]

Prerequisites

• [x] I have written a descriptive issue title
• [x] I have verified that I am using the latest version of ImageMagick
• [x] I have searched open and closed issues to ensure it has not already been reported

Description

Comparing two images that are very similar, but where the bottom rows differ in their red channel by 1 (i.e. one image has these pixels with red = 1, the other is red=2) with metric AE and no fuzz should return 1696 (the actual absolute difference) but returns 0. However, the diff image does have the pixels that differ tinted red.

Steps to Reproduce

Get files attached below in this report and run this command:
compare -metric AE -fuzz 0 out_0000_YCbCr_small.png testdec_0000_YCbCr_small.png diff.png

It returns 0, even though 1696 pixels differ. But the diff.png output image does indeed get those pixels tinted red.

System Configuration

• ImageMagick version: 6.9.9-38 Q16 x86_64 2018-03-12

• Environment (Operating system, version and so on): Fedora 28

• Additional information:
  
  

[Galland]

It happens also on the latest version. I believe the culprit is these lines

fuzz=(double) MagickMin(GetPixelChannels(image),
   GetPixelChannels(reconstruct_image))*
   GetFuzzyColorDistance(image,reconstruct_image);

Where the fuzz distance gets multiplied by the number of channels, so that on an RGB image the 0 fuzz from the command line became 0.5 (see here) and now becomes 1.5 so that a difference of 1, as in the report's images is assimilated to being equal.

[Galland]

This is the commit that broke the AE functionality (Nov. 2017): https://github.com/ImageMagick/ImageMagick/commit/60634fd986465b1b6705b1d97b65624c385de590

[Galland]

Said commit was based on a forum discussion. Unfortunately the code was changed in a hurry without taking into account the actual right response in the thread

I would revert AE metric to its original fuzz meaning, where a 0 fuzz means that compare returns 0 if and only if all pixels are exactly equal, so as not to break scripts that have relied for years on this assumption.

[dlemstra]

Thanks for the extensive research but the commits that you are referring to are in the IM7 repository and you are using the IM6 binaries. It turned out to be a mistake in our IM6 code: https://github.com/ImageMagick/ImageMagick6/commit/cfeab2b2b9f3ba9de781a9f1ac7bdf53f820d9a6. After this patch has been applied the result is 1696. This issue will be resolved in the next release of ImageMagick.

[sizmailov]

Hi! We encountered this issue on ubuntu 20.04 with imagemagick installed from repo:

compare --version

Version: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
Copyright: © 1999-2019 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC Modules OpenMP 
Delegates (built-in): bzlib djvu fftw fontconfig freetype jbig jng jpeg lcms lqr ltdl lzma openexr pangocairo png tiff webp wmf x xml zlib

$ compare -metric ae -fuzz 0 1.png 2.png diff12.png
0

(test images are attached below)

I've tried recent built from source version (ImageMagick 7.0.10-43 Q16 x86_64 2020-11-26) and it finds more sensible 3325 different pixels, so bug is apparently fixed.

@dlemstra Linked commit is tagged with 6.x versions starting from 6.9.10-11, but bug is reproducible at least in 6.9.10-23 (installed from ubuntu repo) Is it packaging problem or something?

Would it be possible to provide an update to repo(s)?

1.png 2.png

[jcwinkler]

I confirm exactly the same behaviour on MS Windows and package ImageMagick-6.9.11-43-Q16-x64-dll with the files provided by @sizmailov. The issue does not occur with package ImageMagick-7.0.10-43-Q16-x64-dll (3325 pixel diff).

[dlemstra]

The output is different because ImageMagick 6 does not compare the alpha channel by default compared to ImageMagick 7. To get the same behaviour in ImageMagick 6 you will need to add -channel rgba to the command.

[sizmailov]

Wow, that is surprising since it was not required in older 6.x releases. Just checked, ImageMagick 6.9.7-4 Q16 x86_64 20170114 does _not_ need -channel rgba to find the difference. Anyhow -channel option is savior for 6.9.10.

Thanks!