OpenCV 图像拼接 优化

前面一篇文件 https://blog.csdn.net/zhanggqianglovec/article/details/103344658 讲述了如果将多个影像拼接为一个大的影像，本文将讲述 一些上面工具在使用过程中的问题及其优化 1. 问题出现： 首先直接说一下工具上的缺陷： 1.1 该工具依赖的是 x86库，包括opencv 2.4.3 ，cholmod 1.6.0 都是32位的，32和64都会影响工具在处理影像时的性能，比如在处理索尼相机的照片时，分辨率是 6000*4000,20多张照片，在处理到一半时会爆出 申请内存失败的情况。(本地环境为 i5处理器四核，16G内存)，处理索尼相机时每张照片都会申请 6000*4000 字节内存块，直接内存爆出内存申请失败。 1.2 该工具迁移到其他机子上会出现不兼容的问题，应为opencv 底层设计到 GPU，CPU等指令，所以在其他机子上 运行，稍微大一点的图片 都会爆出 内存申请失败的问题。 2. 问题定位： 接下来说一下问题的定位 刚开始一直以为是内存的问题，因为在处理小一点的图片时，是没有问题的。在处理所以相机时才会出现；但是当迁移到其他机子上的时候，当地环境是 200G的内存，任然会报出 内存问题，这个就不是内存问题了。然后网上查询，大部分的解决思路 都是 32与64的不兼容。知其然不知其所以然，最后通过仔细的查看爆出来的原因，才豁然大悟，opencv底层调用到了cpu、gpu的指令，然后opencv对底层32/64的支持并不是很好，也就是说 在64环境下调用32 的指令，会出现不兼容的问题，从而导致频繁的爆出内存问题，到此为止，已经定位的差不多了，爆出内存问题只是表象，底层是msvcp.dll/msvcr.dll的执行。 3. 解决之道： 既然问题已经定位到，那么解决之道又是什么，毫无疑问：从底层实现对64的支持，不依赖32位的相关东西。说白了就一句话：重新编译mosaic的所有依赖库，全部换为 64版本 应该就能解决问题。 4. OpenCV 2.4.9 64位的编译 4.1 OpenCV下载： Opencv库的编译相对来说简单，通过Cmake直接可编译，问题是Opencv的源码获取比较麻烦，通过github获取，在git下载过程中时常会出现git下载失败，原因是github连接到了外网，会有网路断开等情况，所以通过github上查找 opencv来下载 还是比较麻烦的，需要多试几次。好在opencv2.4.9 有可执行程序，直接安装 opencv2.4.9 即可安装 他的源码，这个比较好，一下子全部搞定。 4.2 OpenCV工程生成： 在选择 Visual Studio 编译版本的时候需要注意下，Opencv 有区分 X86，X64 和 IA及RAM的编译，这个需要根据自己的情况进行选择，64位环境下一定选择 X64，因为我用的时候 Visual Studio 2010，所以我选择的是 Visual Studio 2010 X64版本，然后点集 Configure，Generate，OpenProject 即可在 Visual Studio 2010中 打开 Opencv 的工程。 4.3 OpenCV 工程编译： OpenCV 工程打开后，找到 ALL_BUILD工程，选择Debug/Release版本，右键build，这个工程只会生成对应的lib库和dll库，并不会生成头文件。 INSTALL工程，该工程首先会执行ALL_BUILD工程，然后复制相关库(lib/dll)到install下的 lib目录和bin目录，复制指定头文件到 include目录，这个工程满足要求，右键 build ，工程执行完毕后会在install目录下生成include目录，bin目录和lib目录。 4.4 Opencv编译完成 5. Cholmod 3.1.0 64位的编译 5.1 Cholmod的获取 网上关于Cholmod的讲解很少，在网上找了很久，找到了SuiteSparse这个产品，SuiteSparse是一个产品套件，里面包含了很多图像相关的处理库，Cholmod只是其中的一部分，而且SuiteSparse目前代码都是针对Linux下的开发，没有针对Windows做 相关的操作，源码目录下不存在cmaketext.txt 文件，不能在windows下直接编译。难道要全部编写cholmod 库代码为windows吗？ 这个可不好。查看本地的cholmod发现，cholmod引用的名字为 cholmod-win，单刀 cholmod有其他组织专门维护了SuiteSparse的windows版本，在我看来官网都没有维护，其他组织维护的可能性不大，抱着试一试的态度，搜了下 cholmod-win这个关键词，一篇博文进入了我的实现 https://blog.csdn.net/ye_shen_wei_mian/article/details/51864239，其提供的连接中找到了 suitesparse-metis-for-windows这个，看样子是对应的windows版本，git上面的地址为 https://github.com/jlblancoc/suitesparse-metis-for-windows/tree/v1.3.0/ ，这个上面提供了CMakeText.txt,欣喜若狂，快速下载编译吧。 但是问题还是一样，git上面下载慢，打开git下载去吧，下班回家。第二天到公司第一眼，发现下载失败，点击继续下载就下载成功了，接下来就是编译。 5.2 Cholmod生成 Cholmod的编译是suitesparse-metis-for-windows 的编译，打开cmake,选择source code和 output路径，同样需要注意Visual Studio版本的确认，点击 configure，发现报错 找不到 lapack，立马头大，又查找看到一片博客：https://www.cnblogs.com/flyinggod/p/8052860.html 看标题就发现，suitesparse-metis-for-windows 自带了 lapack，所以此处只需要 在 Lapack_Dir后面 导入 suitesparse-metis-for-windows 目录下的Lapack目录即可，点击configure，gernate，openproject ，suitesparse-metis-for-windows 工程成功生成。 5.3 Cholmod编译 此处类似 OpenCV 的编译，编译 Build-ALL 和 Install ，对应的头文件和lib库，dll库都已生成

