毕业后文献阅读

1. Massively Parallel Multiview Stereopsis by Surface Normal Diffusion. (finished on 2016.04.11)

ETH的Silvano Galliani等人在2015年发的一篇ICCV文章。这篇文章提出的方法被命名为Gipuma，其最大的创新之处就在于采用了一种非常适合GPU大规模并行处理的diffusion-like propagation scheme，即所谓的red-black (RB) scheme，也就是把全图的像素分为互相包含，互为邻域的红色像素群与黑色像素群，如下图左所示，然后每次要嘛利用相应邻域内的黑色像素参数同时更新所有的红色像素的参数，要嘛就利用相应邻域内的红色像素参数同时更新所有的黑色像素的参数，同一颜色像素的参数更新是完全独立的，因为都是只参考了各自邻域内的另一种颜色像素的参数（此轮迭代中不变化）（邻域形式如下图中和右所示），因此同一颜色像素的参数更新是完全可以并行处理的，可以想见，如果GPU单元个数允许，每次迭代中整幅图像上是有一半的像素在同时进行更新的，计算效率非常的高。

这种red-black scheme是一种用来并行化message-passing type updating schemes的标准方法，也已经被用在了belief propagation上，只可惜我之前一直都没有看到更没有想到这么好的并行策略。

另外Gipuma方法和我的方法不同的地方还有：

一、它采用的support plane model还是通过直接法向量然后推导平面单应的方式来表示的；二、它搜索深度值时有考虑越小的深度值应该搜索的深度间隔越小一点，越大的深度值应该搜索的深度间隔越大一点；

三、采用的匹配代价函数不是NCC，而是那种类似双边滤波的形式；

四、在综合考虑多幅支持图的匹配代价时，使用的是取匹配代价值最小的K个代价值的平均值，我觉得这个不够合理，还不如采用Huber M-estimator的形式呢。

Compile opencv 3.1 with opencv_contrib added and WITH_VTK enabled

先把vtk代码下下来，因为opencv里的三维显示模块viz需要有vtk支持。然后打开cmake进行编译，在默认配置的基础上，我只做了以下更改：
1、check BUILD_EXAMPLES；
2、check BUILD_TESTING；
3、将CMAKE_INSTALL_PREFIX从C盘路径改为F盘下的某个文件夹，这样做的目的是因为CMAKE_INSTALL_PREFIX设置了最后.sln中INSTALL工程要将生成的.lib和.dll文件提取到哪里，而如果设置到C盘的话，则很有可能由于没有访问权限，导致INSTALL失败。不过，其实这里的vtk编译过程最后也不用INSTALL，因为opencv编译的时候需要的是包含VTKConfig.cmake文件的文件夹，并非INSTALL填充的文件夹。
另外一个我后悔没做的更改就是没有uncheck掉BUILD_SHARED_LIBS，导致后续我运行自己的.exe文件时总是需要把vtk的大概40个.dll文件全拷到所在文件夹中，很费事。要是我事先把vtk做成静态库，后续它的函数应该就封装到opencv的某个module的.dll中去了，不用再拷vtk的.dll文件。

编译好vtk之后，再到github上把opencv_contrib代码下下来，之后打开opencv的cmake工程，把OPENCV_EXTRA_MODULES_PATH设置到.../opencv_contrib-master/modules文件夹，把VTK_DIR设置到上述vtk build的文件夹。接着check上BUILD_opencv_viz，另外要注意的是最好是uncheck掉BUILD_opencv_world和BUILD_opencv_contrib_world，因为我发现要是生成这两个库，在VS build的时候经常会报一堆错误，要是不生成这两个库还是使用单个库的话build就不会报错。

配置好之后点击configure顺利通过，但是点击generate的时候报了如下的cmake错误：

CMake Error at /usr/lib/cmake/vtk-7.0/vtkModuleAPI.cmake:120 (message):

Requested modules not available:

 vtkRenderingOpenGL 

Call Stack (most recent call first):

/usr/lib64/cmake/vtk-7.0/VTKConfig.cmake:88 (vtk_module_config) cmake/OpenCVDetectVTK.cmake:6 (find_package) 

CMakeLists.txt:597 (include)

搜索了半天，才在这里找到了解决方案，于是对照着在OpenCVDetectVTK.cmake中做了相应更改之后generate就通过了，之后打开VS去生成各个库即可了。

跑了一下viz三维模块，感觉还是相当不错的。

Compile Ceres and configure it in opencv cmake settings

