环视360全景拼接这块内容，我在几个量产预研项目和内部Demo上都完整走过一遍，从一开始拿四张鱼眼图硬拼出满屏重影，到后来能把拼接缝控制在两三个像素以内，中间踩的坑基本都集中在两件事上：几何模型没建对，以及标定和运行时没解耦。这篇就把这套开源环视360全景拼接代码的思路从头到尾拆一遍，讲清楚鱼眼畸变怎么校、逆透视怎么把地面拉成鸟瞰、四路图怎么拼成一张没有撕裂和色差的全景图，最后落到可以直接跑起来的代码骨架上。适合正在做ADAS泊车辅助、低速全景影像的算法同学，也适合刚接触相机标定、想找一个完整工程练手的朋友。哪怕你只写过一点点OpenCV调用，跟着思路走也能把整条链路搭出来。

1. 环视全景拼接的整体设计与思路拆解

1.1 从泊车场景反推：这套东西到底要交付什么

很多人一上来就看代码，结果看了三千行也不知道每个模块为什么存在。正确的顺序是从使用场景倒推。环视全景在车上最典型的用法就是低速泊车和窄路会车，用户盯着中控屏，需要在一秒内判断车身和路沿、车位线的相对位置关系。这个需求拆下来是三条硬指标：第一，画面必须是俯视视角，因为驾驶员在驾驶位根本看不到车头前下方和车尾正后方；第二，四个方向必须连成一张连续的图，不能是四个独立小窗，否则用户要在脑子里做拼接，认知负担太大；第三，接缝处的地面纹理必须对得上，尤其是车位线和地面砖缝这类直线特征，一旦错位，用户会直接判定这个功能不可用。

这三条指标直接决定了整个技术路线的走向。俯视视角意味着必须做逆透视变换，把相机斜着看到的地面投影到水平面上；四路连续意味着必须建立统一的车体坐标系，让四个相机的输出落在同一张画布上；接缝对齐意味着外参精度要求非常高，误差超过一两厘米就会在拼接缝上表现为明显的台阶。搞清楚了这三条，后面每一个模块存在的理由就都很清楚了：畸变校正为了让鱼眼的强弯曲图像变成可以被单应变换处理的样子，逆透视为了得到俯视图，外参标定为了让四路对齐，融合权重为了掩盖无法完全消除的残差。

这里还有一条隐含的工程约束容易被忽略：这套东西跑在车载域控制器上，算力有限，而且要求上电后几百毫秒内出图。所以整套实现必须是"离线算好、在线查表"的结构，在线部分只做像素映射和加权，不能有任何迭代优化。这一点在第1.4节会详细展开。

1.2 四个鱼眼为什么不能直接拼：三个绕不开的几何问题

新手最容易犯的错是把四张鱼眼图按位置摆在一起，然后抱怨为什么中间有个月牙形的黑洞、边缘还有严重的重复。原因在于鱼眼图像不是"平面的透视图"，它遵循的是等距投影或者等立体角投影，图像上的一条直线在现实里其实是曲线（除非这条线正好穿过光心），你把它当成普通图片去拼接，几何上从一开始就是错的。

具体来说有三个问题。第一个是畸变问题：同一块地面，在鱼眼图像中心附近和边缘附近的像素密度完全不同，边缘被极度压缩，靠边缘的一小块区域可能对应现实中的一大片地面，直接拼接会导致边缘区域分辨率严重不足、拉伸变形。第二个是视角问题：每个相机只有大约190度视场，四个相机加起来覆盖车周，但相邻相机的重叠区在图像上位置各不相同，需要把每一路都先映射到同一个坐标系里，才能知道重叠区到底在哪。第三个是尺度一致性问题：由于安装高度和俯角不同（前视通常装在前保险杠或格栅，侧视在后视镜下方，后视在尾门），同一块实景地面在不同相机里的成像尺度是不一样的，不统一尺度就没法对齐。

所以正确的做法不是"拼图"，而是"重建"：先把每一路相机图像还原成它在地面上对应的物理区域，再按照物理区域的重叠关系重新采样到一张虚拟的俯视画布上。这个"虚拟画布"就是鸟瞰图（Bird's Eye View），也叫俯视投影图。理解了这一点，代码里那些看起来莫名其妙的映射表、查找表就都能解释清楚了——它们本质上就是"目标画布上每个像素，去四路原始鱼眼图的哪个位置取颜色"的索引。

1.3 整条流水线的分层设计：离线标定 + 在线拼接

