ImageMagick的'-subimage-search'操作如何工作？

Question

我在我的应用程序中使用了ImageMagick.我使用ImageMagick将compare命令与-subimage-search选项进行比较.

但是关于-subimage-search工作原理的文献很少.

any anyon能否向我提供有关其工作原理的更多信息？例如:

是使用colormodel进行比较还是进行图像分割以实现其任务？

我现在所知道的是它在第一个图像中搜索第二个图像.

但是如何做到这一点？请解释.

Answer 1

警告:进行子图像搜索很慢 - 甚至非常慢.

理论

这种缓慢是由于子图像搜索的设计工作原理:它在较大图像compare中的每个可能位置执行一个小图像(当前它覆盖在该位置的那个区域).

使用的基本命令-subimage-search是:

compare -subimage-search largeimage.ext subimage.ext resultimage.ext

作为这个命令的结果,你应该得到一个,但两个图像:

• results-0.ext:此图像应显示(最佳)匹配位置.
• results-1.ext:这应该是潜在左上角位置的"热图".

第二个图像(位置图)显示子图像在相应位置的匹配程度:像素越亮,匹配越好.

"地图"图像具有较小的尺寸,因为它仅包含子图像的位置或每个潜在的左上角,同时完全适合较大的图像.它的尺寸是:

width  = width_of_largeimage  - width_of_subimage  + 1
height = height_of_largeimage - height_of_subimage + 1

搜索本身是基于颜色矢量的差异进行的.因此,它应该导致相当准确的颜色比较.

为了提高搜索效率和速度,您可以遵循以下策略计划:

1. 首先,将子图像的非常小的子图像与较大的图像进行比较.这应该更快找到不同的可能位置.
2. 然后使用步骤1的结果在每个先前发现的潜在位置进行差异比较,以获得更准确的匹配.

实际例子

让我们先创建两个不同的图像:

convert rose: subimage.jpg

convert rose: -mattecolor blue -frame 20x5 largeimage.png

作为JPEG 的第一个图像sub-image.jpg(左侧)在颜色编码中会有一些损失,因此子图像不可能创建完全匹配.

第二个图像的主要区别,largeimage.png(右侧),将是主要部分周围的蓝色框架:

现在计时 - compare命令:

time compare -subimage-search largeimage.png  subimage.jpg  resultimage.png
 @ 40,5
 real  0m17.092s
 user  0m17.015s
 sys   0m0.027s

结果如下:

• resultimage-0.png(显示最佳匹配位置)在左侧;
• resultimage-1.png(显示潜在匹配的"热图")在右侧.

结论:结果不正确？错误？

查看生成的图像,并了解两个图像是如何构建的,在我看来,结果是不正确的:

1. 该命令应该返回@ 20,5而不是@ 40,5.
2. 该resultimage-0.png应该有20个像素向左移动的红色区域.
3. 热图,resultimage-1.png似乎表明最佳匹配位置是最暗的像素; 也许我对上面的"像素越亮越匹配"的说法错了,它应该是"像素越暗......".

我将向ImageMagick开发人员提交一份错误报告,看看他们对此有何看法......

更新

正如ImageMagick开发人员@dlemstra所建议的那样,我测试了-metric为subimage-search 添加操作.该操作返回表示匹配接近程度的数值.有各种可用的指标,可以列出

convert -list metric

这将在我的笔记本上返回以下列表(运行ImageMagick v6.9.0-0 Q16 x86_64):

AE Fuzz MAE MEPP MSE NCC PAE PHASH PSNR RMSE

这些缩写的含义是:

• AE:绝对错误计数,不同像素数(-fuzz受影响)
• Fuzz :平均色距
• MAE :平均绝对误差(标准化),平均通道误差距离
• MEPP :每像素平均误差(归一化平均误差,归一化峰值误差)
• MSE :平均误差平方,通道误差平方的平均值
• NCC :归一化互相关
• PAE :峰值绝对值(标准化峰值绝对值)
• PHASH :感知哈希
• PSNR :峰值信噪比
• RMSE :均方根(归一化均方根)

一个有趣的(和相对较新的)度量标准是phash('感知散列').它是唯一一个不需要相同尺寸直接比较图像的(没有-subimage-search选项).在命令行和编程上,通常是最好的"度量"来缩小看起来相似的图像(或者至少可靠地排除这些看起来非常不同的图像对),而不是真正"看着它们".

我确实使用所有这些指标运行subimage-search,使用如下循环:

for m in $(convert -list metric); do
    echo "METRIC $m";
    compare -metric "$m"            \
            -subimage-search        \
             largeimage.png         \
             sub-image.jpg          \
             resultimage---metric-${m}.png;
    echo;
done 

这是命令输出:

METRIC AE
compare: images too dissimilar `largeimage.png' @ error/compare.c/CompareImageCommand/976.

METRIC Fuzz
1769.16 (0.0269957) @ 20,5

METRIC MAE
1271.96 (0.0194089) @ 20,5

METRIC MEPP
compare: images too dissimilar `largeimage.png' @ error/compare.c/CompareImageCommand/976.

METRIC MSE
47.7599 (0.000728769) @ 20,5

METRIC NCC
0.132653 @ 40,5

METRIC PAE
12850 (0.196078) @ 20,5

METRIC PHASH
compare: images too dissimilar `largeimage.png' @ error/compare.c/CompareImageCommand/976.

METRIC PSNR
compare: images too dissimilar `largeimage.png' @ error/compare.c/CompareImageCommand/976.

METRIC RMSE
1769.16 (0.0269957) @ 20,5

因此,以下度量标准设置根本不起作用-subimage-search,如"图像太不相似"消息所示:

PSNR,PHASH,MEPP,AE

(我实际上有点惊讶,失败的指标包括PHASH.这可能需要进一步调查......)

以下resultimages看起来很正确:

1. resultimage---metric-RMSE.png
2. resultimage---metric-FUZZ.png
3. resultimage---metric-MAE.png
4. resultimage---metric-MSE.png
5. resultimage---metric-PAE.png

下面的resultimages看起来与我上面第一次运行时看起来不一样,没有-metric要求结果:

• resultimage---metric-NCC.png(也返回相同的错误坐标@ 40,5)

以下是-metric RMSE(Dirk Lemstra建议使用的)两个结果图像: