一、问题

如题,要进行一个大场景的3DGS重建,数据集来自于某工地现场(大约3000张照片),数据集拍摄于同一个相机,按照国际惯例,3DGS需要输入一个稀疏点云,所以首先利用colmap进行稀疏重建。

进行特征提取,特征匹配(colmap官网建议1000-10000张图的特征匹配使用vocab tree),稀疏重建以后,发现场景中,楼宇出现弯曲,分裂现象,如下图:

7f837e07183b8803bf92d19e18329141.jpg

f16e9f4dcc92944ac9a180e58ae9ec0c.jpg 问题出现以后,查看(在colmap gui界面双击)弯曲部分对应的照片,楼宇上下拍摄角度的照片并没有发现畸变(楼宇是直的,简单的用尺子或者其他工具对比一下,楼宇是否有弯曲)

bc44e38ddc63b3f43baca5f59c06b424.jpg

 从拍摄的照片来看,虽然是对着楼宇上下拍摄,但是无人机的镜头并没有调正,很多照片全是偏向于俯视,头大尾小,虽然这样不影响重建效果,但是处理这些必然是要花费更多时间,相比于端正拍摄的镜头来说。

24e926d7dbf4af2598ab9f0d801a5587.jpg

dd7dd07e1d48e51fc42b855e2e41fa6b.jpg

 然而,在检查楼宇最上方的俯视视角照片时,发现了几处畸变,原来问题出现在这里!因为这些畸变的出现,colmap的计算产生了误差,导致原本方形的楼宇扭曲。后续删除了一些畸变很大的照片。

二、处理

实际上,对于照片中存在的畸变,colmap一般可以修正,猜想这个问题有可能因为特征提取时限定了所有路径下图片使用同一个相机模型。

因为数据集路径中,楼宇的上下与环绕视角,空中俯视视角,两种类型的照片存于不同文件夹,考虑将上下与环绕视角的数据单独分出来先进行重建,先得到正确的楼宇点云,然后在这个正确的结果之上,进行全局的稀疏重建。

具体先重建出上下环绕视角的点云,然后所有图片重新走一次sfm过程,特征提取的时候使用camera for subfolder(每一个文件夹使用一个相机模型,而不是所有文件夹使用同一个相机模型),然后特征匹配,这里可以使用前面重建上下环绕视角的时候得到的database.db文件,里面存储了之前的特征提取和匹配的数值,这样可以更快一点,colmap vocab_tree_matcher --database_path path/to/databse.db ...。下图是正确的楼宇环绕点云:

5b4620c3d487a41c7a6c9c85d2a32593.png

在进行最后一步稀疏重建的时候,添加一个参数--input_path,这个指向已有的稀疏点云,也就是前面重建的上下环绕视角点云,这样,在这个正确点云的基础上,重建剩余全部视角,得到修正的全局稀疏点云。

8cd1afd229d01c8713cb7a16c71ff1dd.png

 整体数据集稀疏重建成功,进入3DGS训练过程,注意大场景的训练显存占用较大,一些硬件,高斯基元相关的参数需要调整一下。

三、潜在的问题

3.1问题

上面提到了在colmap内使用--input_path来添加一个预先重建好的点云,来使得一开始所有图片all in重建失败变为成功,但是前面忽略了细节,先总结一下前面:

step1:先行对一开始重建有问题对应的部分数据(比如说数据集文件夹下的某几个子文件夹)进行重建,特征提取-匹配-稀疏重建,注意保存这个稀疏重建的结果。

step2:数据集中所有图片进行特征提取-匹配,然后在终端中使用colmap mapper进行重建,在--input_path后面加上刚才保存的路径即可

注意:前后两次流程中,特征提取对应的相机模型、相关选项(所有子文件使用同一个相机模型,还是一个子文件夹使用一个相机模型),要前后一致。

下面介绍因为忽略文件路径导致的报错:

图1:在ubuntu使用colmap mapper --input_path时,报错check failed,原因是有两张图图片对应的有问题:

existing_image.Name() == image.second.Name() (1/77.71511885467315.png vs. 1/44.58024851431659.png)

查看了对应的图片,确实不对

d79b38be3e724877be075f33738e234d.png

图2:win10下:两个图片的名称倒是一致,但是在database里面写入的路径不一致,一个是9/47.2另一个是global/9/47.2,多了一级!!!

1cb5628b96784b30a2a2c0d07d29ff30.png

报错原因:在step1时,有一个database文件,后称database1,在step2时,有另外一个database文件,后称database2,添加--input_path以后,加载过程中database1会与database2对齐,如果里面文件不一致,自然就会报错!

3.2解决win10

win10的解决:我的原始路径是:folder\input\,在input有两个文件夹:global和local,注意这里的细节伏笔!在路径中,global排在local前面。a01ba95ca4b54e6c82cd8ddc9315818a.png

直接将global复制进另一个新建好的文件夹inputglobal,这个文件夹和input同一级,重建执行step1,最后win10中得以跑通。

3edc8f61c9784b88a105fc16fc531884.png3.3解决ubuntu22

仔细看ubuntu中的报错信息,与win10类似,但是不一样,这完全是把两张不一样的图片对应起来了,这里就是前面win10中提到的伏笔,ubuntu中,input路径下有两个文件夹0/和1/,而step1中,我想使用的是1/,然后我直接把1/复制到了和input同一级下执行了step1,导致了两个问题

一是:前面说的路径问题,1/应该是一个子文件夹

二是:子文件夹的顺序!1/在0/之后,所以,database1长这样:为了方便,把前面那张图放过来,方便对比

d79b38be3e724877be075f33738e234d.png

39eaae3006f64182840857e6520513dc.png

database2里面的第700张图,长这样:

e1c14d5667cc40638cbe54e44103e206.png

这就是这个报错的具体由来!

好了,既然知道了为什么会错,那就明白从哪改起了,重新放置文件路径:把原来的1/和0/,互换个名字,然后:

21c63228631d48aeb66653b9b850b791.png

e065bd657c7d412e9a4a3022e14a4850.png

830b4aa209674fcaa5b3d34f8d91b1cd.png

重新执行step1和step2!

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