把整个系统切开来，是两条完全独立的路径。离线路径负责算参数，包括每路相机的内参（焦距、光心、畸变系数）和相对车体坐标系的外参（旋转和平移），再结合车辆尺寸把这些参数烘焙成四张"映射表"，每张表记录目标画布上每一个像素对应的源图坐标和融合权重。在线路径则极其简单：接收四路YUYV或NV12图像，用映射表做重采样，把结果按权重累加到同一张画布上，输出YUV或RGB给显示模块。

这种分层的核心价值是把计算复杂度从在线挪到离线。标定里的非线性优化、单应矩阵求解、融合权重生成，这些都是耗时且只需要做一次的操作；而在线部分只剩浮点乘加和内存搬运，非常适合放在DSP或者带向量指令的核上跑。我在一个项目里做过对比，如果在线做完整的畸变校正加投影变换，单帧四路1080p在某个中端车载SoC上要接近40毫秒；改成查表加双线性采样之后，压到了9毫秒左右，差别非常明显。

这里还有个隐藏收益：映射表本质上是一个"接口契约"。标定算法怎么改、用不用新的畸变模型，只要最终产出的表格式不变，在线拼接代码一行都不用动。团队协作时这一点极其重要，标定和渲染可以并行开发，联调时只对齐表结构就行。

1.4 为什么一定要用查找表而不是实时计算

有人会问，实时算一下投影公式不行吗？公式又不复杂。理论上可以，实际上不划算。一方面，每个目标像素都要走一遍"针孔坐标 → 地面坐标 → 车体坐标 → 各个相机坐标 → 鱼眼坐标 → 畸变反算 → 源图像素"这条链，中间涉及至少两次三角函数和一次非线性求根（鱼眼畸变通常没有解析逆），单像素成本很高。另一方面，目标画布上的像素位置是固定的，分辨率不变，映射关系也就不变，实时计算等于每秒重复做几十万次完全相同的运算，纯属浪费。

查找表的代价是内存。假设输出画布1024×1024，四路相机各一张映射表，每个像素存mapx和mapy两个float（也可以量化成int16，损失一点精度换一半内存），再存一个权重float，那么单路大小是1024×1024×(4+4+4)=12MB，四路接近50MB。这个量在车载域控上是可以接受的，但如果你要做多分辨率、多视角切换，就要考虑压缩。实践中的做法是把mapx/mapy量化成Q12的定点数（值域覆盖±2048像素），权重用uint8，这样单路降到1024×1024×5≈5MB，四路20MB，完全可控。

提示：量化会引入亚像素误差，Q12的精度是1/4096像素，远小于双线性插值的固有误差，实测在拼接缝上看不出差别。但如果你后面要做亚像素级的车道线检测，建议保留float版本做离线验证。

2. 鱼眼相机模型与畸变校正的关键细节

2.1 鱼眼成像模型：为什么不能用普通针孔加径向畸变

先说清楚一个常见误解：很多人以为鱼眼图就是普通图像加了很大的桶形畸变，用针孔的k1、k2、k3多项式就能拉回来。在视场角150度以内勉强能凑，超过180度就彻底失效了，因为针孔模型的投影关系是 r = f·tan(θ)，θ趋近90度时r趋于无穷，根本无法表达190度视场。

车载鱼眼镜头通常采用等距投影模型（equidistant），关系式是 r = f·θ，其中θ是入射光线与光轴的夹角，r是成像点到光心的距离。这个模型在θ接近90度时依然平滑，所以能覆盖超大视场。除此之外还有等立体角投影 r = 2f·sin(θ/2) 和正交投影 r = f·sin(θ)，不同厂家用得不一样，标定时如果模型选错，会表现为边缘区域怎么调都对不齐。

一个实际的计算例子：某鱼眼模组分辨率1280×720，标称水平视场190度。有效成像圆的半径实测约340像素（注意不是半宽640，因为图像是16:9裁切，圆形像场被裁掉了上下部分）。按等距模型，f = r_max / θ_max = 340 / (95°×π/180) = 340 / 1.658 ≈ 205像素。这个焦距值会作为标定初值交给优化器，初值给得准，优化收敛快而且不容易掉进局部极小。

实际标定的时候我们通常用带畸变项的多项式形式：r_d = θ + k1·θ³ + k2·θ⁵ + k3·θ⁷ + k4·θ⁹，然后乘以焦距f。这样既有鱼眼模型的物理合理性，又有足够的自由度拟合装配误差和镜片偏差。OpenCV里的fisheye模块用的就是这个形式，四个畸变系数够用，实测重投影误差能压到0.2像素以内。