6. Mosaic 相关配置的修改 接下来就是Mosaic工程的整合，无非是 头文件的导入，Lib对应库目录的导入，在Lib库目下发现 ***.lib中有些库和 原来工程的lib库不匹配，无奈只能注释掉。 6.1 blas库导入： 编译代码 发现dtrsv_，dgemv_，dtrsm_，dgemm_，dsyrk_，dger_，dscal_ 这些接口函数不认识，查看代码 发些这个这些接口没有依赖进来，那么到底是那个库没依赖进来，百度之，发现是 libblas.lib没有包含进来，libblas库是一个线性代数库，原来不知道。同样的，原来的libblas.lib 这个库肯定是用不了，只能找64位的，在 suitesparse-metis-for-windows 下面发现了libblas.lib ，suitesparse-metis-for-windows 已经为你想到了一切，所以提前就给你准备好了。后来才发现，上面的爆出来的那些找不到的接口，后有宏定义的，宏的前缀已经说明了一切，比如：#define BLAS_ZTRSV ztrsv ，细心点就能发现是 Blas库的接口。 再次配置vc的lib目录编译，发现原来的接口连接错误找不到了，又出现了新的 dpotrf 和zpotrf找不到 6.2 lapack库导入： 百度之发现是lapack库的接口，想起来前面在配置cmake的时候用过一次lapack，所以在 suitesparse-metis-for-windows 下查找lapack，在下面找到了 lib库，在vc中再次配置，右键编译，工程编译成功，谢天谢地，接下来准备测试。 7. 运行 1. 在Release目录下 复制opencv的动态依赖库，lapack动态依赖库，blas依赖库，cholmod只生成了静态库，所以不需要复制，直接运行，程序成功执行。 2. 运行小数据，成功执行 3. 运行索尼数据，内存耗尽，直接死机，到此位置，Mosaic 64位大功告成，耗时一天。

8. 此处保存几个连接地址，方便以后学习或者其他学习这参考 SuiteSparse 官网提供的下载地址： http://faculty.cse.tamu.edu/davis/SuiteSparse/ Cholmod-Scikit-Sparse-Windows github地址： https://github.com/jlblancoc/suitesparse-metis-for-windows https://github.com/xmlyqing00/Cholmod-Scikit-Sparse-Windows SuiteSparse github地址： https://github.com/tzuriv/SuiteSparseExtra/tree/master/SuiteSparse https://github.com/DrTimothyAldenDavis/SuiteSparse