E-FOTO开源数字摄影测量教学工作站：模块流程与数据流解析

简介：E-FOTO 是一套专为教学设计的数字摄影测量工作站，面向测绘、地理信息与遥感专业的学生及教师，遵循自由使用与自学理念，帮助读者在免费开源环境中理解商业软件背后的概念、算法与流程。文档系统梳理了图像校正、内定向、外定向、摄影三角测量、立体图正态化、数字高程模型、正射纠正与数字立体展绘八大模块的原理与实现思路，并介绍在线帮助、EBOOK 等教学资料、模块间通过 XML 文件交换数据的集成方式，以及项目自 2002 年以来的进展与教学应用展望。资源包共 1 个 doc 文档，约 1.62MB，为项目综述性论文，适合作为课程讲义或自学参考资料。已有 305 人浏览学习，可帮助读者快速建立摄影测量处理链的整体认知，并为进一步阅读源码、改造模块提供索引。

1. 数字摄影测量在算什么：一张航拍照片，怎么变成一把能读数的尺子

翻看一张航拍图，大多数人第一反应是“拍得挺清楚”。搞测绘的人第一反应往往是：图里那条跑道，实际有多少米？照片只是平面的亮暗，真实世界有三维的几何，摄影测量要答的就是这道题——不靠尺子丈量，只靠成像规律反推。数字摄影测量把这件事交给计算机：影像进来，坐标出去。E-FOTO 就是一套做这件事的数字摄影测量工作站，但它前面挂了个限定词——面向教学。它免费、开源，配一本数字摄影测量电子书和八个处理模块，目的不是替你把活干完，而是让你看清商业软件封装起来的那一段。

2. 为什么要有“教学专用”工作站：商业软件把关键的那一步藏起来了

2.1 商业软件像一台封装好的洗衣机

用过商业摄影测量软件的人大概都有这个体验：把影像导进去，设几个参数，点一下“开始处理”，泡杯咖啡回来，正射影像已经躺在输出目录里了。流程顺滑得让人挑不出毛病。问题也恰恰在这儿——顺滑意味着中间发生的事你看不见。它凭哪组方程把像点扳到地面？它选的是仿射变换还是投影变换？重采样用的是双线性还是双三次？平差迭代了几次、在哪一步收敛的？全被一个进度条盖住了。

对生产单位来说，这是理所当然的封装，不需要操作员懂里面的数学。但对刚学摄影测量的人来说，这层封装恰好把最该看的部分挡得严严实实。你能记住“点这三个按钮能出图”，却说不出这三个按钮之间到底传递了什么。

2.2 教学要的是能拆开、能改、能自学的环境

E-FOTO 的两条设计原则写得很直白：自由使用，自学。

自由使用，意味着它走的是自由软件许可这条路，源码公开，下载下来不是只能点按钮，而是能一行行看；自学，意味着它自己就带着教材——在线帮助、一本数字摄影测量的电子书、一批航拍影像和相机校正资料，都放在同一个入口下能拿到。学生的路径因此变得很长：先照着书读懂原理，再用软件跑一遍，遇到想不通的地方去翻源码，最后甚至可以动手改一个模块、加一个新算法进去。这套路径和“按培训手册学会点哪个菜单”完全是两回事。

项目从 2002 年起步，最初的目标定得很朴素：把校正、内定向、外定向、三角测量、立体图正态化、高程模型提取、正射纠正这一串模块各做出一版。到 2007 年 5 月，这批模块的第一版都落地了。此后主要做的是工程层面的优化，没有再急着堆新功能。

有个用词得先说清楚。“工作站”在这里不是指某台机器，更不是硬件配置，它指的是一个能完成一整套摄影测量处理工作的环境。软件加上教学材料，合起来才叫工作站。

还有一句定位上的话值得记下来：E-FOTO 从一开始就没打算和商业软件抢活。它要做的是把“藏在商业软件背后的概念、工具、算法”摊开给人看。这句话决定了它后面所有的设计取舍——包括为什么它的模块是散的，为什么它先做数学验证再做界面。