2.2 内参标定的实操要点：标定板、姿态与采样分布

内参标定这一步，理论上是标准流程，实际上成败全在数据采集。我见过太多人拿十几张标定板全挤在画面中央的图去标，结果中心区域误差很小，边缘误差两三个像素，拼出来的全景边缘全是错位。

鱼眼标定的采样原则是"覆盖视场、覆盖姿态、覆盖距离"。视场上，标定板要出现在画面的中心、四角、四边中点，尤其是四个角和最外圈，这些地方畸变最大、最需要约束。姿态上，标定板要有明显的倾斜，俯仰、偏航、滚转各来几组，因为鱼眼模型的参数和姿态是耦合的，全是正对着的图会让某些参数不可观。距离上，至少要有近、中、远三档，近的到30厘米，远的到2米以上。数量上，一个相机25到40张比较稳妥，少于15张基本不要指望边缘精度。

标定板本身建议用大尺寸的棋盘格或者圆点阵，格距要足够大，保证在图像边缘也能占到足够像素。我们常用的是8×6格、方格边长60毫米的板子，如果相机安装位置够不到这么近，就换成100毫米的。检查点（圆点阵）比棋盘格在鱼眼上更稳，因为棋盘格的角点在强畸变区域会被压缩得很厉害，亚像素定位精度下降明显。

注意：标定前一定把镜头保护膜撕掉，听起来像废话，但我真的遇到过因为一层膜导致边缘畸变系数偏差、最后拼接缝差了两厘米的情况。另外镜头上如果有指纹或者水渍，会显著影响角点检测，标定前用无尘布擦一遍。

标定完成后不要只看重投影误差这个总数，一定要看误差的空间分布。把每张图的角点重投影误差画成热力图，如果误差集中在某个角落而且数值偏高，说明那个区域的采样不足，需要补拍。总误差0.3像素但边缘单点误差2像素的情况非常常见，这种数据拿去拼全景，接缝一定会出问题。

2.3 从鱼眼图到统一模型：映射表是怎么生成的

拿到内参和外参之后，生成映射表的过程其实是"反向查询"。不是从源图往目标图推，而是遍历目标画布上的每一个像素，反推它在源图上的位置。

以鸟瞰图为例，具体步骤是这样的。第一步，确定目标画布上一个像素 (u_b, v_b) 对应的物理地面坐标。假设画布的原点在车辆后轴中心的地面投影点，每像素代表1厘米，那么 (u_b, v_b) 直接换算成 (X_w, Y_w) = ((u_b - cx_b)·0.01, (v_b - cy_b)·0.01)，单位米。第二步，把地面点转到某个相机的坐标系下。这里用外参：P_cam = R·(P_world - t)，其中R和t是相机相对车体的旋转和平移，P_world = (X_w, Y_w, 0) 因为地面假设是Z=0平面。第三步，判断这个点是否在该相机的视场和有效距离范围内，如果不在就直接跳过，权重置零。第四步，对在范围内的点，用针孔模型投影到归一化平面：x = X_cam/Z_cam，y = Y_cam/Z_cam，然后 r = sqrt(x²+y²)，θ = atan(r)。第五步，用鱼眼畸变模型算出畸变后的半径 r_d，再乘以焦距得到像素坐标：u_s = fx·r_d·x/r + cx，v_s = fy·r_d·y/r + cy。第六步，检查 (u_s, v_s) 是否落在源图边界内，落了就记录到mapx/mapy，否则置为无效值。

这一整套运算对每个目标像素做一次，1024×1024就是一百万次，四路加起来四百万次，离线跑一次大概几秒钟，完全可以接受。做完之后记得做一次可视化验证：把mapx/mapy当成普通的映射对源图做remap，看看输出是不是一张正常的俯视图。这个中间结果非常重要，后面所有问题都能在这一步暴露。

2.4 有效区域裁剪与死区处理

鱼眼图像的边缘是最不可靠的，一方面畸变模型精度在那里最差，另一方面镜头边缘有暗角和分辨率下降，还有一些模组在最外圈有几个像素是纯黑的。所以映射表生成时必须做有效区域裁剪，通常是按半径裁，只保留 r < 0.95·r_max 的部分，再保守一点可以按实际测试定。

