Question

我在我的应用程序中使用过ImageMagick。我使用ImageMagick使用compare命令和-subimage-search选项比较图像。

但是关于-subimage-search如何运作的文档很少。

能不能向我提供有关其工作原理的更多信息？例如：

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

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

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

Answer 1

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

理论

这种缓慢是由于子图像搜索的设计工作原理：它是在每个可能的位置执行小图像的compare较大的图像（当前在该位置覆盖的区域）。

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

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

作为这个命令的结果，你不应该得到一个，而是两个图像：

results-0.ext ：此图片应显示（最佳）匹配位置。
results-1.ext ：这应该是＆＃34;热图＆＃34;潜在的左上角位置。

第二张图像（位置图）显示子图像在相应位置的匹配程度：像素越亮，匹配越好。

＆＃34;地图＆＃34;图像具有较小的尺寸，因为它仅包含子图像的位置或每个潜在的左上角，同时完全适合较大的图像。其规模如下：

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

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

为了提高搜索效率和速度，您可以遵循这一战略计划：

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

实践例子

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

convert rose: subimage.jpg

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

作为JPEG的第一张图像 sub-image.jpg （左侧）会在颜色编码中产生一些损失，因此子图像不可能创建完全匹配。

第二张图片 largeimage.png （右侧）的主要区别在于主要部分周围的蓝框：

sub-image largeimage

现在计算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 （显示＆＃34;热图和＃34;潜在匹配项）在右侧。

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

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

该命令应该已返回@ 20,5而不是@ 40,5。
resultimage-0.png 应该将红色区域向左移动20个像素。
热图， resultimage-1.png 似乎表示最佳匹配位置为最暗的像素;也许我错了我的上面＆＃34;像素越亮，匹配＆＃34; 语句越好，它应该是＆＃34;像素越暗......＆＃34;

我会向ImageMagick开发者提交一份错误报告，看看他们对此有什么看法......

更新

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

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（＆＃39;感知哈希＆＃39;）。它是唯一一个不需要相同尺寸来直接比较图像的（没有-subimage-search选项）。它通常是最好的指标＆＃39;缩小看起来相似的图像（或至少可靠地排除这些看起来非常不同的图像对），而不是在命令行上以编程方式查看它们＃34;

我确实使用所有这些指标运行了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，因为＆＃34;图像太不相似＆＃34; 消息：

PSNR，PHASH，MEPP，AE

（我实际上有点惊讶，失败的指标包括PHASH。这可能需要进一步调查......）

以下重新整理看起来很正确：

的 resultimage---metric-RMSE.png

的 resultimage---metric-FUZZ.png

的 resultimage---metric-MAE.png

的 resultimage---metric-MSE.png

的 resultimage---metric-PAE.png

以下重新成像看起来与我上面第一次没有要求-metric结果的情况一样不正确：

resultimage---metric-NCC.png （也返回与@ 40,5相同的错误坐标）

以下是-metric RMSE的两个结果图像（Dirk Lemstra建议使用的图像）：

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

1 个答案:

理论

实践例子

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

更新