2.3 算法先在高阶平台上验证，再翻译成软件

这套项目的开发路径有点像做菜前的试味：算法先用 MathCAD 这类数学平台写一遍、跑一遍，确认公式站得住、结果对得上，再转写成 C++，挂到 QT 的图形界面上。

先验证再实现，听着慢，其实省事。摄影测量的每一步背后都是成串的公式：共线条件方程、仿射变换、光束法平差。要是直接拿 C++ 写，公式错一个符号，程序照样能跑，只是结果默默偏掉，你根本不知道该怀疑哪一行。在数学平台里，中间结果能直接看见，错在哪一步一目了然。这种做法不玄学，就是给自己留一条可以回头的路。

QT 这个选择的理由也很实际：一套代码，在 Windows、Linux、MacOS 上都能编译。教学场景里最怕的就是“这软件只在我这台电脑上跑得起来”，跨平台把这个坑提前填了。

3. 八大模块是一条流水线：从把照片摆正，到把地形立起来

3.1 图像校正与内定向：先摆正照片，再对准相机

图像校正解决的是一个很直观的问题。你从斜上方拍一个正方形楼顶，照片上它是个梯形。校正做的事，就是根据图像的透视轴，把整幅影像重新投影到一个水平面上，把相机的姿态角带来的变形修正掉，理想情况下能完全消除，最终得到一张接近垂直摄影的新影像。

打个比方，这就像你歪着拍了一张课桌的照片，然后要求把它“掰”回俯视的角度。这个“掰”的动作，本质上是一个坐标变换。E-FOTO 提供了六种变换可选：一般仿射、等角仿射、正交仿射、刚体仿射、等角变换和投影变换。选哪种，取决于你认为影像只发生了平移、旋转、缩放，还是也包含了透视形变。

变换完之后像素要重新取样，这就是重采样。软件给了四种方案：最近邻、双线性、双三次、拉格朗日。最近邻最快，取离得最近的那个原像素的值，代价是边缘容易出锯齿；双线性用周围四个点加权，平滑一些；双三次用更大邻域，细节保留更好但会略微钝化；拉格朗日精度更高，计算也最慢。这个选择不涉及对错，只是精度和速度之间的取换。

内定向是整条流水线的入口。它要干的事，是用影像上的框标点，把“像素在第几行第几列”这种像方坐标，换算到以像主点为原点的像平面坐标上去。算完之后，模块会输出一个变换矩阵，外加一组描述定向质量的统计参数。学生拿到这组数字，就能判断刚才点的框标准不准。

值得一提的是，内定向模块最初做出来后，界面友好性和可用性都有明显问题，源码因为设计没做好也变得难读。到 2006 年，项目组索性把它废弃重写，顺手把可视化和量测这部分逻辑抽成了一个 View 类。这个类后来被内定向、外定向、数字测量、摄影三角测量和正态化好几个模块共用。一次重构，换来的是后面每一步都在复用同一套量测代码。

3.2 外定向与摄影三角测量：算出相机在哪，再算出点在哪

内定向解决的是“相机内部怎么成像”，外定向解决的是“拍照那一刻，相机站在空间的哪个位置、镜头朝向哪边”。六个外方位元素，三个位置加三个姿态角，解出来这套参数，一张影像才真正和地面挂上了钩。

外定向的结果输出比内定向更细：变换矩阵、定向质量的统计参数，还有整个迭代过程跑了几轮，以及一条描述平差是否收敛的消息。这条消息很重要——如果迭代没收敛，前面那些参数看着再正常也不能信，相当于黑匣子自己承认没算明白。

摄影三角测量是把单张的事变成一群影像的事。它的思路是光束法平差：把每张影像从投影中心射出去的光束当成一个整体，同时求解所有影像的外方位元素和一批加密点的地面坐标。单张外定向是各算各的，区域网平差是大家一起商量着调，后者对控制点不足、影像数量多的情况明显更稳。

