企业官网建设流程全解析

1. 项目概述与整体思路

先说结论：这个项目的名字叫"gods-eye-view"，说白了就是"上帝视角"。它不是某个商业软件的名字，而是我自己折腾的一个技术探索项目，目标是让普通的消费级设备（无人机、运动相机、手机）拍出来的片段，最终变成一张无缝的、可以从高空俯瞰全局的俯视图，甚至是一套小范围的实时航拍全景拼接系统。听起来高大上，但核心就三件事：采集、拼接、呈现。

"上帝视角"这个词在互联网上火过一阵，很多人拿它指代游戏里的俯视视角，也有人用它形容监控系统的"鸟瞰图"。但真正放到图像处理和计算机视觉领域，它对应的是两个非常硬核的技术方向：一是多路图像/视频的全景拼接（Panorama Stitching），二是鸟瞰图视角变换（Bird's Eye View，简称BEV）。当你想用几台不同角度的摄像机或无人机飞一圈，最终得到一张"像上帝从天上往下看"的完整画面时，你就同时踩中了这两个方向。

这篇文章不是复刻某个商业全景相机，而是从零开始，用OpenCV和Python实现一套可落地的流程：先用无人机航拍一段覆盖目标区域的视频（或者用多个固定摄像头采集多路画面），然后通过特征点匹配、透视变换、图像融合等步骤，把它们拼成一张完整的俯视全景图，再进一步完成坐标标定和实时监控。整套流程跑通之后，你可以把它用到航拍测绘辅助、比赛/活动场地的全局监控、工地安全巡检、停车场车辆调度等场景里，也可以单纯用来做一个炫酷的个人项目。

适合谁来看？如果你对OpenCV有一定了解，想深入理解图像配准和透视变换原理；或者你手头正好有无人机/摄像头，想找个玩法把它们变成生产力工具；再或者你就是对"上帝视角"这种视觉效果感兴趣，想搞明白原理——这篇内容都可以给你一个完整的路子，包括踩过的坑和调参心得。

2. 关键技术选型与设计思路

2.1 为什么是"全景拼接 + BEV变换"而不是直接买全景相机

市面上有现成的全景相机，比如Insta360这类，拍完直接出全景图。但它们的全景是"球面全景"，也就是以相机为中心的360度环视，视角是"从内往外看"的；而"上帝视角"要的是"从外往内俯瞰"，画面里的地物必须保持真实的地理相对位置关系，这是一个"平面映射"问题。球面全景和俯视平面图之间还差着一个关键步骤——俯视变换/矫正。

另一个思路是直接用卫星图或在线地图的卫星影像，但这类数据有两个硬伤：分辨率不够（通常达不到施工级或监控级清晰度），更新滞后（可能是一年甚至更久前的画面）。无人机航拍加实时拼接则能拿到"当下这一刻"的高清俯视图，这是卫星方案做不到的。

所以我最终确定的技术路线是：Python + OpenCV作为图像处理主引擎，无人机视频/多路RTSP摄像头作为采集源，SIFT/ORB特征提取做图像配准，透视矩阵（Homography）做视角变换，加权融合或Multi-Band Blending做图像拼接。这套组合的好处是全部开源、上手成本低、可定制性强，而且不用依托任何云平台，数据完全本地处理，安全可控。

2.2 核心流程拆解：从视频流到全景图的四步走

整个"上帝视角"的实现链路可以拆成四个阶段，每个阶段都有明确的输入输出：

• 阶段一：数据采集。通过无人机航线规划拍一段覆盖目标区域的视频，或者架设多台不同角度的相机，确保相邻画面之间有30%~50%的重叠区域。重叠太少，后续特征点匹配会翻车；重叠太多，计算量又上去了。经验值，相邻画面重叠40%左右最舒服。
• 阶段二：关键帧提取与预处理。视频流不能直接拿去拼接，一是帧率太高计算量爆炸，二是运动模糊会毁掉特征点。所以先做抽帧，用相邻帧的相似度做筛选，选出一组质量稳定、互为"标签帧"的图像；然后做去畸变、亮度均衡、降噪。
• 阶段三：图像配准与拼接。对每相邻两张图提取特征点，用最近邻匹配、RANSAC求单应矩阵，然后通过矩阵变换把后一张图映射到前一张图的坐标系下，最后做曝光补偿和多频段融合，消除拼接缝。
• 阶段四：坐标标定与输出。如果是固定场景的监控，可以在拼接后的全景图上标定几个已知坐标的参考点，做像素坐标到真实世界坐标（比如经纬度或平面坐标）的换算。这样你点击全景图上的任意位置，就能得到它的实际位置信息，这才是名副其实的"上帝视角"。

