本片文章算是作為上一篇文章【G2O與多視角點雲全域性配準優化】 的延續。
從上篇文章槓已知，現在目前手頭已經有了配準好的全域性點雲、每塊點雲的變換矩陣以及對應每塊點雲的RGB影像。接下來，自然而然的便是：對全域性點雲重建三維網格，並對重建後的三維網格進行紋理貼圖。
已知：三維模型(三角面片，格式任意)，多視角RGB圖片(紋理)、變換矩陣；求：為三維模型貼上紋理圖。
針對上述待求解紋理，熟悉的小夥伴肯定直到，其實在求解多視角立體匹配的最後一步--表面重建與紋理生成。
接上篇，為完成自己的目的，首先需要重構三角網格，從點雲重建三角網格，與相機、紋理圖片等沒有任何關係，可直接使用pcl中的重建介面或者cgal甚至meshlab等軟體，直接由三維點雲重建三角網格。
在完成重建三角網格之前，還有很重要--但是可以酌情省略的一個關鍵步驟：多視角三維點雲融合！下面繼續使用自己之前所拍攝的8個點雲片段為例進行示例記錄。(注意，此處強調8個點雲片段，並不表示8個視角的點雲，後續說明)。
多視角點雲融合
將多個點雲片段拼接之後，無法避免的存在多個視角下點雲相互重疊的情況。如下圖所示，在重疊區域的點雲疏密程度一般都大於非重疊區域點雲。進行點雲融合的目的一是為了點雲去重，降低點雲資料量；二是為了進一步平滑點雲，提高精度，為後續的其他計算(如測量等)提供高質量的資料。
恰巧，自己對移動最小二乘演算法有一定了解，在pcl中，N年之前【pcl之MLS平滑】和【pcl之MLS演算法計算並統一法向量】也做過一些小測試。在我的印象中，移動最小二乘是這樣工作的：針對深入資料，計算目標點及其鄰域，這些待計算的區域性資料便構成了目標點的緊支域，在緊支域內有某個函式對目標點進行運算，運算的基本規則是依據緊支域內其他點到目標點的權重不同，這裡的某個函式即所謂的緊支函式。緊支函式 + 緊支域 +權重函式構成了移動最小二乘演算法的基本數學概念，所謂移動性則體現在緊支域在允許的空間中“滑動”計算，直至覆蓋所有資料。最小二乘一般針對全域性求最優，而移動最小二乘由於其 “移動性”(緊支)不僅能針對全域性優化求解，而且也具有區域性優化性，更進一步的，針對三維點雲，其能夠提取等值面，結合MC(移動立方體)演算法，實現表面三角網格的重建。
pcl中，關於MLS演算法的例子很多很多，自己之前的兩篇水文也算也有個基本的應用介紹，此處不在過多記錄。在這裡，直接使用如下程式碼：
pcl::PointCloud<pcl::PointXYZRGB> mls_points; //存結果
pcl::search::KdTree<pcl::PointXYZRGB>::Ptr tree(new pcl::search::KdTree<pcl::PointXYZRGB>);
pcl::MovingLeastSquares<pcl::PointXYZRGB, pcl::PointXYZRGB> mls;
mls.setComputeNormals(false);
mls.setInputCloud(res);
mls.setPolynomialOrder(2); //MLS擬合的階數，
mls.setSearchMethod(tree);
mls.setSearchRadius(3);
mls.setUpsamplingMethod(pcl::MovingLeastSquares<pcl::PointXYZRGB, pcl::PointXYZRGB>::UpsamplingMethod::VOXEL_GRID_DILATION);
mls.setDilationIterations(0); //設定VOXEL_GRID_DILATION方法的迭代次數
mls.process(mls_points);注意，上述計算過程中，使用了pcl::MovingLeastSquares::VOXEL_GRID_DILATION方法，按照pcl官方解釋，該方法不僅能夠修復少量點雲空洞，而且能夠對點雲座標進行區域性優化，輸出為全域性疏密程度一樣的點雲，通過設定不同的迭代次數，該方法不僅能夠降取樣，還能上取樣(主要通過迭代次數控制).
將自己的資料放入上述計算過程，點雲融合區域性效果如下：
 |
