我正计划实现一个具有 6 个相同型号相机的实时 360° 全景拼接器。
我遇到了来自 OpenCV 的stitching_detailed.cpp 实现。问题是使用我想要的参数将 2 张图像拼接在一起大约需要 1 秒，这相当慢。
因为我的应用程序应该实时运行。我需要能够在大约 100 毫秒内将 6 张图像拼接在一起才能“可接受”。输出分辨率应在 0.2 兆像素左右。因此，我开始在 C++ 中进行自己的实现，几乎基于在stitchig_detailed 上所做的工作。我的目标是在 OpenCV 上尽可能多地使用 CUDA 函数（其中一些甚至没有实现stitching_detailed）。
我一直在仔细研究之前算法所基于的拼接管道，如OpenCV 的图像拼接和论文Automatic Panoramic Image Stitching using Invariant Features中所述。
由于拼接管道过于笼统，为了简化它并加快它的速度，我做了几个假设，我想得到一些反馈以了解它们是否有效：
我将提供给算法的所有图像肯定是全景图像的一部分。所以我不必对此进行额外检查。
6 个摄像头将固定在位置和方向上。因此，我事先知道相机需要拼接到全景照片中的顺序。因此，我可以避免尝试匹配来自不连续的相机的图像。
因为相机将保持静止。执行注册步骤以仅获取一次相机方向矩阵 R 是有效的（作为一种初始化）。之后，我只能为后续帧执行合成块。（再次假设相机保持完全静止）。
我也有以下问题...
我确实可以在我的应用程序之前校准相机并获得每个内在相机参数矩阵 K 及其各自的失真参数。我可以将 K 插入拼接管道，从而避免注册步骤中的 K 计算吗？
相机校准还能带来什么其他东西（如果有的话）？失真校正？
如果我之前关于只执行合成块的假设是正确的......我还能取出它的某些部分吗？我的猜测是，也许接缝查找器应该只运行一次（在算法的初始化中）。
我的申请案例是否需要曝光补偿？（因为相机实际上是相同的）。
任何线索将不胜感激，谢谢！