5

我写了一段需要优化的代码。只是想与社区核对一下，看看该代码是否确实是最佳的。它填满了霍夫变换的累加器。实际上，我只是复制粘贴了 OpenCV 库中的大部分代码。谢谢！

int i,j,n,index;
for (i = 0;i<numrows;i++)
{
    for (j = 0;j<numcols;j++)
    {
            if (img[i*numcols + j] == 100)
        {
            for (n = 300;n<600;n++)
            {   
                index = cvRound(j*tabCos[n] + i * tabSin[n]) + (numrho-1)/2;
                accum[(n+1) * (numrho+2) + index+1]++;
            }
        }
    }
}
4

3 回答 3

2

在一段代码中有一个大而重复的霍夫变换，我也模糊地附上了。这部分代码的维护者一直在std::map为累加器尝试稀疏数组（如果我理解他的介绍正确的话，实际上是一个 C++ 键控单元格索引），并取得了一些成功。

我认为加速与缓存局部性问题有关，它当然取决于数据稀疏。

更新：上面提到的软件旨在服务于许多粒子物理实验，但最初用于试验台项目（即小规模）。当我们认真对待做更大的项目并开始为他们做蒙特卡洛时，即使使用稀疏矩阵，霍夫变换也再次成为一个瓶颈。

到目前为止，我们还没有解决方案，但其中一位同事发现Gandalf包含“快速霍夫变换”，它似乎以类似四叉树的方式评估变换（在 2D 中，大概您在 3D 中使用八叉树）减少工作秩序。我们可能会对此进行实验。

进一步更新：一位同事最终在我们的代码中实现了渐进式概率霍夫变换，目前这似乎是我们所拥有的最快版本。如果您不要求将每个点都分配给一条线，则效果最佳。

于 2010-11-19T19:27:59.037 回答
1

不，这不对。[]通过简单的指针算术来迭代有问题的数组，尽可能多地替换用法。将不变表达式抽象为局部变量。

但是，第一个问题是，您的分析器是否显示此代码是整个应用程序上下文中的瓶颈。如果没有，为什么还要进行微优化呢？

编辑：循环微优化 - 更喜欢第二个，因为不需要数组索引（mult vs add）

int ints[100];
int i;
int *pi;

for (i = 0; i < 100; ++i)
{
  printf("%d", ints[i]);
}

for (pi = ints; pi < ints + 100; ++pi)
{
  printf("%d", *pi);
}
于 2010-11-19T19:23:42.987 回答
0

根据您的应用程序，有很多方法可以优化 Hough 变换，而摆弄低级代码可能是其中的最后一种。我将从随机 HT 或多分辨率 HT 开始，然后是混合方法合并。我认为最好先优化算法。最后一步是使用硬件优化，如 CAD 内存。

于 2010-11-20T13:03:36.067 回答