简介：本资源是一个基于QGIS平台二次开发的遥感图像云检测与地物信息恢复集成系统，面向遥感、GIS及数字图像处理领域的开发者、科研人员与高年级本科生，解决遥感影像预处理中云层干扰识别难、遮挡区域地物信息难以重建的核心问题。压缩包共76个文件，含21个核心Python源码（如main.py、MyMainWin.py、各类算法线程模块）、5个Qt Designer设计的.ui界面文件、7个图标与界面资源图（png/ico）、5个XML配置及国际化qm文件，以及遥感数据样例（tif）、算法参数配置（json）和详细说明文档（docx/md），整体大小为51.24MB。已有70人学习下载，资源结构清晰分层：涵盖QGIS菜单集成（qgisMenu.py）、多源遥感大气校正（GF1/Landsat8专用对话框）、波段组合与辐射定标线程、深度学习模型调用接口雏形及UI交互逻辑，提供可直接运行的桌面端原型系统，具备算法替换、流程可视化与模块化扩展能力，是开展遥感智能处理二次开发实践的优质工程参考。 我做了几年的遥感影像处理，最头疼的就是碰到带云的影像。光学卫星影像只要天气不好，云层一盖，下面全是废数据。以前处理云遮挡，要么在ENVI里人工勾选、要么拿PS一点一点修，遇到大范围测区，几十景影像光去云就能耗掉两三天。后来我干脆基于QGIS做了一套二次开发系统，把云检测和地物恢复整个流程串起来，日常处理效率提升非常明显。今天把这套系统的设计思路和实现细节梳理出来，给同样踩过这个坑的同学做个参考。
这套系统解决的核心问题很简单：给一副带云遥感影像，自动把云和云影检测出来，然后用合理的方式把云遮挡下的地物信息恢复出来，最终产出一幅可用、可入库、可分析的“无云”影像。适用于Landsat、Sentinel-2、高分系列等常见光学遥感数据，不管是做土地利用分类、植被监测还是影像镶嵌，都有实用价值。适合有一定遥感基础、想在QGIS环境下做定制工具的开发者。
1. 项目整体设计与架构选型
1.1 为什么选QGIS作为二次开发平台
先说结论：QGIS做遥感影像二次开发底座，是当前开源技术栈里综合性价比最高的选择。对比过几个主流平台：ENVI的IDL二次开发确实成熟，但license费用不低，而且做桌面端工具分发很麻烦；ArcGIS的ArcObjects和ArcPy生态完整，可Python版本锁定严格，发布独立工具也得依赖ArcGIS环境；OpenCV单独做图像处理没问题，但缺乏GIS空间信息管理能力，没有矢量、投影、属性表这些基础支撑。
QGIS的优势在于它把GIS和遥感影像处理天然地整合在一起。底层用GDAL做栅格数据读写，空间参考、地理变换、金字塔、波段管理全部内置，不用自己造轮子。而且QGIS提供Python插件开发接口，UI设计用Qt Designer拖拽就能完成，开发效率比C++二次开发高很多。对于遥感算法验证和工具落地来说，Python生态足够支撑，numpy做矩阵运算、GDAL做I/O、TensorFlow或PyTorch做深度学习推理，全部丝滑衔接。实测下来，从零搭建一套插件框架到跑通第一个云检测流程，一个周以内可以完成。
1.2 系统功能模块划分
整套系统按职责拆成了五个模块，彼此解耦、通过数据流串联，这也是后续能持续加算法、换模型的关键。
- 数据管理模块：负责输入影像读取、波段提取、影像裁剪、投影转换，核心依赖GDAL/QgsRasterLayer。
- 云检测引擎模块：内置多套云检测算法，包括阈值法、随机森林、深度学习模型，统一接口调用。
- 地物恢复模块：对云遮挡区域进行重建，支持时间序列替换、插值修复、生成式填充三种策略。
- 质量评估模块：计算检测精度指标（IoU、PA、F1分数），评估恢复后的影像质量。
- 可视化交互模块：在QGIS地图画布上叠加检测结果、ROI勾选、参数调优、结果导出。
系统界面集成在QGIS的菜单栏和工具面板中，点击“云检测”按钮弹出参数对话框，选好影像路径、勾选算法组合方式、设置阈值参数，一键运行。结果以临时图层叠加到地图上，用户可以缩放查看检测边界，满意后一键导出。
1.3 技术栈选型版本说明
开发环境这块经历过几次版本升级，踩过不少坑，当前稳定组合如下，供参考：
| 组件 | 版本选择 | 说明 |
|---|---|---|
| QGIS | 3.28 LTR或以上 | LTR版本稳定，插件API兼容性最好 |
| Python | 3.9或3.10 | 匹配QGIS内置Python，避免后续依赖冲突 |
| GDAL | 与QGIS配套版本 | Windows下建议直接使用OSGeo4W安装 |
| 深度学习框架 | PyTorch 2.x（CPU/GPU均可） | 语义分割模型训练与推理 |
| 模型转换 | ONNX Runtime | 模型部署时用ONNX格式，避免依赖冲突 |
| UI开发 | Qt Designer + PyQt5 | 快速设计插件交互界面 |
需要特别说明的是，QGIS版本不要随手升到最新。QGIS的Python API在不同版本之间有过调整，例如某些接口在3.22到3.28之间改过签名，如果插件写好了，升级后容易报错。我一直在3.28 LTR上开发，稳定性很好，算法部分完全不受影响。
2. 云检测算法集成与多算法融合机制
2.1 云检测算法选型全景
云检测听起来简单，实际做起来很考验对遥感成像机理的理解。云在可见光波段表现为高反射、低纹理，在热红外波段表现为低温（高云）或中温（低云），而云影则是暗色、低反射区域。针对这些特性，业界算法大致分三代：
第一代是物理阈值法。典型代表是HOT（Haze Optimized Transform）变换和Fmask算法。这类方法通过设定多个波段反射率阈值来区分云层，比如Landsat 8中，蓝色波段反射率大于0.3、近红外波段反射率大于0.2、且NDVI较低，很可能就是云。优点是速度极快、无需训练样本，缺点是阈值的普适性差，不同地表类型（雪、沙漠、城市高楼）容易误检。
第二代是传统机器学习法。提取每个像素的光谱特征、纹理特征（灰度共生矩阵等）、空间上下文特征，喂给随机森林、支持向量机分类器。相比阈值法精度有提升，但依然需要人工做特征工程，而且分类器训练需要标注样本，泛化到不同传感器时特征分布差异较大，需要重新训练。
第三代是深度学习方法。把云检测看作图像语义分割任务，UNet、DeepLabV3+、SegFormer都有大量成功应用。深度学习模型能自动学习云的形态、边界、阴影关系，在多云复杂场景下精度显著优于前两代方法。我在实际测试中，UNet模型在Sentinel-2影像上的IoU能达到0.89左右，比经典Fmask高出近10个百分点。
2.2 多算法融合策略：级联+投票
单一的算法没有一种能通吃所有场景。阈值法薄云漏检严重，深度学习在厚云边缘有时过拟合导致边界畸变，两者互补性很强。所以我把融合机制做成“级联+置信度投票”的混合框架。
第一层级使用快速阈值法做粗检测，目标是“宁多勿漏”，把疑似云的区域尽量找出来。这一步计算量小，一景Landsat影像几秒钟就能出结果。粗检测结果作为mask，把影像分为“确认无云区”和“疑似云区”。第二层级只在疑似云区上运行深度学习模型，做精细分类。这样做有两个好处：一是大幅减少深度模型的推理面积，原先全图跑一遍要20秒，现在只跑可疑区域，一到两秒就完成；二是阈值法排除掉的区域本就是大概率无云区，深度模型只需集中区分薄云、厚云和云影，任务更聚焦、准确率更高。
融合逻辑可以简单写成：
final_mask = np.zeros_like(coarse_mask) # 粗检确认无云像素直接标为背景 final_mask[coarse_mask == 0] = 0 # 粗检为云的候选区，用深度模型细判 candidate = coarse_mask == 1 if candidate.any(): refined = deep_model.predict(img[:, :, candidate_roi]) final_mask[candidate] = refined # 双引擎投票制：阈值法判为云、模型判为无云的像素 # 进一步做连通域形态学处理，去掉孤立点2.3 三种融合策略对比
| 融合策略 | 实现思路 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|---|
| 级联式 | 阈值法粗检+深度模型精检 | 速度快，精度高 | 阈值法漏检区域直接放弃 | 大批量数据快速处理 |
| 多数投票式 | 多个模型独立预测，结果取多数 | 鲁棒性最强 | 推理耗时成倍增加 | 对精度要求极高的单景影像 |
| 置信度加权 | 各模型输出概率值，加权求和取最大 | 精度与速度折中 | 需要标定各模型权重 | 常态化处理流程 |
我在默认配置里使用的是级联式融合，因为处理效率优先。当遇到单景影像质量极差、需要精细刻画云边界时，会切换到置信度加权模式。置信度权重需要在少量验证样本上做网格搜索确定，即尝试不同的权重组合，选择验证集上F1分数最高的那一组。这一步看起来繁琐，但换来的是不同算法在不同场景下的优势互补。
2.4 精度评估不可跳过
云检测做得好不好，不能只靠肉眼主观判断。我建立了独立标准评估模块，加载人工标注的真值mask或人工检查过的样本集，计算四个核心指标：
- 像素准确率PA：所有像素中预测正确的比例，直观但容易受背景主导。
- IoU（Intersection over Union）：预测云区与真实云区的交集除以并集，是语义分割最常用的指标。
- F1分数：精确率与召回率的调和平均，兼顾漏检和误检。
- 错分率与漏分率：具体分析是“把非云当云”多，还是“把云当非云”多。
评估模块在每次算法调参后自动运行，指标变化一目了然，有效避免了“调参调了半天，效果反而变差”的问题。
3. 地物信息恢复的核心实现
3.1 云遮挡区域的三种恢复方案
云检测只是第一步，用户真正关心的是云下面的地物长什么样。要恢复地物信息，有三种主流思路，各有适用范围：
方案一：时间序列替换法。利用同一区域不同日期的影像，把有云区域用无云时相的对应像素替换。这是最可靠的方法，因为替换的像素本身就是真实观测数据，不存在“想象”的成分。前提是要有同区域、时相接近的无云影像，而且两期影像之间地表覆盖不能发生剧烈变化（比如不能拿冬天的像素替换夏天的植被）。实现时需要对两景影像做配准、辐射归一化处理，否则拼接边界很突兀。
方案二：空间插值修复法。基于云区周围无云像素的光谱值，通过反距离加权（IDW）、普通克里金或样条插值推算云区像素值。这种方式适用于云斑面积较小的场景，比如小于几百个像素的碎云，插值效果尚可。一旦云区面积大到上万个像素，插值结果就是一片模糊的色彩过渡，毫无地物纹理细节，不可用。
方案三：生成式填充法。利用生成对抗网络或扩散模型，根据云区周边的上下文信息“脑补”出内部地物纹理。这个方法这两年很火，但问题同样突出：模型生成的纹理可能是“合理的虚假”——形状、颜色合理，但和真实情况对不上。在业务验收时，生成式填充容易被认定为非真实观测数据，所以我一般只用它做视觉预览，不用于定量反演分析。
3.2 混合恢复策略的设计
单一方案不可靠，这套系统内置了“先识别后恢复”的混合策略：
整个流程分成三条分支：云区像素先分类为“可替换”和“不可替换”。具体判断依据是时间序列影像库中是否存在相近时相且重叠面积大于阈值（默认80%）的无云影像，替换前做辐射归一化防止色差。如果不可替换，再判断云区连通域面积，小于2000像素的用插值修复，大于2000像素的转入生成式填充作为兜底。用户也可以在界面上手动调整判断阈值，针对不同测区做适配。
# 混合恢复策略伪代码 if has_time_series_image(cloud_bbox): result = temporal_replace(src_img, ref_img, cloud_mask) elif cloud_region_pixel_count < 2000: result = interpolation_fill(src_img, cloud_mask) else: result = generative_fill(src_img, cloud_mask)3.3 实战效果分析
拿一景含有大面积厚云的Sentinel-2影像实测：云占比约30%，云区面积细分后有相当一部分是连片厚云。时间序列替换法找到了30天前的无云影像，替换后整体色调一致性较好，但部分农田因为时相不同导致颜色出现轻微差异。对于无法替换的零星云区域，插值修复效果不错，边界过渡自然。实测整体视觉效果接近无云影像，但NDVI反演结果中，少部分替换区域与其他区域的植被指数存在偏差，这套流程更适合做目视解译底图和制图合成。
如果是做定量分析，建议优先保证时间序列替换的时相一致性，把“替换源影像与目标影像的成像日期差”作为必选参数，并在输出报告中显著标注。这也是我在开发过程中最深的体会——地物恢复的终点不只是“看着没云”，还得多想想“数据能否用于定量计算”。
4. 实操环节：QGIS插件开发与算法集成的关键代码
4.1 插件开发环境搭建：避开最容易翻车的几个坑
我第二次搭建QGIS插件环境时踩过一次大坑：在Windows上直接pip安装PyQt5，结果版本和QGIS内置的Qt库不一致，界面加载后中文乱码、控件错位，反复排查才发现是Qt插件路径冲突。正确做法是使用OSGeo4W Shell作为Python环境，直接利用QGIS官方打包好的Python库和Qt库，不额外pip安装Qt相关包。
确认当前环境方式：
# 在QGIS Python控制台中检查版本 from qgis.core import Qgis print(Qgis.QGIS_VERSION_INT) import PyQt5.QtCore print(PyQt5.QT_VERSION_STR)插件骨架工程建议是：
cloud_remove_plugin/ ├── __init__.py ├── cloud_remove_plugin.py # 插件主入口 ├── cloud_remove_plugin_dialog.py # 对话框逻辑 ├── cloud_remove_plugin_dialog_base.ui # Qt Designer绘制的界面 ├── cloud_detection/ │ ├── __init__.py │ ├── threshold_detect.py # 阈值云检测 │ ├── deep_model.py # 深度模型推理 │ └── fusion.py # 多算法融合 ├── restoration/ │ ├── temporal_replace.py # 时间序列替换 │ ├── interpolation_fill.py # 插值修复 │ └── generative_fill.py # 生成式填充 ├── resources.qrc └── metadata.txt用Qt Designer画界面时，推荐把所有参数都做成可手动修改的输入框和下拉框，不要把参数硬编码在代码里。这在调参阶段能节省大量反复改代码重新加载插件的时间。
4.2 核心算法模块的接入示例
第一块：读取影像波段数据并转换坐标系。遥感影像在处理前必须统一投影坐标系，否则后续像素对齐全是问题。在QGIS插件中，最稳妥的方式是用GDAL读取原始数据后，再用gdal.Warp重投影。
from osgeo import gdal, gdalconst import numpy as np def load_bands_as_array(raster_path, target_epsg=4326): src_ds = gdal.Open(raster_path, gdalconst.GA_ReadOnly) if src_ds is None: raise ValueError(f"无法读取影像: {raster_path}") src_wkt = src_ds.GetProjection() # 重投影到目标坐标系 dst_wkt = f"EPSG:{target_epsg}" warp_options = gdal.WarpOptions(format="VRT", dstSRS=dst_wkt) vrt_ds = gdal.Warp("", src_ds, options=warp_options) band_count = vrt_ds.RasterCount bands = [] for b in range(1, band_count + 1): band = vrt_ds.GetRasterBand(b).ReadAsArray() bands.append(band) return np.stack(bands, axis=-1), vrt_ds.GetGeoTransform(), vrt_ds.GetProjection()第二块：深度学习模型推理。训练好的云检测UNet模型先导出为ONNX格式，再用ONNX Runtime加载推理。这样的好处是插件运行环境不用安装PyTorch，部署简单很多，规避了Python库兼容性问题。
import onnxruntime as ort import numpy as np class CloudSegEngine: def __init__(self, onnx_path): self.sess = ort.InferenceSession( onnx_path, providers=["CUDAExecutionProvider", "CPUExecutionProvider"] ) self.input_name = self.sess.get_inputs()[0].name self.output_name = self.sess.get_outputs()[0].name def predict(self, patch): # patch shape: (H, W, C), uint16/float32 input_tensor = patch.astype(np.float32) # 归一化到 [0,1] input_tensor = (input_tensor - input_tensor.min()) / ( input_tensor.max() - input_tensor.min() + 1e-6 ) # 转为 NCHW input_tensor = np.transpose(input_tensor, (2, 0, 1))[None, ...] prob = self.sess.run([self.output_name], {self.input_name: input_tensor})[0] mask = np.argmax(prob[0], axis=0) return mask第三块：恢复结果写回GeoTIFF。注意要保留原始影像的地理参考信息，否则输出的文件无法在GIS中定位。使用gdal.GetDriverByName("GTiff")创建文件时，通过SetGeoTransform和SetProjection写入坐标信息。
def write_geotiff(out_path, data, geo_transform, projection, dtype=gdal.GDT_Float32): driver = gdal.GetDriverByName("GTiff") height, width = data.shape[:2] band_count = 1 if data.ndim == 2 else data.shape[2] out_ds = driver.Create(out_path, width, height, band_count, dtype) out_ds.SetGeoTransform(geo_transform) out_ds.SetProjection(projection) if band_count == 1: out_ds.GetRasterBand(1).WriteArray(data) else: for i in range(band_count): out_ds.GetRasterBand(i + 1).WriteArray(data[:, :, i]) out_ds.FlushCache()4.3 界面集成要点
自定义算法要出现在QGIS菜单中，需要重写addAction和initGui方法。加载处理后的图层并添加到地图画布时，一定要给定正确的CRS，否则QGIS无法正确叠加显示。
def initGui(self): self.action = QAction("云检测与地物恢复", self.iface.mainWindow()) self.action.triggered.connect(self.run) self.iface.addToolBarIcon(self.action) self.iface.addPluginToMenu("遥感处理工具", self.action) def run(self): dlg = CloudRemoveDialog(self.iface) dlg.show()在界面设计上，我习惯给每个关键按钮加上“运行日志输出”区域，把每一步算法执行的耗时和中间结果反馈给用户，比如“阈值粗检完成，耗时2.3秒，检测疑似云像元185420个”。这种设计在调试和跟用户交付时都很有用——不是所有使用系统的同事都懂算法，但他们都看得懂日志。
5. 常见问题与排查技巧实录
5.1 问题速查表
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| QGIS启动后插件加载失败 | metadata.txt格式错误或缺少依赖 | 检查metadata.txt版本号格式；读取QGIS日志的插件报错信息 |
| 影像读取后显示全黑 | 拉伸方式不对，或数据是16位无符号整型 | 图层属性设置中调整对比度增强方式为“按最大最小值拉伸” |
| 云检测mask偏大/偏小 | 阈值参数不适合当前影像 | 开启参数调试模式，可视化每一层阈值结果，逐步调整 |
| 深度学习模型推理内存溢出 | 一次加载整景影像过大 | 切块推理，每块256x256，重叠16像素，按块拼接 |
| 恢复后影像边界色差明显 | 未做辐射归一化或羽化处理 | 对替换边界做20像素宽度渐变羽化 |
| 输出GeoTIFF在ArcGIS/QGIS中偏移 | 未正确写入GeoTransform | 输出前打印原始GeoTransform确认，使用同一对象写回 |
5.2 内存管理经验
遥感影像动辄上GB，如果在插件里一次性把整景影像全部读入numpy数组，一台16GB内存的电脑瞬间就会被吃满。我的处理方案是分块（block）计算：设定默认分块大小1024x1024像素，每个分块独立执行云检测和恢复算法，最后统一拼接写出。这样处理一景2GB的影像，内存峰值控制在1GB左右，稳定可靠。
def process_large_image(ds, block_size=1024): width = ds.RasterXSize height = ds.RasterYSize result = np.zeros((height, width), dtype=np.uint8) for y in range(0, height, block_size): for x in range(0, width, block_size): block = ds.ReadAsArray(x, y, min(block_size, width - x), min(block_size, height - y)) block_mask = cloud_detect_block(block) result[y:y+block_mask.shape[0], x:x+block_mask.shape[1]] = block_mask return result5.3 调参与日志：没有调试输出，一切问题都是玄学
整个开发过程中我最后悔的一件事，是没有从一开始就建立完善的日志系统。前期联调时，一旦结果不对，根本不知道是阈值算法的问题、模型的问题、还是数据处理的问题，只能一段段地打印变量一点一点排查，效率极低。
后来我写了一个简单的日志模块，输出等级分为DEBUG/INFO/WARNING/ERROR，关键步骤全部打上日志：读取影像的信息、坐标范围、波段数量、每一层算法处理的时间、云检测结果的统计值、恢复结果的文件路径。运行完一次性收集日志文件，哪个环节异常一目了然。
import logging logging.basicConfig( filename="cloud_remove.log", level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s", ) logger = logging.getLogger("CloudRemove") logger.info("开始处理影像: %s", image_path)5.4 关于模型训练的一些心得
深度模型部分，大多数人其实是卡在训练数据准备上。云检测的公开数据集有Landsat8 Biome、Sentinel-2 Cloud Mask Catalogue等，可以拿来预训练，但应用到本地高分影像时建议用少量人工标注样本做微调。微调样本不需要很多，精选20-30个典型场景块（每块512x512）就能显著提升模型在目标传感器上的表现。因为云的形态总归是全球一致的，但不同传感器的波段响应、分辨率不同，微调的作用就是让模型适应目标影像的光谱分布。
训练时还有一个容易忽视的坑——样本类别不平衡。无云像素占了绝大部分，如果直接训练，模型倾向于把所有像素都预测为无云，准确率看着很高但实际毫无用处。需要给云类加上更高的类别权重，或者使用Focal Loss这类处理类别不平衡的损失函数。我在训练时用的是dice_loss加交叉熵的加权组合，实际效果比单用交叉熵稳健得多。
6. 这套系统后续还可以怎么扩展
开发完这套系统后，我在实际项目中不断给它加新功能，慢慢沉淀出几个很实用的扩展方向，供参考。
第一，接入更多卫星传感器数据。目前系统针对Landsat和Sentinel-2做了适配，但高分系列、资源系列的数据格式和波段设置都有差异。做传感器适配层时，抽象出统一的“波段提取接口”，每个传感器单独实现一个适配器，就能顺滑扩展。后续需要支持国产卫星的话，这步拆得越早越省事。
第二，加入批处理模式。日常生产任务往往是几十景影像一起处理，单张点按钮效率太低。目前我已经扩展了“批量处理工作流”，读取一个文件夹下所有影像的清单文件（文本文件，每行一条影像路径），顺序执行云检测、恢复、质量评估，最终生成一个汇总报告。批量模式跑起来后，一晚上能自动处理50景以上，第二天直接收结果，对生产效率提升非常明显。
第三，服务化封装。桌面端插件适合单机作业，但如果业务方是一个团队，需要共享处理能力，可以额外加一个“导出处理脚本”功能，自动生成独立的Python CLI脚本，这样就能在没有QGIS环境的服务器上跑批处理。不过要注意，CLI脚本和插件共用核心算法模块，但入口不同、不用加载QGIS界面，部署起来更轻量。
这套系统的路还很长，但现在回头来看，从最初一个“让影像去云更省事”的小需求，逐步发展成包含多算法融合、自动化质量评估、批量处理能力的小工具链，这个过程中积累的调试经验和工程化工具方法，其实比代码本身更有价值。如果你是做遥感数据处理这块的，又有长期跟影像打交道的需求，花点时间把QGIS二次开发这条路走通，绝对值得。
本文还有配套的精品资源，点击获取