这个模块最初是当本科毕业设计做的，算法同样先在 MathCAD 上验证。测试方法也很实在：拿一个像对做匹配，把结果和其他解法逐点比较，确认本模块的解更优，才开始往 C++ 上移植。最终版本提供两个接口，一个管点测量——用户联机点一个点，立刻拿到坐标；一个管点创建——用户先把一批测量点圈出来，再一次性算它们的坐标。

3.3 立体图正态化与 DEM：让两只眼睛对得上，把高程抽出来

立体图正态化用的是 Schenk-Cho 算法，干的事基于核线几何。通俗地说，人眼看远近，靠的是左右眼看到同一物体的水平位移；立体像对也一样，只有当同名点只在水平方向上有差异时，视差才好量、自动匹配才好做。正态化就是把原始立体像对重采样成核线影像对，把垂直方向的差异尽量抹掉，让后续的自动匹配和立体观察省力。

这一步看着技术性很强，其实它解决的是一个“对齐”问题。两张照片如果连角度都对不上，机器找同名点就像在两张不同格式的地图之间找同一个路口，纯属自找麻烦。

DEM 抽取模块要在测区上架一张虚拟格网，然后一个格子一个格子地推高程。用的工具是共线方程：先把成像时的透视光束重建出来，再用空间前方交会，算出格网上每个点对应的地面三维坐标，最后连成地形模型。它存在的意义有一半是为了下一步——正射纠正必须知道每个像素脚下那块地有多高，否则压不平。

DEM 模块的测试方式挺有意思：直接拿一个校区做主校区做了 3D 可视化，等于是用自家院子当试验田。

3.4 正射纠正与数字立体展绘：把斜的压平，把轮廓画出来

正射纠正是 DEM 抽取的下游。有了高程格网，就可以逐像素地把中心投影的影像纠正成正射投影——地面上每一个点，在影像上的位置和它在地图上的位置能对得上。输出分两类：一类同时带高程和灰度信息的完整模型，一类只有灰度信息的数字正射影像。前者数据更全，后者更接近传统意义上的成果图。

数字立体展绘（也就是数字补偿）走的是另一条路。它不逐像素算，而是在立体像对上勾绘地物和地形的三维轮廓。勾出来的这些三维要素，可以作为 back-lines 插回 DEM 里，用来修地形——机器在植被茂密或者纹理寡淡的地方容易把高程算飘，人工在立体下勾几条线，往往比反复调参数管用。

把八个模块的名字和职责摊开看，整条链路就清楚了：

这张表也解释了为什么“工作站”这个词用得不算夸张：从一张原始航片出发，一直走到能用的正射影像和三维轮廓，八个环节缺一环都走不完。

4. 模块散着放怎么变成工作站：XML 数据流与控制层的角色

4.1 独立模块是优点，也是麻烦

早期 E-FOTO 的八个模块，是一个个孤立的程序，谁也不是谁的延伸。这个设计在教学上有明显好处：一个模块可以单独学、单独改、单独验证，一个学生在一个学期里把内定向吃透，完全不需要先搞懂正射纠正。

麻烦也很直接。数据得靠用户自己搬运。上一步的结果存在哪个文件里、是什么格式、下一步怎么读进去，全靠你自己心里有数。一个环节参数填错，后面几步全白跑，而且报错往往出现在离错误很远的地方——这种血泪经验在松散结构里特别多。

所以项目组后来做的事，不是重写算法，而是给这堆程序加一条数据传送带。

4.2 XML 当传送带，控制层当调度员

这条传送带的载体是 XML 摄影测量项目控制文件。它承担四件事：保存、访问、验证、处理各模块产生的数据。保存是写进 XML，访问是从 XML 里读，验证是检查这份数据合不合法，处理是把它交给下一个模块。