后面几个小节，我会把每个阶段涉及的原理和实操细节展开讲清楚。

3. 核心算法原理与实操细节

3.1 特征点检测与匹配：SIFT、ORB怎么选

图像拼接的根基是"找到两张图里同一个物理位置的像素点对"。这就要依赖特征点检测算法。OpenCV里常用的有三件套：SIFT、SURF、ORB。

SIFT（尺度不变特征变换）的匹配精度在大多数场景下是最好的，对旋转、缩放、光照变化都有很强的鲁棒性。但它有两个问题：一是算法本身受专利保护（虽然过期了），二是计算量大，实时性不够，在手机上跑不动。SURF是SIFT的加速版，原理类似，速度稍快，但精度略降。ORB是纯开源的，速度非常快，适合实时视频流，但在弱纹理区域和光照变化剧烈的场景下，匹配质量会明显下降。

我的取舍原则是这样的：如果做离线拼接（比如无人机飞完一圈再处理），无脑用SIFT，精度优先；如果做实时拼接（多路摄像头，每帧都要拼），用ORB并把特征点数量卡在上限500~1000，然后用FLANN做快速最近邻搜索，再把匹配阈值调严。实测下来，ORB+FLANN在720P分辨率的实时拼接上能做到10帧左右，足够监控类场景使用。

import cv2 def detect_and_match(img1, img2, method='SIFT'): if method == 'SIFT': detector = cv2.SIFT_create() norm = cv2.NORM_L2 elif method == 'ORB': detector = cv2.ORB_create(nfeatures=1000, scaleFactor=1.2, nlevels=8) norm = cv2.NORM_HAMMING else: raise ValueError('unknown method') kp1, des1 = detector.detectAndCompute(img1, None) kp2, des2 = detector.detectAndCompute(img2, None) if len(kp1) < 10 or len(kp2) < 10: return None, None, None, None if method == 'SIFT': matcher = cv2.FlannBasedMatcher(dict(algorithm=1, trees=5), dict(checks=50)) else: matcher = cv2.BFMatcher(norm) raw_matches = matcher.knnMatch(des1, des2, k=2) good = [] for m, n in raw_matches: if m.distance < 0.75 * n.distance: good.append(m) if len(good) < 8: return None, None, None, None src_pts = np.float32([kp1[m.queryIdx].pt for m in good]).reshape(-1, 1, 2) dst_pts = np.float32([kp2[m.trainIdx].pt for m in good]).reshape(-1, 1, 2) return src_pts, dst_pts, kp1, kp2

刚才代码里用了最近邻距离比来筛选匹配对，ratio参数取0.75是Lowe在SIFT原论文里给出的经验值，意思是如果最佳匹配的距离不到次佳匹配的0.75倍，才认为这是可靠的匹配，否则两个特征点都太接近，很可能对应的是重复纹理区域。这个参数在ORB里也可以直接用。

3.2 Homography矩阵求解：透视变换的"灵魂"

找到匹配点对之后，下一步是求解单应矩阵H。一个H矩阵可以把一张图像里所有像素点通过透视变换映射到另一张图像对应的位置上。它的物理意义是：假设拍摄的场景是平面，或者相机只做纯旋转运动，那么两张图之间的对应关系可以用一个3x3矩阵精确描述。

求解H矩阵至少需要4对匹配点，但实际过程中匹配点对里一定混着误匹配的"坏点"，直接用最小二乘会翻车。所以要用RANSAC（随机采样一致性算法）：每次随机挑4对点求一个候选H，然后看其他匹配点对在这个H下的投影误差，误差小于阈值的算"内点"，反复迭代几百次，找到内点最多的那个H作为最终结果。

这个过程在OpenCV里只要一行代码：

H, mask = cv2.findHomography(src_pts, dst_pts, cv2.RANSAC, 5.0)

