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

Question

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

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

任何人都可以向我提供有关其工作原理的更多信息吗？例如:

Does it compare using colormodel or does it image segmentation to achieve its task?

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

但这是如何做到的？请解释。

Answer 1

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

理论

这种缓慢是由于子图像搜索的设计方式造成的:它执行 compare位于 的小图像每较大图像中的可能位置(该区域当前覆盖在该位置)。

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

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

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

结果-0.ext :此图像应显示(最佳)匹配位置。

结果-1.ext :这应该是潜在的左上角位置的“热图”。

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

“ map ”图像具有较小的尺寸，因为它仅包含子图像的位置或每个潜在的左上角，同时完全适合较大的图像。其尺寸为:

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

第一个图像 sub-image.jpg(左侧)是 JPEG，在颜色编码中会有一些损失，因此子图像不可能创建 精确 比赛。

第二张图片 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(显示潜在匹配的“热图”)在右侧。

结论:结果不正确？漏洞？

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

该命令应该返回 @ 20,5而不是 @ 40,5 .

resultimage-0.png 应该将红色区域向左移动 20 个像素。

热图 resultimage-1.png 似乎将最佳匹配位置指示为最暗的像素；也许我上面的“像素越亮匹配越好”陈述是错误的，它应该是“像素越暗......”？

我将向 ImageMagick 开发人员提交错误报告，看看他们对此有何评论....

更新

正如 ImageMagick 开发人员 @dlemstra 所建议的，我通过添加 -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 :平均绝对误差(归一化)，平均 channel 误差距离

MEPP :每个像素的平均误差(归一化平均误差，归一化峰值误差)

MSE :平均误差平方， channel 误差平方的平均值

NCC :归一化互相关

PAE :绝对峰值(归一化绝对峰值)

PHASH :感知哈希

PSNR :峰值信噪比

RMSE :均方根(归一化均方根)

一个有趣的(相对较新的)指标是 phash ('感知哈希')。它是唯一一种不需要相同尺寸直接比较图像的方法(没有 -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 指标感到有些惊讶。这可能需要进一步调查......)

以下结果图像看起来基本正确:

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 建议使用的):