怎么把几百张无人机正射影像拼接成一张完整的图。?
现在有一个村落的无人机影像数据几百张，不知道怎么拼接，求告知用什么软件怎么操作 无人机RGB影像拼接流程（使用地面控制点）本文介绍使用地面控制点（GCPs）拼接无人机RGB影像，生成DEM、DOM。
数据获取情况：
无人机：DJI M600 PRO
相机：Sony A7RM2(40mm)，不具备GPS记录功能
场景：农田
旁向航向重叠率：≥75%
飞行高度：30m
软件：Agisoft Metashape Pro 1.8
Agisoft官方原文：Aerial data processing (with GCPs) - Orthomosaic&DEM generation : Helpdesk Portal (freshdesk.com)
2022.8.30：之前排版有问题，现已更新
1.新建并保存项目
1.1依次点击File → Save.
1.2编辑项目名称，点击“保存”.
2.添加照片
2.1依次点击Workflow → Add Photos.
2.2选择需要拼接的照片.
3.对齐照片
照片需要对齐。在这个阶段，Metashape 估计每张照片的相机位置和方向，并生成由连接点组成的稀疏点云。
3.1. 依次点击 Workflow → Align Photos...
3.2. 对齐参数如下图，点击 OK .
4.添加标记（Markers）
在飞行任务开始前，在航测区域铺设地面控制点标靶，使用RTK测量其坐标和高程，导出数据。标靶和文件格式如下图，本文选择WGS84坐标系。
4.1.依次点击 View → Reference，调出相关窗格
4.2.选择Reference窗格，点击 Import Reference.
4.3. 选择.csv文件，点击打开
4.4.选择坐标系，选择分隔符，指示经纬度和高程列数.
4.5.点击 OK ，点击 Yes to All
5.添加地面控制点
5.1.选择包含地面控制点的照片
5.2.在图片中右击地面控制点，依次点击 Place Marker → 控制点名称 ，在控制点处会出现绿色小旗和控制点名称
5.3.每个地面控制点至少在两张照片标记，软件根据对齐信息自动标记其他照片中的地面控制点（灰色小旗）
5.4.切换至模型视图，可查看地面控制点的相对位置
6.建立批处理任务
6.1.依次点击Workflow → Batch Process...
6.2.点击 Add.... 添加任务
6.3. 添加 Optimize Alignment（优化相机对齐参数） 工作，参数如下
6.4.添加 Build Dense Cloud，参数如下
6.5.添加 Build DEM，参数如下
6.6.添加 Build Orthomosaic，参数如下
6.7. 勾选 Save project after each step
6.8. 保存批处理文件
7.使用批处理文件进行批处理
8.导出DEM
9.导出DOM
写在前面
感谢长三角智慧农业研究院史云院长对这项工作的支持！
任何一个优秀的开源项目都会有详实且不断更新的文档，充分阅读和研究这些文档是最好的学习途径，当然英文和专业术语，行业小话等等，都是阻碍阅读的障碍，但这些都是通过搜集资料花时间理解就能够克服的，也并不是难以完成的任务。
WebODM就是这样一个优秀的开源项目，它的主要开发语言有三种:
[*]JavaScript：界面交互；接口层
[*]Python：接口；算法；
[*]Bash脚本语言：编写服务器上的可执行脚本如项目启动停止的命令行工具
围绕这三个套语言有很多依赖的框架和技术，这些我们会在涉及到具体细节时再一一介绍。
1. 项目组成：
WebODM只是整个OpenDroneMap项目组成中的一个部分，从github的项目首页来看，该项目的定位是一款持续性的开放无人机测绘软件，围绕这个目标，有如下几个核心仓库，他们的作用如下：
[*]ODM: 一个将无人机拍摄原始影像拼接成地图，点云，3D模型和数字高程影像的命令行工具
[*]WebODM: 围绕着 ODM 增加了用户管理，系统设置，工程管理，任务管理，结果可视化等系统模块的BS系统软件
[*]NodeODM: 使用Node.js与express等框架开发的API接口层，同时也可以作为分布式任务的一个处理节点
[*]ODMdata: 示例数据
[*]ClusterODM: 分布式任务调度节点，与 NodeODM 配合使用
[*]docs: 文档
2. 架构
WebODM从架构设计上就采取了分布式方案，目的是应对大体量的无人机影像，一次无人机测绘作业生产千张影像是很正常的，原始影像数据可能在几G到几十G不等，分布式的架构能够弹性的伸缩扩展，可以应对这样的使用场景。从以下架构图中可以看出，WebODM的作用只关注业务部分：如用户管理，任务注册，任务进度回显，系统配置等等，而后台任务则通过 NodeODM 接口层传递到 ODM 命令行工具进行处理。
下面这张图是上面绿色部分
的展开结构，描述了其中各个组件间的关系：
[*]白色部分是与计算机的文件系统相关的：
[*]dbdata是数据库文件
[*]appmedia是节点间共享的文件存储；
[*]黄色部分是数据库应用相关的：
[*]PostGIS 指 postgres + postgis（数据库应用与空间类型的扩展）
[*]Redis Broker 是缓存数据库；
[*]紫色部分是一些其他应用：
[*]Nginx：反向代理服务器，用于分发静态资源，负载均衡，后端接口代理
[*]Gunicorn：Python 服务网关
[*]Django：Python Web开发框架
[*]CeleryScheduler/ Celery Worker：异步消息队列，用于处理异步耗时任务
各个组件的联系如下：用户在前端填写任务信息，调用任务的注册接口，浏览器发起的请求通过 nginx -> Gunicorn -> Django经过 Django 应用处理过后，将任务描述信息存储至数据库中，将任务数据（图像等）存储至 appmedia，任务开始后，由 CeleryScheduler 进行异步程序调度，由 CeleryWorker 负责具体后台任务执行，执行过程中利用 Redis 进行通信（反馈后台任务的开始，过程，结束等事件），执行过程中需要的数据来自于数据库 PostGIS 与 appmedia，CeleryWorker 同时与 NodeODM 接口层进行通信，传递执行命令。
3. 依赖
值得一提的是，ODM也依赖于许多底层的开源依赖，在官网中都有致谢提及，不得不说，开放和共生才会让软件的生命力愈来愈旺盛：
Our processing software makes use of several libraries and other awesome open source projects to perform its tasks. Among them we’d like to highlight, OpenSfM, OpenMVS, PDAL, Entwine, MVS Texturing, GRASS GIS, GDAL, PoissonRecon.PostgreSQL (>= 9.5)
PostGIS 2.3
Python 3.6
GDAL (>= 3)
Node.js (>= 6.0)
Nginx (Linux/MacOS) - OR - Apache + mod_wsgi or Waitress (Windows)
Redis (>= 2.6)
GRASS GIS (>= 7.8)参考资料
[*]Gunicorn 网关
Python WSGI HTTP Server for UNIX
[*]Celery 异步消息队列：用于master指挥worker去做异步耗时任务，需要一个消息中间件来通信
Celery - Distributed Task Queue俺是路飞呀：Celery介绍和基本使用
[*]OpenDroneMap官方博客
https://opendronemap.org/blog/
[*]WebODM开源项目研究总结（一）
Mr.Car：WebODM开源项目研究总结（一）
[*]长三角智慧农业研究院
中农数智
[*]长三角智慧农业研究院公众号：CSJZHNYA
正射用pix4d效果不错 正射可以用pix4d，不过cc也可以 写个代码，镶嵌一下就可以了。
页:
[1]