背景：

colmap下进行三维重建可以利用最小割将图片分块，局部进行重建，利用分布式可以加速此流程。

最小割简单示意：

s为起点，t为终点，阻断s到t的流量的代价最小的割的集合，叫做最小割。

normalized N cut

带权重的最小割，因为实际graph中没有s和t，如果只想把整个graph切成两部分，就可能出现下图min-cut 1和min-cut 2。

引入normalized约束就是为了让两块更均匀（better cut）

分块更“均匀”的目的：

意味着分块过程更倾向于n变成2个n/2，而不是n-1和1，因为1是没法去重建的，而n-1也无法获得加速效果。综合来讲，不合理的切割会导致既不能加速，又会丢图（太小没法用）。

而且分块重建最终不可避免的需要分块合并，需要把分开重建的两个区域拉回到一起，所以每个独立的块需要结构更鲁棒，内部结构更明确，外部要与其他块有明显关联。

所以目的明确了，需要产生，更加左右平衡，更加互相关联度大的小块。

最小割的问题与分块功能优化：

实际的分块逻辑直接调用normalized N cut后仍然会有很多问题，因为最小割不会考虑三维重建业务本身，所以切割出来的东西并不会特别“关照”，会有很多不符合需求的问题产生。

三维重建中，graph的edge存储形式是图像间的匹配性，weight是图像间匹配对的个数。除此没有任何关联。当最小割“自由发挥”时，可能会产生凸点问题和多连通域问题，这两个问题会因数据丢失导致二分切割无法继续下去。

对此，做了两个小优化：

对比航拍倾斜摄影与地面街景采集：

1.倾斜摄影建模或产出点云容易，相对比下，街景数据（360全景相机采集加工）则比较难（尤其是环形绕障碍物采集的AR数据，两条航带隔着大规模障碍物，无关联度。）

2.除了点云产出质量，还有一个速度问题，利用最小割讲所有图片关联组成的图结构切割，利用分布式分块进行重建，会提速很多，但是倾斜摄影产生的图结构，关联度是可以很大的。拓扑结构是网状的（并且是可以交叉重叠的网）几刀下去，还是会有一定的关联度；而360°街景（中间带建筑物）采集出来的街景是环形拓扑结构，一刀下去就那两个边有流量(最小割)。

直觉上，倾斜摄影在高空，能跨航带重叠，并且因为五机位+倾斜度，实际重叠度会更大。

而360°街景为地面采集数据，重叠度对采集方式敏感，在工程化加工时（区域分块重建）会发生很多问题。

倾斜摄影关联度如图（image_id）

通过image——id查询db对应图片路径进行分析

拓扑关系如图：

星型结构，并且中心一点的区域会产生很大跨度的立体网状连结。

back 862对应球场位置

用图片路径在cc中查找相机

横向第二“航带"第五机位

第二航带第一机位

横向第四"航带"

纵向，第八个机位

这是AR数据：

环形拓扑结构的一个典型节点，前后关联都很线性。

（每一个点都前后有十几二十个点的链接，不是严格的”窄“环，但是整体结构呈环状，只要足够窄，切割后关联度太低，也是无法进行分块的合并的）

我用一个网络拓扑结构来说明：航空倾斜摄影就像最左侧，街景采集就像最右侧，无论怎么加粗，都是一个环形，都很脆弱，切割之后变成圆弧，圆弧结构脆弱，且无法回环检测。

这种环形拓扑结构切割很看运气，极端条件下，16万条边，切割完成后，两边的交界处overlapping直接为零，两区域关联度为0，切割失败（无法利用多视角进行分块合并）

结论：

倾斜摄影，横纵跨度大，关联度高。back 862已属角落，若选取中心区域摄影，会产生更高重叠度。

对比：

AR PURAN数据(绕圈采集，并且圈内是实墙障碍)：1/1.jpg只与后续1/2.jpg~1/29.jpg有关联，是线性结构，而非S型网状结构。

这种环形拓扑结构切割很看运气，如果刚好数据密度和关联性差，而最小割一定就取最小关联度的点去切，势必导致切割之后失去关联度。要求全局数据密度合理，运气好，才能切割。

并且1/1.jpg与2/1.jpg关联，与5/1.jpg关联，认为裁剪存在问题。

补充:环形结构一刀下去就是一条完全的线了，弯曲的线不能完成闭环检测，即使勉强去重建，也会是发飘的结构，有累积误差。

附：街景采集效果图