写这篇博文之前先说个感受图像去雨这个方向这几年论文不少但真正能落到工程里的方案并不多。要么效果还行但模型重到没法在边缘设备上跑要么轻量了但去雨效果又明显打折。我是在一个户外视觉项目的雨天场景里被这个问题反复折磨之后才认真去研究轻量级去雨网络选型的最后锁定了StarNet这条路线实测下来稳定性和性价比都超出了预期。如果你也在做自动驾驶感知、安防监控或者户外摄影相关的图像预处理这篇内容应该能帮你省下不少调研时间。1. 先搞清楚StarNet到底是什么以及它解决的核心痛点1.1 去雨任务为什么这么难雨痕对视觉系统的影响不是简单地“画面脏了”这么简单。真实场景里的雨滴大小不一、分布稀疏不均雨线方向还受风力和镜头角度影响再加上背景纹理和雨痕在频域上高度重叠传统滤波方式根本分不开。更麻烦的是雨痕在图像上属于局部高频信息而背景边缘也同样是高频信息如果处理不好去完雨之后边缘糊了、细节丢了那对下游检测或分割任务来说等于帮了倒忙。我接手那个项目的时候最初用的是传统的暗通道先验去雨思路效果怎么说呢静态图像看起来还行但一遇到视频流或者密集雨丝背景被过度平滑的现象特别明显尤其是霓虹灯、车灯这些高亮区域简直没法看。后来换成基于CNN的轻量模型速度是上去了可对大块雨痕和细密雨丝并存的情况还是力不从心。1.2 StarNet给这个难题提供了什么解法StarNet全称是Spatial-to-depth Transformer Network是一篇面向单图像去雨的轻量级Transformer方案。它的定位非常明确在保证去雨效果接近甚至超过一些大模型的同时把参数量压缩到百万级别让模型真正具备部署价值。我最初看到这个设计的第一反应是这名字起得有点取巧但拆开看架构之后发现它在每个环节都在刻意控制计算量。按照论文公开的数据StarNet在常见去雨基准数据集上的表现能跟Restormer这类大模型掰手腕但参数量只有Restormer的几十分之一。这种“效果和体积的平衡点”正是实际工程里最难得的。这个方案适合谁如果你正在做实时视频流的预处理、在嵌入式设备上跑视觉任务或者只是想把去雨模型塞进现有的推理管线里StarNet是一个很值得认真研究的候选方案。如果只是做学术对比实验它清清爽爽的结构也方便你魔改。2. 网络结构与设计思路拆解2.1 轻量级Transformer为什么能兼顾效果与速度Transformer在图像修复任务里之所以能打得过CNN关键在全局感受野。雨痕经常横跨整幅图像局部卷积窗口看来看去都只看到一小段很难建立起“这条雨线从头到尾是一体”的认知。但Transformer的自注意力机制天然能捕捉这种长距离依赖所以从SwinIR到Restormer去雨效果都跨越了一大步。然而标准的全局自注意力计算复杂度是图像尺寸的平方级直接把整张图拉进去算训练时都费劲更不用说部署。StarNet的核心思路就是在不牺牲全局建模能力的前提下大幅压缩计算开销。它不是单纯把窗口调小而是同时引入了patch级别的空间信息重塑和分方向的条纹注意力。这么说吧如果把去雨网络比作一个处理照片的修图师CNN的做法是拿着一把小刷子一点一点把雨线涂掉速度慢还容易漏大Transformer是把整张照片铺在桌面上整体分析效果好但桌子得足够大StarNet的办法是先快速把照片里的像素重新分组打包再用一条横刷和一条竖刷分别处理不同走向的雨丝效率自然高。2.2 三个被刻意设计的核心模块第一个是Spatial-to-depth模块。简单说就是把空间维度上的相邻像素按块重新排列到通道维度上通俗讲就是“把棋盘压扁”。原来一个像素点的邻域信息被塞进通道里特征图的分辨率降下来了但通道数涨了。这么干的好处是后续自注意力计算的空间复杂度直接降低同时保留了局部邻域信息的一致性。第二个是分patch的Transformer模块。它把特征图切成小块每个小块内部做自注意力块与块之间再通过跨窗口的方式交换信息。这跟SwinIR的移动窗口有点像但StarNet的切片方式考虑了图像的空间结构配合空间到深度的卷积整体感受野并没有因为缩小计算范围而变窄。第三个是分层strip Transformer模块这是处理雨痕最精髓的部分。它把注意力分成水平条带和垂直条带两种模式分别沿图像的行方向和列方向计算。雨痕大多是斜线但从统计角度看水平和垂直方向的响应采集已经能覆盖大部分雨丝形态而且条带策略的计算量远小于全局方块注意力。这三个模块叠起来就是StarNet在轻量化的同时还能保证去雨质量的核心原因。我平时写技术调研笔记有个习惯就是遇到新架构先问“这里的假设是否合理”。StarNet的假设是雨痕的方向性可以通过行列分解来近似。这个假设在实际场景里基本成立因为即使斜向雨丝在频域里也能用横纵分量的叠加去表达。理解了这一点后续做模型魔改或者参数调优才不至于盲目。3. 训练细节与数据准备的实操要点3.1 数据集的选取与预处理实操去雨方向的公开数据集不算少但质量参差不齐。论文里常提到的是Rain100H、Rain100L、Rain800这些合成数据集另外还有GT-Rain这类真实雨图。我的建议是如果做效果演示或者论文复现首选Rain100H它的雨痕覆盖密集、遮挡程度高能逼出模型的真实水平如果做实际项目落地最好额外找真实场景数据做微调纯合成数据训出来的模型直接上真实雨景效果往往会有折扣。数据预处理环节我踩过几个坑。第一是图片缩放很多复现脚本默认把训练图像缩到256×256但如果你的应用场景是1080P视频帧直接拿缩小的训练图去推理大图边缘区域会出现明显的模糊感。我的做法是训练时用随机裁剪而不是整体缩放推理时再用滑窗或者直接整图输入效果会好很多。第二是数据增强策略。很多新手会忽略归一化参数的一致性训练时用的均值和方差如果和推理时不统一色彩偏移问题会非常明显。去雨模型对色彩一致性很敏感我建议在数据加载阶段就把归一化写死成一个常量而不是从训练集临时统计。还有一个不起眼但很重要的细节雨痕图像的对比度通常偏低训练时适当做随机亮度扰动和gamma校正能增强模型对光照变化的鲁棒性。我一开始没做这一步结果模型在阴雨天的泛化效果总比晴天带雨场景差加上之后明显改善。3.2 损失函数与训练策略选择StarNet的训练目标基本可以分为像素级损失和感知级损失两路。像素级损失最常用的是L1损失它比L2损失对模糊的惩罚更小能让输出图像保留更多纹理细节感知损失则是把预测结果和真值都送进预训练分类网络里比较它们在中间特征层的差异这能帮模型生成更符合人类视觉习惯的结果。实际操作里我的经验是L1损失权重设置在1.0感知损失权重设置在0.05到0.1之间。感知损失权重太高会让输出图像变得过度平滑像加了磨皮滤镜一样反而丢失了雨滴边缘附近的真实信息。我试过把权重调到0.5结果图像干净了但纹理细节没了对下游检测任务反而是负优化。优化器方面AdamW是现阶段最稳妥的选择。学习率我习惯用1e-4起步配合Cosine Annealing调度在100到150个epoch内完成训练。很多人会把batch size设得很大来加速但在这个模型上显存占用并不高更大的batch size反而容易让训练陷入局部最优我常用的是batch size 8配单卡训练。有个容易被忽略的细节是去雨属于低层视觉任务模型对初始化方式比较敏感。我试过用ImageNet预训练权重初始化骨干网络效果并不比随机初始化好多少反倒是用Xavier初始化再配合warmup头几个epoch训练的稳定性更好。所以如果有人告诉你“必须用预训练”你可以先画个问号自己对比实验再做决定。3.3 从零训练到微调的策略建议如果你不是为了复现论文而是想把StarNet用在自己的场景里我强烈建议不要从随机初始化开始训。先用公开数据集训一个通用模型再用自己的业务数据做微调这个流程能节省一半以上的训练时间。微调阶段的学习率要压到主训练的十分之一左右比如主训练用1e-4微调就用1e-5。同时微调数据里最好保留一部分原雨图防止模型在陌生数据分布上产生遗忘。我自己在微调时习惯按6:3:1的比例混合业务雨图、公开雨图和无雨清晰图无雨清晰图的作用是让模型记得“干净图不能越处理越脏”。4. 从环境搭建到实际推理的完整过程4.1 环境搭建与依赖版本选择StarNet的代码基于PyTorch环境配置不算复杂但版本搭配上有个别人容易踩坑的地方。我推荐用Python 3.8或者3.10PyTorch版本在1.13到2.x之间的稳定版都行CUDA建议用到11.7以上这样能保证Transformer里的注意力算子正常编译。安装依赖的时候除了常规的numpy、opencv-python、tqdm之外还要留意einops这个库StarNet的代码里大量使用了einops的rearrange操作来实现空间到深度的重排列。如果你习惯用纯PyTorch的view和permute去手写很容易因为维度顺序不对而报错而且排查起来特别隐蔽。启动训练前我习惯先跑一个单步的forward测试用随机张量输入模型确认输出尺寸和数值范围正常。这一步能过滤掉八成以上的维度问题。之前有朋友直接从GitHub拉代码开训结果跑了半小时后发现loss一直不降最后才查出来是输入图像没有归一化到0到1之间模型在无穷大的输入范围里胡乱震荡。4.2 推理阶段的关键参数与完整命令推理阶段的参数设置比很多人想象的重要得多。以StarNet为例输入图像路径、输出路径、权重文件路径是最基本的三个参数。除此之外还有一个隐藏参数值得关注就是模型输入尺寸的适配方式。如果推理图片不是训练时的正方形尺寸代码里通常会做resize或者padding。我实际用下来直接resize到256×256再上模型输出会丢细节更好用的是先pad成256的倍数推理后再裁剪回原尺寸。这个方式能保持原图的长宽比和纹理细节。显存方面StarNet的设计目标就是轻量级在单张消费级显卡上推理1080P图像占用大概在1GB到2GB之间这相比Restormer动辄占用10GB以上的情况完全是两个量级。如果你是在CPU上推理一次推理时间会拉长到几秒但模型本身小配合ONNX导出之后还是有可能达到准实时的需求。说到ONNX导出这也是实际部署里几乎绕不开的一步。PyTorch的模型文件在推理服务里直接加载可以但换成ONNX格式后很多加速框架和边缘设备会更友好。导出ONNX的时候动态轴要设对尤其是batch维度和图像宽高维度否则后期接不同分辨率的输入又得来回改图。4.3 与常见去雨方案的实际对比体验为了写这部分我把StarNet跟两类方案做了同环境对比。一类是传统CNN方法的代表比如DerainNet和UMRL另一类是重量级Transformer方法Restormer。对比条件一致同一批测试集同一台机器。选型对比个人实测记录方案参数量1080P平均推理耗时RTX 3060主观去雨效果部署友好度DerainNet较大约200ms雨纹残留多边缘偏糊一般UMRL中等约160ms轻雨尚可重雨失效一般Restormer约26M约1500ms效果好但显存占用高差StarNet约1M约80ms重雨场景接近Restormer轻雨场景完全够用好这个表不是要证明StarNet全面碾压其他方案而是说它在“效果能接受”和“资源消耗低”之间找到了一个实用平衡点。如果你的场景是离线处理高价值图像不追求实时Restormer依然值得考虑但要考虑成本、并发、功耗StarNet这类轻量方案明显更现实。5. 常见问题与排查技巧实录5.1 训练时loss不下降或下降缓慢这是我被问得最多的一类问题也是我自己第一次训练时踩过的坑。如果你确认数据加载和模型结构都没问题那么大概率是学习率设置不合理。StarNet这种轻量Transformer对学习率区间比较敏感我建议直接从3e-4开始扫如果30个epoch内loss纹丝不动再往下调到1e-4。另外一个常见原因是损失函数里感知损失的权重占比太小L1损失已经降到一个平台期但感知损失没有明显变化。这时候光看总loss会觉得模型不学了实际上分开打印两个loss分量就能发现是感知部分太弱不是整体没在优化。还有一个小概率但常见的情况数据加载器返回的标签和输入对不上。这个问题多发生在多进程加载时shuffleFalse但缓存队列乱序或者增强操作不小心把真值图也做了随机翻转。遇到这种问题建议固定随机种子并写个可视化脚本把训练对打印出来人工核对一遍。5.2 推理结果偏暗、偏色或出现伪纹理如果你用训练好的模型去跑真实雨图发现输出偏暗第一反应不应该是调模型而是检查输入数据的归一化。很多开源代码默认输入范围是0到1但你的图像读取管线如果用了cv2.imread读进来是BGR顺序且范围0到255直接喂给模型就会出问题。正确的做法是转RGB再除以255必要时再按照训练时的均值方差做标准化。偏色问题通常也和通道顺序、归一化参数有关。我遇到过的情况是训练时用的数据加载器基于PIL推理时换成OpenCV通道顺序不一致导致输出图整体偏蓝绿色调。这种情况修改模型本身是没用的排查数据管线的通道顺序才能解决。伪纹理这个词听起来可能有点吓人其实就是模型把原本平滑的区域生成了一堆不该存在的条纹或斑点。常见触发条件有两个一是推理图像分辨率远高于训练分辨率模型没有见过这么大的空白区域容易脑补二是输入图像有压缩噪声尤其在JPEG低质量压缩下模型会把压缩块当成纹理去“修复”。解决办法是推理前对输入图做一次轻度的去块滤波。5.3 显存占用异常或推理速度达不到预期StarNet的整体参数量只有约1M正常来说显存压力很小。如果你发现速度远低于预期先看输入图像尺寸。有些代码在推理时会先把图像resize到某个固定尺寸再通过模型后resize回去这个过程看似无感实际上耗时和显存都在浪费。还有一类情况是环境里的PyTorch版本太旧没有用上TensorRT或者cuDNN的优化算子。同样是Transformer结构PyTorch 1.13和2.1之间的推理速度能差出百分之二三十。建议更新到较新的PyTorch并且用torch.compile包裹一下模型注意torch.compile需要较新的GPU驱动和CUDA支持。如果这些都排查完还慢那就要看你的CPU是否存在频繁的GPU-CPU数据传输了。推理脚本里如果每张图都调一次同步速度也会掉得厉害。把预处理和推理放在同一个设备上进行或者用批量推理接口能有效减少传输次数。5.4 真实部署时最容易忽略的细节第一个细节是黑白名单机制。很多实际场景里晴天画面根本没雨却还是每帧都跑一遍去雨模型。这样既浪费算力又可能对原图造成不必要的处理痕迹。我建议在去雨模型前加一个轻量的雨检测分类器只在有雨时才触发去雨这个思路在工程上性价比极高。第二个细节是推理结果的可解释性。模型输出的图像在像素级上可能看起来很干净但下游任务如果用到OCR或者车牌识别雨痕被去除的同时也可能把字符边缘给抹了。所以做项目评估的时候不要只看去雨后的PSNR和SSIM一定要拿到下游任务里测端到端指标。我在车牌场景里就吃过亏去雨模型把雨滴去得很干净但车牌数字也被平滑过识别率不升反降。第三个细节是模型更新的灰度发布。如果你把去雨模型部署到了线上模型更新不能一刀切全量。先灰度一部分流量对比解析率、主观反馈这些核心指标确认没问题再全量。这一条对所有AI模型部署适用但对图像增强类模型尤其重要因为“视觉上变好”和“任务上变好”经常不是一回事。考虑到篇幅把两个值得补充的现象写在这里。一个是模型在极端恶劣天气下的表现比如暴雨夹杂水雾StarNet还是会有局限性的。它的设计假设是雨痕本身具备清晰的条纹结构一旦雨滴被风吹得完全离散成水雾形态行列注意力就抓不到什么有效语义输出会偏模糊。这种情况没必要硬扛前级加检测预警直接降低对去雨效果的预期会更实际。另一个有趣的现象是相同的输入尺寸下训练分辨率越低推理大图时的颗粒感越明显。如果终端设备推理性能跑不动高分辨率输入一个折中方案是训练时用256输入推理时用滑窗重叠裁剪并对重叠区域做均值融合拼接。这样做出来的结果比直接resize大图要自然得多多花的时间也完全在可接受范围。我个人在实际操作中的体会是StarNet这类轻量级模型最核心的价值不是某一个指标刷得高而是让原本只存在于实验室的去雨能力真正有了进入到真实产品管线里的可能性。你不需要为了它专门备一台推理服务器也不用为了跑一帧图等上半秒钟绝大多数现有设备的算力已经足够覆盖。如果你也想在自己的视觉链路里补上雨天预处理这一环StarNet会是一个不错的起点架构清晰、代码干净、调试路径也相对好走值得认真对待。