Question

我正在使用photographic mosaic算法。涉及4个步骤：

整个过程相对简单，但是步骤2涉及将n个图像与m个段进行比较，其中n>＆gt;米这是迄今为止最耗时的一步。

以下是我为每个段候选对进行的过程：

确定候选图像是否与段尺寸兼容。如果不是，则假定禁止分配。
使用由Bitmap创建的中间子图片Graphics.DrawImage(Image, Rectangle, Rectangle, GraphicsUnit)，我将位图数据转换为原始图像片段的红色，绿色和蓝色int[,]矩阵。我使用LockBits()方法而不是GetPixel()方法，因为它的速度要快得多。为了减少计算时间，这些矩阵只有大约3x3或5x5，而不是原始段的完整尺寸。
我对候选图像执行相同的处理，创建红色，绿色和蓝色3x3或5x5 int[,]矩阵。
从cost = 0开始，我将源和候选图像片段的红色，绿色和蓝色值的差异大小添加到成本中。这些绝对差异的总和是分配成本。

实际上，我使用所有16 RotateFlipType个变换检查每个候选图像，因此需要进行16 * n * m个比较，其中n =分段数，m =放置区域的数量。

我想知道我是否可以对每个图像进行FFT而不是比较每个像素，我只比较低频分量，因为高频分量不会显着影响输出。另一方面，很多开销，例如获取子图像并将它们转换为矩阵仍然存在，而我的直觉告诉我，频谱比较将比25 int值的基本比较慢。

Answer 1

起初我会通过

快速加速

为每张图片创建信息，例如：

平均颜色，r / g / b直方图我认为每个通道8或16个点就足够了。您可以添加任何其他信息（最暗/最亮的颜色，......）但它应该是旋转/翻转不变
索引按平均颜色对图像进行排序

仅将R，G，B限制为几位，如4 ...并从中创建单个整数，如
```
col=R+(G<<4)+(B<<8);
```
最后索引排序使用此号码的图像
<强>比较

所以二进制搜索索引排序图像（如果你为每个减少的颜色创建索引表，那么这也将减少到O(1)）并找到平均值接近或相等的图像颜色作为你的细分。

然后从这些匹配中找到与直方图最接近的匹配，然后将所有只对这些图像应用...

直方图比较可以通过相关系数或任何距离或统计偏差来完成......

对于你问题的 FFT 部分，我认为它或多或少已经通过评论回答了。是的，你可以使用它，但我认为这是一个矫枉过正。开销很大，但你可以将图像重新缩放到低分辨率并在其上使用 FFT ，或者只是比较低分辨率图像

<强> [注释]

同样使用 HSV 代替 RGB 可以提高视觉相似度