裁剪之后会出现一个问题：车身边缘附近的地面，可能落不到任何一个相机的有效区域内，形成死区。典型位置是四个角，尤其是前后保险杠外侧几十厘米的地方。这个死区在最终画面上表现为黑色或者空白，用户看到会觉得很奇怪。处理办法有两个，一是在画布设计时就把死区范围算进去，用车辆的3D模型或者一个半透明的车身剪影盖住；二是把画布边缘做一个渐变的羽化，让死区自然过渡到黑色，视觉上不突兀。量产方案基本都是前者，在画布上叠一个车模，既美观又能明确告诉用户"这块是我看不到的"。

3. 逆透视变换与鸟瞰图生成

3.1 地面平面假设：整个方案的基石与它的代价

逆透视变换能成立，全靠一个假设：车周的地面是一个水平平面，相机高度已知，姿态已知。有了这个假设，地面上任何一个点在世界坐标系里的Z坐标都是0，投影关系就从三维退化成了二维到二维的映射，可以用一个3×3的单应矩阵完整描述。

这个假设的代价必须说清楚。第一，地面不平的时候会有误差。上坡、下坡、路沿、减速带，这些地方的地面点实际高度不是0，投影到画布上会偏离正确位置，偏离量随高度和距离增大。粗略估一下：相机高度1.2米，一个高10厘米的路沿在5米外，投影误差大约是 10cm × (5/1.2) ≈ 40厘米，在画布上就是40个像素，非常明显。第二，立体物体完全失效。一辆旁边的车、一根柱子、一个行人，它们在画布上会被严重拉伸，变成一个奇怪的拖影。这是所有基于平面假设的环视系统的通病，不是代码bug。

工程上的应对是：把画布覆盖范围控制在车身周围2.5到3.5米，超出这个范围误差就不可接受了；对立体物体的拉伸不去做几何修正（做不了），而是靠用户教育，在说明书里明确"全景图为辅助参考"。有些方案会引入高度分层（把画布分成地面层和1米层两张图分别投影再融合），但这会显著增加复杂度和算力，一般只在高端方案里出现。

3.2 外参标定：四路相机怎么统一到一个坐标系

外参标定的目标是求每个相机相对车体坐标系的旋转矩阵R和平移向量t。车体坐标系一般定义在后轴中心的地面投影点，X轴向前，Y轴向左，Z轴向上（右手系）。

标定方法分两类。第一类是用标定场，地面上画好精确的标记点（比如四个角落的棋盘格或者特定图案），每个相机都能看到若干个已知世界坐标的点，用PnP或者直接优化重投影误差求解外参。这种方法精度最高，量产下线标定基本都用它，但需要专门的场地。第二类是用地面上的自然特征或者车辆自身的已知几何（比如车身线条），精度差一些，适合售后或者用户自助标定。

我这里重点讲第一类里最实用的做法：不用完整标定场，只用地面上的四条直线。具体思路是，在车身四周的地面上贴四条已知位置的直线（胶带就行），每条线至少被两个相邻相机同时看到。对每个相机，检测直线在图像上的方程，结合地面平面假设反算出这条线在相机坐标系下的三维位置，再用两条以上的线确定相机的位姿。这种方法的优点是场地要求低，缺点是只能约束到几个自由度，对旋转的约束不如点云强。

实际操作中更常见的是混合方案：地上摆几个已知间距的棋盘格，保证相邻相机有共视区域，每个相机至少看到两个棋盘格的部分角点。用这些角点做联合优化，把四个相机的外参和地面平面一起优化，同时约束相邻相机在重叠区的对齐误差。这个联合优化是关键，因为单独标每一路，各自的误差不相关，拼起来接缝就会有系统性偏差；联合优化把重叠区的对齐作为显式目标，能把这个偏差压下去。

3.3 单应矩阵的推导与数值实现

在已经有内参和外参的情况下，单应矩阵可以直接算出来，不用再做点对点拟合。推导如下：地面点在世界坐标是 P = (X, Y, 0, 1)，投到相机归一化平面是 p ~ K·[R|t]·P。把[R|t]按列拆成 r1, r2, r3 和 t，因为Z=0，第三列被消掉，得到 p ~ K·[r1 r2 t]·(X, Y, 1)^T。所以单应矩阵 H = K·[r1 r2 t]，是一个3×3矩阵。

这个式子告诉我们一件重要的事：H完全由内参、外参和地面平面决定，只要有准确的K、R、t，H就是精确的，不需要额外的拟合步骤。很多人喜欢用四对点做findHomography，那是因为他没有外参，只能靠点对点。有外参的情况下直接算更稳，因为避免了点检测误差的引入。