肉眼可見點雲更加均勻、平滑，同同時資料量從100w+ 降到 10w+.
上述操作，基本滿足了自己下一步的要求。
進一步的，鑑於表面重建並非重點，針對上述結果，這裡直接使用MeshLab軟體中的泊松重建，結果記錄如下：
多視角紋理對映
在這裡，正式引入自己對所謂“多視角”的理解。
首先，多視角與多角度，通常情況下，這兩個概念基本都是在說同一件事情，即從不同方位角拍攝三維模型。但是這其中又隱含兩種不同的 [操作方式]，其一如手持式三維掃描器、SLAM中的狀態估計、甚至搭載攝像機/雷達的自動駕駛汽車等，這些場景下基本都是相機在動，目標不動，即相機繞目標運動；其二 如轉檯式三維掃描器等，這些場景基本都是相機不動，目標動，即目標本身具有運動屬性。所以這裡，有必要對多視角與多角度做進一步的區分，多視角指的是相機的多視角(對呀，相機才具有真實的物理視角、位姿、拍攝角度 巴拉巴拉...)，多角度指的是目標物體的不同角度(對呀，一個物體可以從不同的角度被觀察)。
其次，外參，外參是很重要的一個概念(廢話，還用你說！)，可真的引起其他使用者足夠的重視嗎？未必！ 我們一般常說的外參，其實是帶有主語的，只是我們太習以為常從而把主語省略了。外參---一般指相機的外參，即描述相機的變化。在多視角三維點雲配準中，每個點雲都有一個變化矩陣，該變化矩陣可以稱其為點雲的外參，即描述點雲的變化。至此，至少出現了兩個外參，且這兩個外參所代表的物理意義完全不一樣，但是又有千絲萬縷的聯絡。我們都知道，巨集觀下運動是相互的，則必然點雲的外參和對應相機的外參互逆。
注: 之所以這裡對上述概念做嚴格區分，主要還是因為自己之前對上述所提到的概念沒有真正深入理解，尤其是對外參的理解，導致後期演算法計算出現錯誤；其二還是後續庫、框架等對上述有嚴格區分。
OpenMVS與紋理對映
終於到了OpenMVS。。。。
已知OpenMVS可以用來稠密重建(點雲)、Mesh重建(點雲-->網格)、Mesh優化(非流行處理、補洞等)、網格紋理對映，正好對應原始碼自帶的幾個APP。
此處，目的只是單純的需要OpenMVS的網格紋理對映功能！瀏覽國內外有關OpenMVS的使用方法，尤其國內，基本都是”一條龍“服務，總結使用流程就是 colmap/OpenMVG/visualSFM...+ OpenMVS，基本都是使用可執行檔案的傻瓜式方式(網上一查一大堆)，而且基本都是翻來覆去的相互”引用“（抄襲），顯然不符合自己要求與目的。吐個槽。。。
為了使用Openmvs的紋理對映模組，輸入資料必須是 .mvs格式檔案，額。。。.mvs是個什麼鬼，我沒有啊，怎麼辦？！
好吧，進入OpenMVS原始碼吧，用自己的資料去填充OpenMVS所需的資料介面。（Window10 + VS2017+OpenMVS編譯省略，主要是自己當時編譯的時候沒做記錄，不過CMake工程一般不太複雜）。
場景Scene
檢視OpenMVS自帶的幾個例子，發現其必須要填充Scene類，針對自己所面對的問題，Scene類的主要結構如下:
class MVS_API Scene
{
public:
PlatformArr platforms; //相機引數和位姿 // camera platforms, each containing the mounted cameras and all known poses
ImageArr images; //紋理圖，和相機對應 // images, each referencing a platform's camera pose
PointCloud pointcloud; //點雲 // point-cloud (sparse or dense), each containing the point position and the views seeing it
Mesh mesh; //網格 // mesh, represented as vertices and triangles, constructed from the input point-cloud
unsigned nCalibratedImages; // number of valid images
unsigned nMaxThreads; // maximum number of threads used to distribute the work load
... //省略程式碼
bool TextureMesh(unsigned nResolutionLevel, unsigned nMinResolution, float fOutlierThreshold=0.f, float fRatioDataSmoothness=0.3f, bool bGlobalSeamLeveling=true, bool bLocalSeamLeveling=true, unsigned nTextureSizeMultiple=0, unsigned nRectPackingHeuristic=3, Pixel8U colEmpty=Pixel8U(255,127,39));
... //省略程式碼
}自己所需要的主要函式為bool TextureMesh(),可見其自帶了很多引數，引數意義後期使用時再討論。
Platforms
首先來看platforms，這個東西是Platform的陣列。在OpenMVS中，Platform定義如下：
class MVS_API Platform
{
...
public:
String name; // platform's name
CameraArr cameras; // cameras mounted on the platform
PoseArr poses;
...
}對我們而言，必須需要填充CameraArr和PoseArr兩個陣列。
CameraArr是CameraIntern型別的陣列。CameraIntern是最基本的相機父類，一提到相機，則必須包含兩個矩陣：內參和外參，CameraIntern也不例外，它需要使用如下三個引數填充，其中K為歸一化的3X3相機內參，可用Eigen中的矩陣填充，所謂歸一化，其實就是該內參矩陣的每個元素除以紋理圖片的最大寬度或高度；R顧名思義，表示相機的旋轉，C表示相機的平移，R和C共同構成了相機的外參。
KMatrix K; //相機內參（歸一化後的） the intrinsic camera parameters (3x3)
RMatrix R; //外參：相機旋轉 rotation (3x3) and
CMatrix C;PoseArr是Pose型別的陣列。Pose是類Platform中定義的一個結構體：
struct Pose {
RMatrix R; // platform's rotation matrix
CMatrix C; // platform's translation vector in the global coordinate system
#ifdef _USE_BOOST
template <class Archive>
void serialize(Archive& ar, const unsigned int /*version*/) {
ar & R;
ar & C;
}
#endif
};
typedef CLISTDEF0IDX(Pose,uint32_t) PoseArr;從上述Pose中可以看出，其也包含了兩個矩陣，但是這裡的Pose中的矩陣所表示的物理意義和CameraIntern中外參的物理意義完全不同，簡單來說，<font color=red>CameraIntern中表示的是相機本身固有或自帶的屬性，而Pose則表示整個Platform平臺(包含相機的)在世界座標系中位姿矩陣，針對每一張紋理圖(下面介紹)，這兩個屬性引數共同構成了對應相機的真實外參</font>（後期通過原始碼解釋）【問題1】。
Images
images是ImageArr型別的陣列，如同原始碼中解釋，每個Image對應於每個相機位姿。Image的結構如下：
class MVS_API Image
{
public:
uint32_t platformID;//plateform相對應的ID // ID of the associated platform
uint32_t cameraID; // camer對應的ID //ID of the associated camera on the associated platform
uint32_t poseID; // 位姿ID //ID of the pose of the associated platform
uint32_t ID; // global ID of the image
String name; // 該imgage的路徑 // image file name (relative path)
Camera camera; // view's pose
uint32_t width, height; // image size
Image8U3 image; //load的時候已經處理. image color pixels
ViewScoreArr neighbors; // scored neighbor images
float scale; // image scale relative to the original size
float avgDepth；
....
}如上述自己新增的中文註釋，其中<font color =red>platformID、cameraID和poseID三個引數一定要與Platform中的成員屬性嚴格對應</font>，對自身而言這是最重要的三個引數，Platform中的成員變數本身並不攜帶ID屬性，只是根據新增順序預設排序，ID索引從0開始遞增。
在Image結構中，還有不得不提的camera成員，如原始碼中所註釋，它表示視角(Camera)的位姿，也就是哪個相機對應於該圖片。乍一看該camera成員也必須要進行填充，可事實並非如此，原因後期解釋【問題2】。
該結構中其他成員，如影像寬度高度、影像的name等，在呼叫Image::LoadImage(img_path);函式的的時候會自動填充；neighbors成員表示影像於3D點的鄰接關係，在紋理貼圖中非必要選項，而且不影響紋理貼圖效果。
PointCloud
該成員表示點雲，一般作為OpenMVS的稀疏重建或稠密重建的結果，對於網格不具備約束性，直接捨棄不填充。
Mesh
OpenMVS中的三角網格儲存結構，我只需要知道其有Load函式即可。