在此之上，项目加了一个控制层。控制层管所有数据流的输入输出，效果是用户只需要录入当前这一步真正需要的数据，其余的从之前生成的 XML 里读过来就行。它还顺带负责界面输入的验证——该是数字的地方你填了字母，当场拦下来，而不是等到平差跑完才发现全错。

示意一下这个控制文件大概长什么样：

<!-- 摄影测量项目控制文件示意，字段名做了简化 --> <project> <sensor> <focal_length unit="mm">152.0</focal_length> <principal_point x="0.0" y="0.0"/> </sensor> <images> <image id="IMG_001" path="frame_001.tif"> <!-- 前一步做完，这里的状态才会被后续模块认可 --> <interior_orientation status="done" file="io_001.xml"/> </image> </images> <control_points file="gcp.xml"/> </project>

这段结构里，focal_length是相机焦距，是图像校正和内定向都要用的参数；principal_point是像主点，内定向的基准；status记录这一步做没做完，控制层靠它判断能不能往下走；file指向具体的中间结果。整套机制的核心思路是让每个模块只关心“我要什么”和“我产出了什么”，至于这些数据怎么串起来，交给控制层和那份 XML 去操心。

注意：模块之间靠 XML 传递数据，改动一个模块的输出字段，下游读它的模块会立刻失效。改字段时顺手同步一下下游的读取逻辑，能省掉很多排查时间。

4.3 代码维护才是软件生命周期的开始

软件发布可执行文件，生命周期并没有结束，恰恰相反，最耗时间的部分才刚开始——维护。项目组在这件事上的态度比较务实：一边修旧模块的缺陷，一边开发新模块，同时靠在线渠道收集用户反馈，把问题一条条列出来消化。

重构的例子前面提过，内定向重写时抽出的 View 类被多个模块复用；外定向第一版的代码在改进时也做了重用，没有推倒重来。这种“能用的先留着、难懂的再重写”的节奏，比一次性重写整个项目更符合教学的现实——参与开发的多是研究生和本科生，人来人往，代码必须写得让下一个人接得住。

跨平台这件事也有持续的代价。界面选型升级一次，很多类会被标记废弃，代码迁移的工作量相当可观。项目当时固定在某个 QT 大版本上，每跟随一次升级，都是一轮不小的工作。这一点对任何长期维护的软件都成立：依赖不会自己停住，你不跟着动，它就慢慢变成负担。

5. 五个最容易搞混的地方：别把内定向当成相机检校

5.1 摄影测量和遥感判读：一个在量几何，一个在认东西

易混点：两者都从影像里获取地理信息，外行看来几乎是同一件事。

为什么混：都跟航拍、卫星影像打交道，成果也常常一起出现。

怎么区分：摄影测量的重心是几何——影像上这个像素，对应地面哪个三维坐标，误差多大。它靠成像几何反算，输出的是坐标、高程、正射影像。遥感判读的重心是属性——这片区域是耕地还是水体，是林地还是建成区。前者回答“在哪、多高”，后者回答“是什么”。当然两者会互相借力，正射影像既是摄影测量的产物，也是判读的底图，但核心问题不是同一个。

5.2 内定向和相机检校：一个每次都要做，一个是提前标定

易混点：两个词都跟相机内部参数有关，听起来像同义词。

为什么混：内定向确实要用到焦距、像主点这些相机参数，而相机检校的产物也包含这些。

怎么区分：相机检校是对相机本身做一次标定，测出焦距、主点位置、镜头畸变系数这些相对稳定的量，属于“设备档案”。内定向是每处理一批影像时都要做的动作：用影像上的框标点，把像素坐标换算到像平面坐标，解出一个变换矩阵。检校结果是内定向的输入之一，内定向是每次作业的必经步骤。把两者混为一谈，容易出现“我相机校过了，为什么还要点框标”这种困惑。

5.3 外定向和摄影三角测量：一个解单张，一个解一群

易混点：两者都是解算参数，都跟相机姿态有关，结果看着也像。