那个5.0是投影误差的像素阈值，越小要求越严格，匹配质量差的时候建议放松到8~10；质量好的时候收紧到3~4效果更干净。我踩过的最典型的坑是：在纹理稀疏的大片草地上航拍，特征点数量本来就少，RANSAC还总被误匹配带偏，后来加了一个条件——内点比例低于40%就放弃这张图，重新抽下一帧，拼接质量瞬间稳定了。

透视矩阵H求解完成后，拼接的核心就是利用OpenCV的warpPerspective把后一张图变换到前一张图的坐标系，然后合在一起。不过实操中还有一个细节：直接拼接的结果曝光差异会非常明显，尤其无人机在夕阳下转弯时，两张相邻帧的亮度可能差一大截。缝合线处一旦出现明显的明暗跳跃，整个全景图看起来就会非常假。所以还需要做曝光补偿和多频段融合，这部分我在下一节细说。

3.3 拼接的细节工程：曝光补偿与融合

多图拼接的最终效果好不好，七八成取决于融合，而不是配准。就算特征点匹配、透视变换都做对了，只要曝光不一致、接缝明显，成品就"低级"。原始的简单做法是加权平均融合：在两张图的重叠区域里，越靠近左边图权重越大，越靠近右边图权重越小，这样能做出一个平滑过渡。但问题是，如果两张图的曝光差异很大，过渡区域会像一块脏抹布，灰蒙蒙的。

更好的方案是OpenCV的exposureCompensate做曝光补偿，再加上Multi-Band Blending多频段融合。后者的核心思想是：把图像按频段拆开，低频部分（画面整体的颜色、明暗）做大幅度的平滑过渡，高频部分（纹理、边缘细节）只在一条很窄的缝合线附近做过渡。这样拼接结果既没有明显的接缝，细节也不会被破坏。

Multi-Band Blending在OpenCV的stitching模块里是内置的，但如果你不想用整个stitching API，自己实现也不难，原理就是拉普拉斯金字塔分解、按权重融合、再重建。我在项目里图省事，直接用了stitcher类，但关闭了他自带的裁剪，因为自动化裁剪经常把图裁歪。

stitcher = cv2.Stitcher_create(cv2.Stitcher_PANORAMA) # 关闭自动裁剪，后面手动处理 stitcher.setPanoConfidenceThresh(0.5) status, pano = stitcher.stitch(images)

不过这里要提一句：Stitcher_create的PANORAMA模式，在高清大图、图片数量又多的情况下，内存占用非常夸张。我之前用12张4000x3000的无人机照片跑拼接，16GB内存的电脑直接卡死。后来改成"增量拼接"：每次只拿相邻两张来拼，拼完的结果再和下一张拼，内存占用直线下降，而且出错的定位也更方便。

4. BEV视角变换与坐标标定

4.1 为什么纯拼接还不够：从"斜视"到"俯视"的最后一米

全景拼接做完，你得到的是一张"空中视角"的图，但严格来说，它还不是"上帝视角"——因为无人机或摄像头的镜头往往不是垂直向下拍的，画面会带透视倾斜。远处的物体会变小，近处的物体会变大，远处的道路看起来是斜的。要让画面变成真正的"从上往下垂直看"，需要做BEV变换，也就是把侧视角图像投影到地面平面。

数学上，这是用一个3x3的单应矩阵完成的（跟拼接用的H矩阵同宗同源，但物理含义不同）。你需要提前标定地面上的4个点，然后把这4个点映射到平面图上对应的位置。OpenCV里的getPerspectiveTransform就是干这个的，它只需要4组对应点。

src_pts = np.float32([[x1, y1], [x2, y2], [x3, y3], [x4, y4]]) # 在斜视角图里的坐标 dst_pts = np.float32([[0, 0], [width, 0], [width, height], [0, height]]) # 俯视图的坐标 M = cv2.getPerspectiveTransform(src_pts, dst_pts) bird_view = cv2.warpPerspective(image, M, (width, height))

听起来简单，实际操作里最难的是选好4个参考点。如果在固定摄像头场景下，你可以直接在画面里找4个已知距离的地面特征点（比如停车位的四个角、篮球场的两条边线交点）；如果是无人机场景，那就需要RTK级别的定位信息，或者在目标区域先布设地面控制点（GCP），用GPS测好坐标，再在图像上找到对应的像素位置。

4.2 坐标标定的实战方案：从像素到现实世界