但实际项目里，外参会有一点点偏差（装配公差、悬挂高度变化），这时候可以做一个精修：用直接算出的H作为初值，在重叠区做图像配准，优化一个小的修正量。这个修正量建议只放开平移和旋转各一到两个自由度，不要全放开，否则容易过拟合到地面纹理上，导致远处变形。

数值实现上有几个坑。一是矩阵类型，用double算，最后再转float存表，用float算H再累乘误差会放大。二是归一化，H作用在齐次坐标上，算完要除以第三分量，第三分量接近0的点（也就是接近地平线的点）要直接丢弃，否则会得到巨大的坐标值。三是边界检查要在除法之后做，不要在之前做。

3.4 画布尺寸与分辨率怎么定：一次实打实的换算

画布设计是个纯工程问题，取决于你要看多远、要多清楚。假设车长4.7米、车宽1.85米，希望看到车身四周各2.5米的区域，那么画布覆盖的物理尺寸是 (4.7 + 5.0) × (1.85 + 5.0) = 9.7米 × 6.85米。考虑到画布通常是正方形（便于显示旋转和视角切换），取10米×10米。

接下来定分辨率。人眼在中控屏上分辨车位线，需要大约每厘米1个像素以上。10米=1000厘米，所以1000×1000像素起步。为了对齐硬件和SIMD，实际取1024×1024，则每像素对应 1000/1024 ≈ 0.977 厘米，差不多就是1厘米1像素。如果屏幕更大或者需要更精细，可以提到2048×2048，但内存和带宽会翻四倍，需要权衡。

这里有个容易被忽略的点：分辨率不能均匀分配。车身边缘区域是最需要看清的（那里是判断距离的关键），而远处可以糊一点。所以有些方案会用非均匀采样，中心区域密、外围稀，实现方式是在生成映射表时对物理坐标做一个非线性缩放。不过这种做法会让后面的距离测量变复杂，如果不是必须，建议先用均匀采样。

3.5 四路在画布上的布局与坐标约定

布局说白了就是决定前、后、左、右四路相机各自负责画布上的哪一块。听起来简单，实际上坐标约定不统一是联调阶段最常见的扯皮来源。

我的建议是在项目一开始就把约定写死并文档化：车体坐标系原点在后轴中心地面投影，X向前、Y向左、Z向上；画布坐标系原点在画布左上角，u向右、v向下；画布中心对应车体坐标系的原点（或者车辆几何中心，二选一，但要写清楚）。四个相机的安装位置用同一个坐标系描述，前视在 (2.3, 0, 0.75)，后视在 (-0.9, 0, 0.8)，左视在 (0.1, 1.0, 1.15)，右视在 (0.1, -1.0, 1.15)（数值仅为示意，实际以测量为准）。

有了这个约定，每路的有效区域就能直接算出来：对画布上每个像素，转到车体坐标，再转到各相机坐标，判断是否在视场内。落在多个相机视场内的像素就是重叠区，需要融合；只落在一个相机内的就是独占区，直接取值。这个判断逻辑在离线阶段完成，结果以权重图的形式存下来，在线阶段直接查。

4. 拼接融合与视觉一致性处理

4.1 重叠区到底有多大：先量再谈融合

融合策略的选择，前提是知道重叠区有多宽。四路190度鱼眼的相邻重叠角大约在10到30度之间（取决于安装位置和朝向），投影到地面上，重叠宽度通常在40到80厘米。这个宽度听起来不小，但在画布上也就40到80个像素，如果融合窗口开得太宽，会把两路的误差都摊进来，反而更糊。

测量方法很直接：生成映射表之后，把四路的有效区域掩码叠加，统计每个像素被几路覆盖。理想情况下，重叠区宽度均匀、分布对称。如果发现某一侧重叠特别窄，说明那个相机的安装角度或者外参有问题，应该回去查标定，而不是靠融合算法硬扛。

4.2 融合权重的三种做法与选择依据

第一种是硬切换，重叠区中间画一条线，左边取A右边取B。优点是快、无重影，缺点是那条线两侧会有明显的亮度跳变和几何错位，视觉上非常刺眼，除非你的标定精度极高（亚像素级），否则不建议。

第二种是线性加权，权重按到各自独占区的距离线性过渡。这是最常用的方案，实现简单，效果也够用。权重可以预先算好存在表里，在线只需两次乘加。缺点是如果两路图像本身有亮度差，线性融合会在重叠区形成一条渐变带，肉眼能看出"涂抹感"。