为什么混：三角测量的输出里，也包含每张影像的外方位元素。

怎么区分：外定向是对单张影像求六个外方位元素，输入是这张影像上的控制点，解完就结束。摄影三角测量是把多张影像连成一个区域网，用光束法平差同时求解所有影像的外方位元素和一批加密点的地面坐标。前者是后者的输入，后者是前者的联合优化。影像少、控制点多的时候，逐张外定向也能凑合；影像成百上千、控制点稀疏的时候，不做区域网平差，误差会一路累积到后面每一步。

5.4 图像校正和正射纠正：一个整幅变换，一个逐像素纠正

易混点：名字里都带“纠正”，输出看起来都是“变正了的影像”。

为什么混：目的确实相近，都是消除变形。

怎么区分：图像校正是对整幅影像施加一个统一的几何变换，仿射也好、投影也好，一幅图一套参数，做完就完事。它对付的是相机姿态带来的整体倾斜，前提是地形起伏不大。正射纠正要逐像素处理，因为它要消除的是地形起伏造成的投影差——山包上的点和山谷里的点，位移方向和大小都不一样，一个统一变换根本压不平。所以正射纠正必须依赖 DEM，没有高程就无从纠正。判断标准很简单：地势平坦、只求近似，用校正；地形有起伏、成果要能当底图量距，用正射纠正。

5.5 DEM 和正射影像：一个有高，一个有颜色

易混点：两者常常一起出现，都是“地表模型”。

为什么混：正射影像是在 DEM 的基础上做出来的，两个成果文件经常并排交付。

怎么区分：DEM 是一张高程格网，每个格子只存一个 Z 值，没有颜色、没有纹理，它在计算机里更像一张灰度图，只是灰度代表的是海拔。正射影像是一张纠正过的照片，每个像素存的是地表反射的亮度和色彩。前者回答“这里多高”，后者回答“这里长什么样”。拿 DEM 去判读地物类型是南辕北辙，拿正射影像去量高程同样不靠谱。

6. 什么时候该用它，什么时候别碰

教学软件和生产软件，是两种完全不同的东西，用错了场景，两边都会失望。

适合用 E-FOTO 的场合，基本围绕“搞懂”和“验证”这两个词。比如课堂上讲完共线方程，学生需要在真实数据上跑一遍，看看公式怎么变成坐标；比如研究生要试一个新写的匹配算法，需要一个能读源码、能改模块、还能跨平台编译的壳子；再比如小范围的实验测区，影像就几对，时间是充裕的，重点是每一步的中间结果能不能拿出来看。这些场景里，E-FOTO 的优势全在透明：源码能翻，电子书能对着读，模块的输出里带着精度统计和收敛信息，失败了也知道该往哪查。

不适合的场合也很清楚。生产任务首当其冲——商业工作站把各模块整合成一条顺畅的流水线，正是为了效率，而 E-FOTO 的模块长期是相对独立的程序，集成还在推进中，靠手动搬运数据的效率撑不起工期。影像量大的项目同样不合适，几百上千张影像的区域网，光在模块之间倒腾数据就够呛。还有一类是“只想要结果、不关心过程”的团队，用这套软件纯属自找麻烦。

我第一次接触这类教学软件的时候，犯过一个挺典型的错误：拿它当商业软件的替代品，直接上了一批生产数据，指望它一口气出正射影像。结果内定向的精度统计我没看，外定向的收敛消息我也没看，一路点到正射纠正，出来的图位置整体偏了一截，回头排查才发现问题出在很早的一步。从那以后我每次跑这类流程，都强制自己先把每一步的精度统计和收敛信息拉出来看一眼，再决定要不要往下走——参数好看不代表算对了，报错没出现也不代表没出错。

如果你手上正好有一批航拍影像，又一直没弄明白商业软件里那个进度条背后到底发生了什么，这套东西值得下载下来，配着电子书从内定向开始一步步走一遍。希望帮到你。

本文还有配套的精品资源，点击获取