BEV变换出来的图像，本质上是一个"以像素为单位"的理想平面图，但监控和巡检需求想知道的是"这条车道离我多远"、"那个设备在哪个经纬度"。所以还需要最后一步：把像素坐标映射到现实世界的米制坐标或经纬度坐标。

固定监控场景下，我用的是一个简单的线性标定法：在BEV图上找两个已知真实距离的点，算出"每像素对应多少米"的比例，再根据一个已知的参考点（比如某个角落的经纬度）算出所有点的偏移。这个方法在平坦场地上完全够用，误差可以控制在2%以内。复杂地形（有坡度）就得用GIS那套方案了，比如用相机内外参做地面点投影，但那就是更重的工程了，普通场景不太需要。

这里说一个我实测下来的心得：BEV变换最怕的不是算法，而是场景本身不平坦。如果地面有坡，哪怕只是轻微起伏，远处像素的映射误差就会指数级放大。有一次我在看台边上架设监控，看台本身是个斜面，画出来的俯视图车辆位置明显偏移，后来把参考点全布在看台正下方的平地区域，勉强补救。所以如果场地不平，别硬上，老老实实多布几个GCP做分区变换。

5. 实测过程与完整操作指南

5.1 硬件准备与环境搭建：一顿能跑的配置清单

先列一下我实际跑通这套系统时用的硬件，都是比较容易买到的设备，总成本可控：

• 无人机：大疆Mini系列这类轻便机型即可，带GPS。如果纯粹测试拼接算法，其实用手机拍也行，但无人机的好处是能保持大致恒定的高度，画面遮挡少。注意飞行时要开启"网格线"辅助，保持航线重叠率。
• 固定摄像头（可选）：海康或大华的RTSP网络摄像头，支持HTTP拉流即可。我用了4个700线同轴改装的网络头，目的是测试"多路实时拼接"的场景。
• 电脑：CPU i5以上，内存建议16GB以上。拼接高清大图时内存是最大的瓶颈。如果要用Multi-Band Blending，建议内存32GB起。
• Python环境：Python 3.9，OpenCV 4.5以上版本，numpy，imutils。装OpenCV时选择opencv-contrib-python这个包，SIFT和ORB都在里面。

环境搭建里最容易出问题的是OpenCV的版本，SIFT在4.4之后的版本需要把contrib模块一起装。而且当时那个包管理器装完默认可能不带SIFT，需要显式指定版本，建议直接：

pip install opencv-contrib-python==4.8.1.78

5.2 无人机航线采集：重叠率怎么定、飞多高合适

用无人机做"上帝视角"采集，航线设计直接决定后续拼接成败。关键参数就两个：飞行高度和航线间距。高度决定地面分辨率，间距决定重叠率。飞行高度越高，单张图覆盖范围越大，但地面物体越小；间距越小，重叠率越高，拼接越稳定，但需要飞的张数越多。

我常用的一套参数是：飞行高度80米，照片尺寸4000x3000像素，单张覆盖地面大约200米x150米，航线间距设定在100米左右，这样相邻航线的重叠率大约在50%。画幅方向让相机保持90度正下视（正射投影），如果带着云台稍微歪了角度，对单图拼接的影响不大，但做BEV变换时误差会放大，所以尽量保持正下视。

实际操作用大疆的航线规划app（比如Pilot或第三方DJI Pilot 2），选"正射影像采集"模式，输入重叠率，app会自动生成航线并逐点拍照。如果没有航线规划功能，手动飞也行，但一定要保持高度稳定，避免忽高忽低导致地面分辨率不一致。

5.3 实时多路摄像头拼接演示：RTSP拉流、关键帧同步

固定监控场景下，多路摄像头画面的拼接是更"细粮"的活儿，因为摄像头之间的视角变换是固定的，不用每次重新求H矩阵。实操时我先用统一的RTSP地址拉流，把四路画面分别转成灰度图，然后用同一个地面标定板求出四个画面到主视角的映射矩阵，存下来。之后每一帧只需要应用这4个矩阵做warp，然后把它们叠到一张大的画布上，配合加权融合就能实现近乎实时的俯视拼接。