从ceres官网上下载下来代码后，用cmake gui打开，在默认设置的基础上我只做了如下修改：
1、check MINIGLOG，否则如果没有设置gflags_DIR的话cmake会报错；
2、设置CMAKE_INSTALL_PREFIX到非C盘路径，默认的这个路径是到C盘，如果不改成非C盘路径，那么后续INSTALL的时候有可能由于没有权限而报错。
BUILD_SHARED_LIBS默认就是unchecked，意味着后续将编译生成静态.lib，不会生产.dll，这样后续自己编写的基于ｏｐｅｎｃｖ的可执行程序目录中也就不需要．ｄｌｌ文件了，否则还得把ｃｅｒｅｓ的．ｄｌｌ文件也一并拷到目录中，显得有点麻烦。我的理解是如果是静态．ｌｉｂ，那么ｏｐｅｎｃｖ的哪个模块用到它了，就会把它整个封装过来，后续自己的可执行程序就只管ｏｐｅｎｃｖ的模块的．ｌｉｂ和．ｄｌｌ就行了，不再牵扯到ｃｅｒｅｓ的库。
ｇｅｎｅｒａｔｅ后，打开．ｓｌｎ依次点击ｂｕｉｌｄ　ＡＬＬ＿ＢＵＩＬＤ和ＩＮＳＴＡＬＬ。
然后再打开ｏｐｅｎｃｖ的ｃｍａｋｅ配置，在ｕｎｇｒｏｕｐｅｄ的里面找到Ｃｅｒｅｓ＿ＤＩＲ，设置到上面ｉｎｓｔａｌｌ ceres的那个文件夹中的ＣＭａｋｅ文件夹，里面有CeresConfig.cmake文件，点击configure后会提示EIGEN_INCLUDE_DIR NOTFOUND，这时再把这个路径设置到eigen库的第一级路径即可，再次点击configure就行了。

opencv_nonfree module is moved to opencv_contrib since opencv 3.0

   本来想着剩下的工作只是为工程配置好路径以及要使用的.lib文件即可，结果编译报错，说是在opencv2下面找不到opencv_nonfree.hpp，打开文件夹一看确实没有，上网一搜才知道opencv3.0之后nonfree模块整个被挪到contrib模块了，而且默认的opencv代码下载里还没有contrib模块，得去github上面下载下来，然后在CMake里为OPENCV/OPENCV_EXTRA_MODULES_PATH设置好contrib代码路径再重新整个编译一遍才行，这样也就算了，关键是sift和surf的使用方法发生了变化，这意味着即使设置好了库，后续也需要更新很多我自己的代码才行，想想头都大了，于是想着回到2.4.8版本，结果在windows 10(64-bit)下用vs2015(x86)CMake进行configure都会报错，提示什么
CMake Warning (dev) at apps/haartraining/CMakeLists.txt:37 (add_library):
Policy CMP0038 is not set: Targets may not link directly to themselves.
Run "cmake --help-policy CMP0038" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.

Target "opencv_haartraining_engine" links to itself.
This warning is for project developers. Use -Wno-dev to suppress it.
   然后强行configure后，点击generate，又报错。。。：
CMake Error: install(EXPORT "OpenCVModules" ...) includes target "opencv_world" which requires target "zlib" that is not in the export set.
   虽然能生成.sln，但是总感觉即使最终生成了库，其中也会有问题。
所以又想着是不是2.4.8版本太低了，于是下载了2015年才发布的2.4.11，即最后的2.4版本，结果cmake的时候configure确实没问题，可generate的时候还是出现了上述错误，而且搜索相关问题都没有发现解决方案，挺郁闷的，到现在为止还是决定把3.1的contrib模块整过来算了，后续慢慢改自己的调用吧。

Problem cannot open source file "SDKDDKVer.h" solved

   打开之前vs2010的工程，点击build，结果遇到了在targetver.h文件中找不到SDKDDKVer.h的问题，原因就在于之前工程的configuration properties->VC++ Directories->Include Directories中改成了
$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSdkDir)include;$(FrameworkSDKDir)\include;$(ProjectDir);
   添加了$(ProjectDir)，结果就因为这一改，这一栏属性没有更新至vs2015的默认设置，提供了错误的include路径，自然就找不到SDKDDKVer.h文件了，因此我在vs2015中新建了一个工程，看了下默认的路径设置，其实只要选择<inherit from parent or project defaults>就可以恢复到正确路径了：
$(VC_IncludePath);$(WindowsSDK_IncludePath);

problem solved