第三种是距离变换加羽化，用距离变换算出每个像素到各自有效区边界的距离，用这个距离做权重，再套一个平滑曲线（比如余弦或者smoothstep）。这种方法过渡最自然，代价是要多存一张距离图。我一般推荐这种，因为它在视觉上的收益明显大于那点内存开销。

具体实现上，权重归一化别忘了：w_A' = w_A/(w_A+w_B)，w_B' = 1 - w_A'。如果两路权重都为0（死区），直接输出黑或者车模。如果只有一个相机有效，权重直接置1，不要参与归一化，否则会出现暗边。

4.3 亮度与色彩一致性：让四路看起来像一台相机拍的

四路相机型号相同，但装配位置不同、朝向不同、镜头个体有差异，拍出来的图在亮度、色温、对比度上都会有区别。不做处理直接融合，接缝处就是一道明显的色带，非常影响观感。

处理方法分两步。第一步是离线求增益。在标定场地上，让四个相机同时拍一块均匀的灰色地面（或者专用的灰卡），计算每路图像在重叠区的平均亮度和平均色度，以某一路为基准，算出其余三路的RGB增益系数。增益可以全局一个，也可以分块（比如把图像分成4×4块，每块一个增益），分块能处理镜头暗角，但要注意块间平滑，否则会出现网格状痕迹。

第二步是在线做限制。增益系数不要直接用，要做一个限幅，比如限制在0.8到1.25之间，防止某一路因为遮挡或者强光导致增益算飞。更好的做法是用时间上的滑动平均，让增益缓慢变化，避免画面闪烁。

提示：亮度补偿只调增益不调伽马，是很多方案效果不佳的原因。镜头暗角是乘性衰减，增益能修；但模组的伽马曲线差异是加性的，需要单独做一次曲线匹配。实践中最省事的做法是在重叠区做直方图匹配，把B路的直方图拉到A路上，效果立竿见影，代价是多一点在线计算量。

4.4 拼接缝错位与"鬼影"的成因和处置

拼接缝错位表现为地面上的直线（车位线、砖缝）在接缝处断开、错位一个台阶。成因按出现频率排序：外参标定误差最大，其次是畸变模型不匹配，再其次是地面不平。

排查顺序建议这样：先看错位是系统性的还是局部的。系统性错位（所有接缝都往同一个方向偏）基本是外参的问题，回去重新标；局部错位（只有画面某个角落错）可能是那个区域的畸变拟合不好，考虑增加该区域的多项式阶数或者在映射表生成时做局部的残差补偿。如果错位随距离增大而加剧，那是地面平面假设的锅，只能缩小画布范围。

"鬼影"和错位不是一回事。鬼影是同一个物体在两路图像里都出现了，融合之后变成两个半透明的影子。典型场景是旁边的车辆、行人、柱子。这是几何上无解的，因为立体物体不满足地面平面假设。缓解办法是在重叠区做相似度检查，如果两路的局部纹理差异过大（说明看到的是不同高度的物体），就偏向取某一路而不是融合，减少重影的视觉干扰。但这种方法对算力有要求，一般只在高端方案里做。

5. 代码实现的关键环节与可复现骨架

5.1 工程结构与数据结构设计

我把整个工程分成三个模块：calib（离线标定）、table（映射表生成）、render（在线拼接）。calib输出相机内参和外参的YAML，table读取这些参数生成四张映射表和四张权重图，序列化成一个二进制文件，render在启动时加载这个文件，之后每帧只做remap和加权。

核心数据结构长这样：

// 单路相机的映射表，尺寸与输出画布一致 struct ViewLut { int width; // 画布宽度 int height; // 画布高度 std::vector<int16_t> mapx_q12; // Q12定点源图x坐标 std::vector<int16_t> mapy_q12; // Q12定点源图y坐标 std::vector<uint8_t> weight; // 0-255融合权重 int src_width; // 源图尺寸 int src_height; }; // 四路合成 struct SurroundLut { ViewLut views[4]; // 0:front 1:rear 2:left 3:right int canvas_width; int canvas_height; };

用int16存Q12的好处是内存减半、缓存友好，代价是要在remap时做一次移位。如果后面想接硬件加速，很多车规DSP的remap单元原生就吃定点坐标，这时候定点反而是优势。

5.2 离线映射表生成的代码骨架

这段是整个项目的灵魂，逻辑必须一条一条对上第2.3节的推导。