这个思路的核心是"一次性求矩阵，之后只做变换"。在jetson nano或树莓派这类小计算平台上，720P四路的拼接能跑到15帧每秒。真正拖慢实时性的不是变换本身，而是RTSP解码。我把解码分辨率限制到960x540，再配合硬件解码，性能一下就上来了。如果你也想跑实时，记住：分辨率优先降，别让解码把CPU耗尽。

import cv2 captures = [cv2.VideoCapture(rtsp_url) for rtsp_url in rtsp_urls] Hs = [np.load(f'homography_{i}.npy') for i in range(len(rtsp_urls))] while True: frames = [] for cap in captures: ret, frame = cap.read() if ret: frames.append(frame) if len(frames) < len(captures): continue warped = [cv2.warpPerspective(f, H, (pano_w, pano_h)) for f, H in zip(frames, Hs)] # 简单加权融合 pano = np.zeros((pano_h, pano_w, 3), dtype=np.uint8) for i, w in enumerate(warped): mask = (w > 0).astype(np.float32) pano = pano + w * mask / max(1, sum(mask)) cv2.imshow('gods_eye_view', pano.astype(np.uint8)) if cv2.waitKey(1) & 0xFF == ord('q'): break

实时拼接的隐患在于多路摄像头之间的"帧同步"，四路摄像头如果各自的网络延迟不一致，画面上同一辆运动的小车就会出现"左右分魂"的问题，在拼接缝附近尤其明显。我当时用RTSP的套接字缓冲做了软同步，把每个摄像头的数据包时间戳对齐后再送进算法，误差控制在50毫秒以内。如果你用USB直连的工业相机，硬件触发是最好的方案；用网络摄像头的话，就只能做软同步了。

5.4 调参与参数保存：记录下我实测的一组可靠配置

说到调参，各种参数看起来虽多，但最终能用的就那么一套。我把常用参数和推荐值整理成了表格，方便大家拿来就用：

其中"抽帧间隔"是视频拼接里最容易忽视的。如果你拿一段无人机飞行的视频直接做"逐帧拼接"，大概率会失败，因为相邻帧的画面重叠太多，特征匹配虽然容易，但累计误差会非常大；间隔太大又会导致重叠率不足。我的经验是：先手动或脚本估算一下飞行速度，保证抽出来的帧与帧之间有40%左右的重叠就行。如果飞行速度慢，帧间隔拉大；速度快，帧间隔缩小。

6. 常见问题与踩坑实录

6.1 拼接结果出现明显错位、重影

这是最高频的问题，90%是因为特征点匹配质量不过关。排查思路分三步：第一步，可视化匹配点对，如果看到大量交叉、乱连的连线，说明匹配本身就不靠谱，去调整ratio阈值或换成SIFT；第二步，检查RANSAC内点比例，如果内点比例低于50%，说明匹配对里坏点太多，需要提高阈值或增加图像重叠；第三步，确认图像没有强烈的运动模糊，无人机转弯时拍的照片经常糊，宁可丢帧也别拿模糊图硬拼。

重影另一个隐蔽来源是"视差"，也就是场景里有明显的立体物体（比如高楼、电线杆），从不同角度看过去，物体的投影位置会变化，而单应矩阵假设场景是平面的，解决不了视差问题。我的处理办法是：拼接前把画面中明显突出地面的目标区域用mask剔除掉，或者保证无人机轨道的平移量足够小，让视差控制在可接受范围内。

6.2 曝光差异明显，拼接缝"阴阳脸"

这个问题在夕阳、背光场景下尤其严重。最直观的处理是用曝光补偿算法先估算两张图的重叠区域亮度差，然后整体调整其中一张的亮度。但真正的解法是"采集时就做好控制"：如果飞无人机，尽量在光线稳定、光照柔和的时段采集，避开中午强阴影和日落时的低角度光；如果架设多路摄像头，统一白平衡和手动曝光值，不要在自动模式下让每个摄像头自己调节。

万一已经拍完才发现曝光不一样，融合阶段用Multi-Band Blending能救回80%。但要注意，Multi-Band Blending只在重叠区域内平滑过渡，如果重叠区之外的亮度本身就差异巨大，拼出来依然会不自然。

6.3 实时拼接延迟高、卡顿