Establish git source control for Visual Studio 2015 project

   之前的工程目录本来就是一个repository，里面有个.git的隐藏文件夹，其中记录了版本控制的信息，因此用vs2015打开工程以后直接在各个文件前面就会显示红勾，表示处于checked状态，但是还不能进行commit等操作，因为我在安装vs2015的时候并没有安装git source control，因此还需要安装git。于IDE右侧Team Explorer中直接会出现install git的按钮，点击后会跳转至git的网站，下载相应版本并完成安装，之后就可以在vs2015 IDE中直接享受git source control了。

Compile opencv 3.1 from sources on windows 10 (64-bit)

1、下载opencv 3.1，并解压至F盘，这时F盘中会有一个opencv的文件夹；
2、下载最新的CMake（我当前使用的是CMake 3.4.3）并安装；
3、下载最新的stable release Eigen库（我当前使用的是Eigen 3.2.8），并解压，于F:\opencv文件夹中新建一个dep文件夹，并把解压得到的eigen-eigen-07105f7124f9文件夹拷贝至dep文件夹；
4、下载最新的stable release TBB库（我当前使用的是TBB 4.4 update 3），并同样解压至dep文件夹中，这里要注意不要下载source代码，而是下载windows* OS库，因为里面有预先编译好的tbb_debug.lib和tbb.lib，而这两个.lib文件是后续编译opencv时需要用到的；
5、于opencv文件夹中新建一个mybuild文件夹，然后打开CMake程序，并选择
source code路径为：F:/opencv/sources
build binaries路径为：F:/opencv/mybuild
之后勾选Grouped复选框，接着点击Configure按钮，在弹出的对话框中选择编译器为Visual Studio 14 2015，即32位版本；
6、在默认的CMake设置基础上，我做了如下改动：

• 在WITH group中uncheck WITH_CUDA；check WITH_OPENGL, WITH_TBB；
• 在BUILD group中check BUILD_EXAMPLES,BUILD_opencv_world；
• 在Ungrouped Entries中为EIGEN_INCLUDE_PATH设置为F:/opencv/dep/eigen-eigen-07105f7124f9；为TBB_INCLUDE_DIRS设置为F:/opencv/dep/tbb44_20160128oss/include

7、再次点击Configure按钮后，需要为TBB_LIB_DIR指定路径，设置其为F:/opencv/dep/tbb44_20160128oss/lib/ia32/vc14，首先由于前面选择的编译器为win32，因此这里选择ia32文件夹而非intel64，另外，这个路径一定要进一步选择至vc14，这一点至关重要，因为要是只设置到ia32文件夹的话，后续在编译opencv库的时候，会出现LNK1104 cannot open file 'tbb_debug.lib'错误，这是因为此时CMake generate的.sln中有多个工程依赖于外部文件_tbb_windef.h，里面有语句#pragma comment(lib, "tbb_debug.lib")，即链接时需要用到tbb_debug.lib，而如果没有提供到vc14文件夹的路径，那么这些工程的Linker->General->Additional Library Directories中就不会给出正确的包含tbb_debug.lib的文件路径。当然如果由于疏忽，在CMake时没有设置对路径也没有太大关系，因为可以手动为每个相关的工程在Linker->General->Additional Library Directories中重新把路径设置到vc14文件夹，只不过麻烦点，需要每个工程都更改一遍，如果CMake时就设置对路径就省去了这些麻烦。完事之后再次点击Configure应该就没问题了，接着再点击Generate生成OpenCV.sln；

8、双击打开OpenCV.sln，置于debug和win32，然后在菜单栏点击Build ALL_BUILD工程（记住不是Build Solution），或者右键ALL_BUILD工程选择Build；完事之后右键INSTALL工程选择Build；之后切换至release模式重复上述两次Build，最终编译得到的所有.dll和.lib文件以及.h头文件就位于F:\opencv\mybuild\install文件夹中。

The end.

关于加班

  晚十二点开完会回到宿舍，心里不禁想，LD真的非得把会安排在晚上开吗？就不能安排在白天工作时间？LD白天有那么忙？会后简单的一句“不好意思，占用大家休息时间了”就算抚慰人心了。

  国外的经历让我也逐渐开始赞同一种看法：只有那些不会管理时间，工作效率低下的人才需要靠加班来完成工作，我也逐渐开始学习如何管理自己的工作时间，如何抓重点，如何按照优先级来完成手头的工作，以提高工作效率，这样自己在工作之余可以有时间放松，或者是享受兴趣爱好，亦或是读书学习。但是这一套思路想要得到落实得有个前提条件，那就是时间得是由自己安排，那么问题来了，当LD的时间安排驾临于一切之上的时候，这一套思路就然并卵了。

  莫非这次又是我自己理想主义了？我想知道国外的那种工作时间制度是怎么贯彻执行的，文化认知？法律保障？个人抗争？