// 生成单路LUT：从画布像素反推源图坐标 void buildLut(const CameraParams& cam, const CanvasConfig& cfg, ViewLut& lut) { lut.width = cfg.canvas_w; lut.height = cfg.canvas_h; lut.mapx_q12.assign(cfg.canvas_w * cfg.canvas_h, -1); lut.mapy_q12.assign(cfg.canvas_w * cfg.canvas_h, -1); lut.weight.assign(cfg.canvas_w * cfg.canvas_h, 0); for (int v = 0; v < cfg.canvas_h; ++v) { for (int u = 0; u < cfg.canvas_w; ++u) { // 1. 画布像素 -> 车体坐标系下的地面点（单位：米） double Xw = (u - cfg.origin_u) * cfg.meter_per_pixel; double Yw = (v - cfg.origin_v) * cfg.meter_per_pixel; // 2. 车体坐标 -> 相机坐标 Eigen::Vector3d Pw(Xw, Yw, 0.0); Eigen::Vector3d Pc = cam.R * (Pw - cam.t); if (Pc.z() <= 0.05) continue; // 点在相机后方或过近 // 3. 针孔归一化 double x = Pc.x() / Pc.z(); double y = Pc.y() / Pc.z(); double r = std::sqrt(x * x + y * y); double theta = std::atan(r); // 4. 鱼眼畸变（等距模型 + 多项式修正） double t2 = theta * theta; double rd = theta * (1.0 + cam.k1 * t2 + cam.k2 * t2 * t2 + cam.k3 * t2 * t2 * t2); // 5. 归一化 -> 像素 double scale = (r > 1e-9) ? rd / r : 0.0; double us = cam.fx * x * scale + cam.cx; double vs = cam.fy * y * scale + cam.cy; // 6. 边界与有效圆检查 if (us < 1 || vs < 1 || us > cam.width - 2 || vs > cam.height - 2) continue; double du = us - cam.cx, dv = vs - cam.cy; if (std::sqrt(du * du + dv * dv) > cam.valid_radius) continue; int idx = v * cfg.canvas_w + u; lut.mapx_q12[idx] = static_cast<int16_t>(std::lround(us * 4096.0)); lut.mapy_q12[idx] = static_cast<int16_t>(std::lround(vs * 4096.0)); lut.weight[idx] = 255; // 权重留给后处理统一生成 } } }

权重不要在这里定死，因为权重需要知道四路的覆盖关系才能算。正确顺序是先把四路的有效性图都生成出来，再统一做一次"覆盖计数 + 距离变换 + 归一化"，这样重叠区才能正确分摊。

5.3 在线拼接主循环：把每帧的活儿压到最少

在线部分的目标是"零分支、少拷贝"。基本流程是：把四路源图转成统一的格式（建议内部统一用RGB888或者YUV420的Y分量单独处理），然后对每个目标像素，遍历覆盖它的相机，取颜色乘权重累加。