实时性瓶颈通常不在算法在I/O。先用profile工具看耗时分布：如果是解码耗时高，就降低分辨率或开启硬件解码；如果是特征提取耗时高，就换ORB并限制特征点数量；如果是拼接矩阵warp耗时高，就先用小分辨率跑通流程，再上调。另外，实时拼接如果不需要每帧都重新求H矩阵，一定要把H矩阵缓存下来，只在画面切换到新的场景时才重新计算。这个缓存优化能直接把耗时从每帧80毫秒降到15毫秒左右。

6.4 一个让我记忆犹新的调试经历

最让我头痛的问题出现在无人机视频拼接中，拼接出来的全景图整体看起来正常，但放大看会有一个微妙的锯齿状扭曲，仿佛整张图被"搓"了一下。当时我换了好几种特征点算法都无解，最后才意识到是"累计误差"在作妖——每拼一张图都会引入一点点误差，拼到第10张时误差已经积累到肉眼可见的程度。

解决方案是引入"图优化"（Bundle Adjustment）：在拼接过程中不按顺序一张接一张地拼，而是每隔几帧就回头用全局信息对已经算好的H矩阵做一次整体微调，把累积误差拉回来。OpenCV的stitching模块内部已经包含类似机制，但它隐藏了细节，所以效果不稳。后来我改用了"两两匹配 + 全局坐标统一"的两步法：先算出所有相邻图之间的H矩阵，再用最小二乘把这些局部变换统一到同一坐标系下，误差被平均分摊，出来的全景图就干净了。

7. 项目扩展与应用方向

这套"上帝视角"系统做出来以后，能玩的方向不只是拼图炫技。我整理一下自己已经测过和正在做的几个扩展方向，供大家参考：

• 场地活动监控：在足球赛、马拉松、音乐节等场景，用两三个摄像机位拼出一张全场实时俯视图，后台人员可以一眼看到人多聚集的区域，判断是否需要疏导。这比盯着几十个分屏效率高太多。
• 工地安全巡检：无人机每天定时飞一圈，拼出当天施工现场的全景图，对比前一天的图，就能自动检测出材料堆放的变动、新开挖的区域，甚至判断某些危险区域的边界是否被突破。配合变化检测算法，这比人眼巡检可靠得多。
• 农业长势评估：多光谱版本的话还在测试，但普通RGB拼接已经可以用来评估大面积农田的覆盖度、倒伏区域，以及判断灌溉是否均匀。周末去农田飞一圈，回来拼一张高清俯视图，比自己走近去看直观得多。
• 车库/物流仓库管理：多路固定摄像头实时拼接后，叠加车牌识别或货物id识别，就能在一个界面里掌握整个场地的车辆货物情况。同理，大型停车场完全可以用6到8个摄像头拼接出一张"上帝视角"总览图，哪个车位空着、哪条通道堵了，一目了然。

如果想把"上帝视角"做成产品级，还需要解决一个硬件问题：多路摄像头的同步性，特别是运动目标的实时跟踪，需要所有摄像头在同一时刻采集画面。不然拼接出的动态画面会撕裂。软件能做的只是时间戳同步，硬件触发才是一劳永逸的办法。

8. 写在最后的几点实操心得

项目做到后面，最大的体会是：这类图像处理项目的难点不在数学公式，而是在数据质量和参数调试上。公式大家都在书上、文档里看过，但真实场景里的灰尘、反光、雾霾、飞鸟遮挡、电线杆干扰、无人机抖动，每一个都能让你的算法挂掉。算法只是工具箱，真正重要的是你在现场处理这些脏数据的经验。

整个"gods-eye-view"项目从接到想法到第一版跑通，前后花了两周，绝大部分时间都耗在调参和数据清洗上。如果你也要做类似的项目，我的建议是先别急着上大而全的实时系统，而是先把离线拼接的Pipeline走通、把参数摸透，再往实时方向走。因为离线你能看到每一张中间结果，出错容易定位；实时系统把一切封在一起，一旦出错，你根本不知道是采集、传输、解码还是拼接的问题。

另外一点很实用：代码里所有矩阵、所有中间图像都记得存盘，无论是调试还是复现，都省时省力。我后来处理一个客户的航拍拼接需求，能在10分钟内快速定位问题，就是因为第一次做时保留了每一步的缓存数据。

最后，还是那句话：多动手，少空想。拼图软件多得是，但你亲手从零跑通一个Pipeline之后，你才算真正理解"上帝视角"这四个字背后，每一块像素是怎么落位的。