SfM问题总结

1、20140831. 好久没有动过自己的SfM代码了，今天改进了一个地方，那就是RO的代码里之前没有判断两视图间匹配个数，导致有时两视图间根本没有任何有效匹配时，还去做RO，结果就导致程序直接报错退出了，现在改为至少得有3个有效匹配，采取做RO；
2、TempleRing的测试图中第1幅图的EO和第31幅图的EO基本一致，当把第31幅图考虑进来一起做SfM时，导致重建结果不对，一旦把第31幅图排除出去，SfM的结果就正确了，看来之前的SfM代码在这一块还需要改进；
3、之前我的SfM流程貌似有一个比较严重的问题，那就是貌似有效匹配图越多，好像找到的有效tracks越少，我在想这会不会是因为两视图间一一映射的约束太强，容易把还不错的tracks给误杀掉，总之看起来明显是有需要改进的地方。

科研心态

    在外面待的这一年独处的时间居多，因此有很多自省的时间，可以想一想以前从未想过的问题，比方说自己当初为什么要选择科研这条道路，这个问题的答案当初是很清晰明确的，就是兴趣，我真心实意的想把玩一些东西，并想把它们彻彻底底的弄清楚，但是后来渐渐地目标似乎变成了撰写paper，为了paper而paper，因为毕竟毕业的门槛高高的在那摆着，如此一来当初单纯的心态也随之发生了改变，常常会患得患失，很功利也很投机主义，我想要真正做出深入的研究成果还是要回归那种interest driven的心态，从最原始质朴的求知欲望出发把玩感兴趣的东西，管它有没有实际的“价值”呢。

外婆

    上午收到家里消息说外婆于昨晚去世了，因为外婆年事已高，而且最近几年身体一直不好，近期又查出肝癌晚期，所以早有心理准备，但看到消息的那一刻心里还是一惊，缓过神来才意识到外婆是真的离开我们了。
    还记得我出国之前几天去小舅家看望外婆，发现外婆的头发较之前愈发花白，个子也更矮了，整个人微胖，显得憨态可掬，现在想想那可能只是身体不适导致的浮肿，我能感觉到外婆的身体状态不比以前，但当时的精神头还可以，却不曾想半年后的今天外婆就辞世了。
    当时在小舅家待的最后一天晚上大家带着外婆一起去外面的馆子吃饭，吃完饭之后就要启程回株洲了，外婆一个人坐在餐馆的椅子上一边看着我和凤凤一边在抹眼泪，我还笑着安慰外婆说“别哭，这哭什么，我在国外也就待一年，很快就回来了”，外婆抹干了眼泪也笑着对我说“好，好，在外面注意安全”，现在才明白外婆当时就料到了自己可能挺不过这一年，不料那也真的成了我见外婆的最后一面，画面就这样永远的定格在了那一瞬，一个憨憨的小老太太坐在椅子上眼含泪水望着我和凤凤。
    外婆总说我是她的骄傲，我也一定会更努力让她继续以我为傲，真心希望外婆在天国有一块温暖的地方，再无病痛和忧伤，唯有永远的阳光。

Tensor Voting

http://homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/MORDOHAI/tensorvoting.html

使用 CStdioFile 按行读入文件数据

   CStdioFile 是 MFC 封装的 std::ifstream 和 std::ofstream 形成的一个类，可以按行从文件读入数据，使用起来非常的方便，详细使用说明参考 http://msdn.microsoft.com/en-us/library/a499td6y.aspx。
    一个简单的读自定义点云文件（坐标、颜色及法向）的函数范例如下：

void ReadCloudFile(const CString & path, pcl::PointCloud<pcl::PointXYZRGB> & cloud, pcl::PointCloud<pcl::Normal> & normal)
{
cloud.clear();
normal.clear();

CStdioFile file;

if (!file.Open(path, CFile::modeRead))
{
return;
}

CString line;

while (file.ReadString(line))
{
if (line.IsEmpty())
{
continue;
}

double X,Y,Z,nX,nY,nZ;
int R,G,B;

sscanf(line, "%lf;%lf;%lf;%d;%d;%d;%lf;%lf;%lf", &X, &Y, &Z, &R, &G, &B, &nX, &nY, &nZ);

pcl::PointXYZRGB p;
pcl::Normal n;
p.x = X;
p.y = Y;
p.z = Z;
p.r = R;
p.g = G;
p.b = B;
n.normal_x = nX;
n.normal_y = nY;
n.normal_z = nZ;

cloud.push_back(p);
normal.push_back(n);
}

file.Close();
}

Conflict between window macro min max and std::min std::max

    在新建一个新的 MFC 工程并单独添加 PCL 的时候，编译过程出现错误，提示 PCL 的相关文件中的 min 函数的输入参数个数不对，这其实是因为 windows 自己在 <window.h> 头中定义了宏 min 和 max 函数，而 PCL 中使用的 min 和 max 是 stl 中的函数，于是就产生了冲突，在网上找到一篇 microsoft 官方微博提供的关于此问题的一个解决方案：

http://support.microsoft.com/kb/143208

    他的做法是在 Project->Properties->Configuration Properties->C/C++->Preprocessor->Preprocessor Definitions 中添加一个 NOMINMAX 的宏定义，这样的话 windows 自己的宏 min max 函数就不会被定义了，但是这样的做法是导致 MFC 中自己包含的很多确实用到该宏 min max 函数的地方报错，提示 min max 函数没定义，到此该问题的解决貌似成了一个鱼和熊掌不可兼得的情况。
    回到 PCL 用户论坛继续找解决方案，最终找到一个方案，那就是在 stdafx.h 添加完所有 windows 自己头文件后，添加任何 PCL 头文件之前，通过 #undef 宏命令取消 windows 自己宏 min max 函数的定义：

#include "targetver.h"

#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS      // some CString constructors will be explicit

// turns off MFC's hiding of some common and often safely ignored warning messages
#define _AFX_ALL_WARNINGS

#include <afxwin.h>         // MFC core and standard components
#include <afxext.h>         // MFC extensions

#include <afxdisp.h>        // MFC Automation classes

#ifndef _AFX_NO_OLE_SUPPORT
#include <afxdtctl.h>           // MFC support for Internet Explorer 4 Common Controls
#endif
#ifndef _AFX_NO_AFXCMN_SUPPORT
#include <afxcmn.h>             // MFC support for Windows Common Controls
#endif // _AFX_NO_AFXCMN_SUPPORT

#include <afxcontrolbars.h>     // MFC support for ribbons and control bars

#undef max
#undef min
#include <pcl/point_types.h>
#include <pcl/io/io.h>

    这样的话所有的 windows 头还是用自己定义的 min max 函数，而所有 pcl 的库就用的 stl 的 min max 函数，这样做是合理的，因为 pcl 中肯定不会用到 windows 定义的 min max 函数。

PCLVisualizer visualize my own point cloud and normals

    经过一上午的代码整合与调试，终于可以通过 PCLVisualizer 来显示自己的点云和法向场了，效果如下：

    需要注意的一点是在退出该三维显示窗口时最好是直接点叉关闭掉，如果是通过按 q 键来退出窗口的话，貌似显示内循环不会结束，就会导致内存泄露。