void renderFrame(const SurroundLut& lut, const uint8_t* const src[4], uint8_t* dst, int dst_stride) { for (int v = 0; v < lut.canvas_height; ++v) { uint8_t* row = dst + v * dst_stride; for (int u = 0; u < lut.canvas_width; ++u) { int idx = v * lut.canvas_width + u; int accR = 0, accG = 0, accB = 0, accW = 0; for (int k = 0; k < 4; ++k) { const ViewLut& L = lut.views[k]; int w = L.weight[idx]; if (w == 0) continue; // Q12 还原为浮点坐标 float sx = L.mapx_q12[idx] / 4096.0f; float sy = L.mapy_q12[idx] / 4096.0f; // 双线性采样 int x0 = (int)sx, y0 = (int)sy; float ax = sx - x0, ay = sy - y0; const uint8_t* p = src[k] + y0 * L.src_width * 3 + x0 * 3; for (int c = 0; c < 3; ++c) { float v00 = p[c]; float v01 = p[3 + c]; float v10 = p[L.src_width * 3 + c]; float v11 = p[L.src_width * 3 + 3 + c]; float val = v00 * (1-ax) * (1-ay) + v01 * ax * (1-ay) + v10 * (1-ax) * ay + v11 * ax * ay; // 乘权重累加，这里简化处理，实际按通道分开 if (c == 0) accR += (int)(val * w); if (c == 1) accG += (int)(val * w); if (c == 2) accB += (int)(val * w); } accW += w; } if (accW > 0) { row[u*3+0] = (uint8_t)(accR / accW); row[u*3+1] = (uint8_t)(accG / accW); row[u*3+2] = (uint8_t)(accB / accW); } else { row[u*3+0] = row[u*3+1] = row[u*3+2] = 0; } } } }

这段代码是能跑的，但性能很朴素。实测1024×1024画布、四路全部参与，在普通x86上一帧大概20到30毫秒。要压到10毫秒以内，需要做三件事，见下一节。

5.4 性能优化的三个有效手段

第一是预计算权重归一化。上面代码里每帧都在做除法，其实权重图离线就能归一化成0到255的整数，四路加起来正好255，在线只做乘加不做除。这一步能省掉大量整数除法，在嵌入式上收益特别大。

第二是分块跳过。大部分画布像素其实只被一个相机覆盖，独占区根本不需要走四路循环。可以在离线阶段生成一张"覆盖掩码"，把独占区、双覆盖区、三覆盖区分开，在线时分块处理：独占区直接remap，双覆盖区才走加权。实测这一招能减少60%以上的计算。

第三是向量化。双线性采样的四个点和权重计算非常适合SIMD，把R、G、B三个通道打包成一次处理，或者把相邻四个像素打包，都能获得两到三倍的加速。如果是ARM平台，NEON指令集对这类操作支持很好；如果是DSP，直接调它的图像处理库。

还有一个工程手段是降低画布分辨率的内部处理。比如内部按512×512拼接，输出时再上采样到1024×1024，画质损失在可接受范围内，计算量降到四分之一。这个取舍要看具体产品的屏幕尺寸，屏幕小的时候完全没必要做高分辨率。

6. 常见问题与排查技巧实录

6.1 一张速查表：从现象定位到根因

我把这些年遇到的问题整理成表，遇到现象先查表，能省掉大量瞎猜的时间。

6.2 三个踩过的坑，都是文档里不会写的

第一个坑是标定时的温度。镜头模组有热胀冷缩，尤其是塑料镜筒的模组，在低温下焦距会变，标定在25度做，装车后在零下十几度跑，接缝就错位了。后来我们的做法是在标定时记录温度，如果产品工作温度跨度大，就在高低温箱里各标一次，做两组参数，在线按温度传感器切换或者插值。这个细节如果不在项目早期考虑到，后期返工成本极高。

第二个坑是映射表的边界处理。mapx/mapy存在边界外的值时，如果直接拿去remap，不同实现的行为不一样，有的会做镜像填充，有的会填0，结果就是画布边缘出现一圈奇怪的彩色条纹。正确的做法是在生成LUT时对越界点显式置为-1，在线采样时判断到-1就跳过，权重置0。这个bug我们查了两天才定位到，因为它在大部分场景下都不出现，只在特定角度才冒出来。

第三个坑是四路的时间同步。如果四路图像不是同一时刻采集的，车辆在移动时，四路看到的场景有细微差异，拼出来的接缝会随着车速变化而抖动。这个现象很容易被误判成标定问题，实际上硬件同步没做好。排查方法很简单：把车停在原地拍，如果接缝是稳的，一开动就抖，那就是同步的问题，跟标定无关。硬件上要靠同一个触发信号给四个模组，软件上要有帧号对齐机制。

6.3 一个容易被忽略的小技巧：拼接质量的自检工具

最后分享一个我们在项目里做的自检工具，非常省事。做法是：在地上摆一块印着标准方格的大布（或者直接在标定场地上用），让车停上去，然后用这套系统输出全景图，程序自动检测画布上的方格线，测量每个交点相对理想位置的偏移量，输出一张误差热力图。

这张图能一次性告诉你三件事：哪条接缝错位最大、错位是系统性还是局部性、误差随距离怎么增长。有了它，标定完了不用靠肉眼判断，直接看数值，误差超过阈值的区域自动标红。我们在一个项目里靠这个工具发现左视相机的外参标定数据用错了文件，肉眼根本看不出来，因为错位只有8个像素，但方格图上非常明显。

注意：自检工具的阈值设定要结合画布分辨率。1厘米1像素的画布，接缝错位控制在3像素以内基本不可见，超过5像素用户就能察觉。别拿亚像素的标准去要求一套环视系统，性价比不对。

我个人在实际操作中的体会是，环视拼接这活儿，八成的时间要花在标定和验证上，代码本身写起来反而快。前期把坐标系约定、映射表格式、自检工具这三件事定死，后面调参就是个体力活；这三件事要是含糊过去，后面每改一次参数都要重新怀疑一遍人生。