Legacy ImageMagick Discussions Archive

I get

# small image of triangle (ref.jpg) and large image of triange (test1.jpg)
compare -metric rmse -subimage-search test1.jpg ref.jpg null:
1452.43 (0.0221626) @ 8,0

This is an rmse difference of 2.2%

# small image of triangle (ref.jpg) and large image of arch (test2.jpg)
compare -metric rmse -subimage-search test2.jpg ref.jpg null:
12244.3 (0.186836) @ 4,1

This is a 19% difference


Next, I also tried making the blue transparent in the small image of the triangle and testing against the large image of the triangle.


convert ref.jpg -fuzz 20% -transparent "#00A1E5" ref1.png

compare -metric rmse -subimage-search -dissimilarity-threshold 1 test1.jpg ref1.png null:
38414.9 (0.586174) @ 8,0

This gives a 58% error.

Thus, the transparency is not acting in the way I had suggested. It is contributing to the difference between the images.

In fact, comparing the transparent image to the non-transparent image is showing a similar large error measure of 59%

compare -metric rmse -dissimilarity-threshold 1 ref.jpg ref1.png null:
38428.7 (0.586385)

So the transparency is not causing the blue regions to be ignored as per my suggested enhancement.

fmw42 wrote:1452.43 (0.0221626) @ 8,0

The is an rmse difference of 22%

??? 2.2%!

Did you test a comparison when turning the blue to transparent in both images?

snibgo wrote:

fmw42 wrote:1452.43 (0.0221626) @ 8,0

The is an rmse difference of 22%

??? 2.2%!

Did you test a comparison when turning the blue to transparent in both images?

Thanks for catching my decimal place error. I have fixed it.

No, that was not what I was suggesting IM do.

It would probably works fine because it is using the alpha channel in both images. So it would not matter if the background were blue or transparent. I think when there is alpha, it includes the alpha channel in computing the metric. So it becomes a 4 channel rmse rather than a 3 channel rmse.

That is not what I was suggesting to do. I want any transparent pixel in the reference to be skipped during the metric calculation.


But I tested the transparent reference image with the same original image, but with -alpha set (fully opaque alpha) and got the same kind of result.

Here are two tests:

# same image but one with blue turned transparent
compare -metric rmse ref.jpg ref1.png null:
38428.7 (0.586385)

# both images with blue turned transparent
compare -metric rmse ref1.png ref1.png null:
0 (0)

In the second, all 4 channels are identical. In the first, the rgb channels are the same, but the alpha channels are 0 and 1 for the two images. Thus that difference contributes to the rmse and causes a large difference.

Nonetheless, his two images are too similar -- the one with the triangle and the one with the arch. Even doing as I suggest to skip transparent pixels may not help enough, because there are still sufficient number of white pixels so that the metric may never get smaller than his required 18%.

Now you have changed the second one, to make that incorrect:

fmw42 wrote:# small image of triangle (ref.jpg) and large image of triange (test1.jpg)
compare -metric rmse -subimage-search test1.jpg ref.jpg null:
1452.43 (0.0221626) @ 8,0

The is an rmse difference of 2.2%

# small image of triangle (ref.jpg) and large image of arch (test2.jpg)
compare -metric rmse -subimage-search test2.jpg ref.jpg null:
12244.3 (0.186836) @ 4,1

This is only a 1.9% difference

The percentages should be 2.2% and 18.7%.

snibgo wrote:Now you have changed the second one, to make that incorrect:

The percentages should be 2.2% and 18.7%.

Thanks again. My "eyes" are going blind or my brain is dyslexic.

I have fixed it a second time.

Thanks Fred, Snibgo for your efforts. Really appreciate it !

So what is the conclusion on IM transparency comparison in compare metric ? Is it present or not ?

appu wrote:Thanks Fred, Snibgo for your efforts. Really appreciate it !

So what is the conclusion on IM transparency comparison in compare metric ? Is it present or not ?

To the best that I can tell, the transparency (alpha channel) just acts like a fourth channel, which is compared like all the other channels. Transparency is not acting as a "skip-this-pixel", in my opinion. An enhancement to compare would be needed to do that.

One other possibility might be to work on edge extracted images.


convert ref.jpg -define convolve:scale='!' \
-define morphology:compose=Lighten \
-morphology Convolve 'Sobel:>' ref.png

convert test1.jpg -define convolve:scale='!' \
-define morphology:compose=Lighten \
-morphology Convolve 'Sobel:>' test1.png

convert test2.jpg -define convolve:scale='!' \
-define morphology:compose=Lighten \
-morphology Convolve 'Sobel:>' test2.png

compare -metric rmse -subimage-search -dissimilarity-threshold 1 test1.png ref.png -format "\n" null:
1454.75 (0.0221981) @ 8,0

2.2 % rmse


compare -metric rmse -subimage-search -dissimilarity-threshold 1 test2.png ref.png -format "\n" null:
9511.68 (0.145139) @ 5,2

14.5% rmse

I do not know if that helps your issue or not.

I retract my upthread statement that "compare" currently ignores pixels that are transparent, unless "-alpha off" is used. Although my examples on page 1 suggest that the statement is true, I think they are merely special cases.

However, I don't understand what difficulty is in the problem. I created a blue image.



Then I searched for the small arrow image within the three images: (larger arrow, "arch" and blue).
There is a clear difference between success and failure. These are with horrible JPG files. I suspect the results would be even more distinctive if JPG compression wasn't used.