这个系列写到第二篇了。上一篇刚把数据清洗的流程捋完后台就开始有人追着问批量去水印的事。说实话这需求确实刚需尤其做运营、做设计、天天处理素材图的朋友手里经常压着几百上千张带着水印的图一张张用PS去修腰酸背痛不说修到后面手都飘。我自己上次整理一批素材图三百多张每张右下角挂着同一个半透明文字水印手动修了一整天效果还参差不齐。后来干脆把lama-cleaner这个开源修复工具拉起来用Python调它的接口批量处理十分钟跑完全部图片出图稳定且干净。这篇文章不绕弯子直接把这套流程拆开讲透从服务部署、接口确认、脚本编写到mask自动生成再到实测踩坑全程干货。1. 去水印的主流路子我试了一圈最后留在模型服务化很多人看到“批量去水印”的第一反应是直接用Photoshop录个动作不就行了确实固定位置的水印可以录制“矩形选框内容识别填充”的批处理动作。但内容识别填充的算法本质是尽量找周围相似的纹理去补一旦水印压在人脸、复杂背景、密集纹理上PS很容易给你补出一块发糊的色斑。而且同一个动作处理一百张图成功率很难稳定在让甲方闭嘴的水平。OpenCV自带的传统图像修复算法我也试过。cv2.inpaint()处理小瑕疵、红眼、小划痕没什么问题一旦水印区域稍微大一点比如10个字的长串logo它填充出来的东西就是一层带颜色的雾边缘还有明显的涂抹感。因为Telea和FMM这类方法本质上只用了周围的局部信息对“脑补一块缺失内容”这件事并不擅长。裁剪就更不用说了水印往往盖在关键内容附近裁掉等于把图片的构图毁了。真正让我下定决心换方案的是LaMa这个修复模型。它走的是生成式修复路线利用傅里叶卷积把大面积缺失区域当成生成任务来处理能根据整张图的语义把纹理和结构补回来效果比起传统算法完全是另一个级别。lama-cleaner这个项目把LaMa等一系列模型封装成了开箱即用的服务既带图形界面也暴露HTTP接口这就非常适合批量脚本调用了。我把几个维度拉出来对比了一下方案单张耗时批量能力大面积修复效果部署成本PS动作内容识别30秒左右弱依赖人工抽检容易发糊低已有工具OpenCV传统修复毫秒级好大面积不行低裁剪水印区域秒级好丢失构图零lama-cleaner服务化接口单张1-3秒好脚本批量跑实测最稳中等装个环境最终选型理由就两条一是生成式修复对大面积水印的“脑补”能力是目前所有我能上手的方式里最强的二是服务化接口天然适合Python做批处理不用每次启动都开图形界面也不需要把图片拖来拖去。接下来要解决的就是怎么把这个服务跑起来以及怎么把一批图片的调用流程打磨到能直接交给同事用的程度。2. 服务先跑起来安装、启动、拿 curl 探明真实接口2.1 安装和启动命令lama-cleaner是Python生态里的开源项目安装路径很顺。我自己习惯用虚拟环境隔离避免和系统里的依赖版本打架。# 建议创建一个独立环境 python -m venv lama_env source lama_env/bin/activate # Windows下用 lama_env\Scripts\activate pip install lama-cleaner如果机器上有NVIDIA显卡并且装好了CUDA直接用cuda推理速度快不少如果是Mac或者普通PC用CPU也能跑单张图大约多等几秒而已。批量去水印场景下我建议直接用lama模型它兼顾速度和效果。启动命令如下lama-cleaner --modellama --devicecuda --port8080没有CUDA的话就改成--devicecpu。想让局域网内其他机器也访问就再加一个--host0.0.0.0。核心参数我先列个表省得你翻文档参数作用我的建议--model选择修复模型批量去水印首选lama效果和速度均衡--device推理设备有N卡用cuda没有就用cpu--port服务监听端口默认8080被占了就换--host监听地址只听本机默认127.0.0.1跨机器调用要写0.0.0.0--gui是否打开图形界面纯接口批量调用不要开第一次启动时服务会下载模型权重文件有几百MB取决于网络情况多等一会儿是正常的。看到终端出现类似“Uvicorn running on http://127.0.0.1:8080”的日志就说明服务已经起来了。这里有个小提醒下载权重要保证网络通畅别用公司那种动不动断外网的内网环境跑这个步骤不然卡在下载阶段很浪费时间。2.2 接口地址别猜用 /docs 或 curl 确认服务起来之后第一件事不是我直接写Python代码而是先用curl把接口调通。因为lama-cleaner不同版本之间的API路径和参数名有过调整网上很多教程写的地址都已经过时了直接照搬容易吃404。浏览器打开http://127.0.0.1:8080/docs能看到一个Swagger接口文档页面这里面列的就是当前版本真实可用的路由。以我用的版本为例修复接口是POST /api/inpaint接收表单文件image和mask。修图时image放原图mask放掩码图接口返回修复后的图片。在服务器终端里用curl做一次冒烟测试比打开文档更直观curl -X POST http://127.0.0.1:8080/api/inpaint \ -F imagedemo.jpg \ -F maskdemo_mask.png \ -o demo_out.jpg执行完如果生成了demo_out.jpg并且文件大小不是几十字节的错误信息说明接口链路是通的。我第一次跑这个curl还踩了个坑拿了一张带透明通道的PNG当原图结果接口直接返回400。后来把图片转成RGB三通道的JPG再试一次就通了。所以准备测试图的时候记得用JPG或者不透明PNG。到这里服务层已经ready后面所有批量处理都是对着这个HTTP接口反复POST脚本可以完全脱离图形界面运行。3. 批处理脚本的分层设计扫描、请求、调度分开才算能用3.1 文件扫描与输入输出准备刚接触自动化的人最容易犯的错是把所有逻辑堆在一个for循环里图片读取、mask生成、请求、保存全塞一起看起来很快但一旦某一步出问题排查成本成倍上涨。我的习惯是先把目录结构理清楚让每一步的输入输出都看得见input/ 原始带水印图片 masks/ 每张图片对应的水印mask output/ 修复后的图片 failed.log 失败记录日志扫描文件的代码很直接用pathlib就能解决from pathlib import Path INPUT_DIR Path(input) OUTPUT_DIR Path(output) MASK_DIR Path(masks) SUPPORTED {.jpg, .jpeg, .png, .webp} images sorted( p for p in INPUT_DIR.iterdir() if p.suffix.lower() in SUPPORTED ) print(f共发现 {len(images)} 张图片)这一步把路径统一整理好后面无论调试哪一张只要按文件名定位对应的mask和输出文件就行。关键原因是批量流程跑起来之后日志里报错的往往是某一张图的名字如果路径散落在代码各处查找效率会很低。3.2 请求函数、超时与重试请求函数是整个脚本的心脏它负责把一张图片和对应的mask提交给lama-cleaner接口拿到修复结果。import requests import time API_URL http://127.0.0.1:8080/api/inpaint def inpaint_one(image_path, mask_path, save_path, timeout60): with open(image_path, rb) as f_img, open(mask_path, rb) as f_mask: files [ (image, (str(image_path), f_img, image/jpeg)), (mask, (str(mask_path), f_mask, image/png)), ] resp requests.post(API_URL, filesfiles, timeouttimeout) if resp.status_code 200: with open(save_path, wb) as f_out: f_out.write(resp.content) return True raise RuntimeError(fHTTP {resp.status_code}: {resp.text[:200]})timeout60这个参数很关键。lama模型在CPU上处理一张大图可能超过10秒但正常情况下不太会超过60秒。不设置超时的话假设服务端卡住脚本会一直挂在那整批任务全部被拖死。服务端批量运行过程中偶尔也会出现偶发的超时或者网络闪断这时候需要重试机制兜底def inpaint_with_retry(image_path, mask_path, save_path, retries3): for attempt in range(retries): try: return inpaint_one(image_path, mask_path, save_path) except Exception as exc: if attempt retries - 1: raise wait 2 ** attempt print(f[warn] 第 {attempt 1} 次失败: {exc}{wait}s 后重试) time.sleep(wait)重试间隔我用的是2的指数退避第一次等2秒第二次等4秒给服务端留出恢复时间。这种策略比固定间隔更稳不容易在服务端还没缓过来的时候疯狂重试反而加重负担。3.3 并发调度与断点续跑单线程一张一张跑也能跑完但GPU利用率会很低。批量处理时提升吞吐最直接的方式是加并发。这里我用ThreadPoolExecutor因为瓶颈在远端服务的推理Python线程的GIL影响可以忽略。from concurrent.futures import ThreadPoolExecutor, as_completed def process_one(image_path, mask_path, output_path): inpaint_with_retry(image_path, mask_path, output_path) return output_path with ThreadPoolExecutor(max_workers4) as pool: futures [] for img_path in images: mask_path MASK_DIR / (img_path.stem _mask.png) out_path OUTPUT_DIR / img_path.name if out_path.exists(): continue futures.append(pool.submit(process_one, img_path, mask_path, out_path)) for fut in as_completed(futures): try: print(完成:, fut.result()) except Exception as exc: print(失败:, exc)注意两个细节。第一out_path.exists()就是断点续跑逻辑如果输出文件已经存在默认这张已经处理过了直接跳过。这招在批量跑到一半服务挂了、重新启动继续跑的时候特别管用。第二并发数不要贪多。我自己测试4到6个线程是比较甜点的区间再多的话GPU显存容易被打满单张处理速度反而下降还会增加请求失败概率。如果你的服务跑在CPU上线程数可以降到2到3个。4. mask 自动生成才是大步调三种方法解决水印定位mask是什么简单说它就是一张和原图同等尺寸的黑白图白色区域表示“这里需要修复”黑色区域表示“保持原样”。对lama-cleaner来说给它喂的mask越精准修复效果越好、越接近真实语义喂偏了要么该修的地方没修掉要么把不该动的区域也重绘了。批量场景里最难的不是调接口而是怎么自动化生成这些mask。下面三种方法覆盖了我实际遇到的大部分情况。4.1 固定位置水印bbox 矩形直接生成最常见的情况是水印位置基本固定比如视频截图的右上角、资料页右下角、模板图底部一条。这种直接用固定矩形生成mask就完了。我用OpenCV读图获取宽高再手动从配置文件里读坐标生成一张全黑的遮罩把水印所在的矩形区域填白。import cv2 import numpy as np def mask_by_bbox(img_path, x1, y1, x2, y2): img cv2.imread(img_path) h, w img.shape[:2] mask np.zeros((h, w), dtypenp.uint8) mask[y1:y2, x1:x2] 255 return mask坐标怎么确定我用一张代表性的图在画图工具里打开鼠标悬停显示坐标圈出水印外框四周多留5到10个像素。这里有一个非常容易忽略的点如果水印边缘离边界太近修复区域会直接贴到图片边缘lama的生成结果偶尔会在边界出现颜色断层。遇到这种情况保底方案是给mask区域额外留出一些背景边距让模型有足够上下文去“脑补”。另外坐标值建议写进一个配置文件或者常量里不要散落在代码各处否则换一批水印位置时改起来很痛苦。4.2 亮色文字像素阈值提取水印区域很多水印是白色或者高亮半透明文字比如“某某素材网”这类直接基于亮度阈值提取效果就不错。思路很简单转灰度图超过阈值的像素标记为白色mask。def mask_by_threshold(img_path, thresh200, expand5): img cv2.imread(img_path) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) _, mask cv2.threshold(gray, thresh, 255, cv2.THRESH_BINARY) kernel cv2.getStructuringElement(cv2.MORPH_RECT, (expand * 2 1, expand * 2 1)) mask cv2.dilate(mask, kernel, iterations1) return mask但这里有个坑如果图片本身有大片亮色区域比如白色背景上的白色桌面、蓝天、白墙阈值法会把它们也一起标成水印导致模型把这些正常内容重绘一遍。我的处理办法是先限定一个候选范围不让它在全图乱找。比如水印固定在底部那就先把图片底部三分之一截出来做阈值检测再把这个局部mask贴回全图。范围限定会让误检率大幅下降。阈值大小怎么调一般半透明白色水印在200左右能抓到纯白水印150到180就行灰色水印可能要到240以上。这个参数没标准答案多拿几张图试跑一下选一个漏检和误检平衡的阈值就好。4.3 差分法把水印当“背景噪音”剥离如果你的水印位置固定但背景每张图都不一样阈值法就会失效因为水印和背景叠加后的像素值不是一个稳定值。这种情况我更推荐差分法也是我实际项目里最依赖的方法。思路是这样的水印是恒定的“前景”背景内容是每张图不同的“噪声”。那我准备5到10张同构图的正常图片水印位置相同、内容不同把它们转成灰度后用像素级中位数叠成一张“标准背景图”。因为每张图内容不同中位数能抹掉大部分随机差异而水印由于恒定存在会被保留下来。然后用当前图和标准背景图做差差异大的区域就是水印候选。def build_background(image_paths): stack np.stack( [cv2.imread(p, cv2.IMREAD_GRAYSCALE) for p in image_paths], axis0 ) return np.median(stack, axis0) bg build_background([bg_01.jpg, bg_02.jpg, bg_03.jpg, bg_04.jpg]) current cv2.imread(target.jpg, cv2.IMREAD_GRAYSCALE) diff cv2.absdiff(current, bg) _, mask cv2.threshold(diff, 30, 255, cv2.THRESH_BINARY)差分法的优势是它不关心水印的亮度颜色只要水印在每张图中的位置基本一致就能提取出来。缺点是要求手头有若干张“正常内容不同、水印位置一致”的图。如果只有一张图要处理这个方法就没法用了。所以我的策略是按优先级排固定坐标bbox优先单图亮色水印用阈值多图同位置水印用差分。4.4 mask 后处理无论用哪种方法生成的mask都建议做两步后处理膨胀把白色区域向外扩张几像素避免修复结果在边缘留下半圈残影。膨胀太少水印边缘的浅色残留会非常明显膨胀太多会让修复范围扩大。一般3到5像素是合理范围。单通道确认确保生成的mask是单通道8位灰度图尺寸与原图完全一致。lama-cleaner接口对mask格式有要求彩色mask或者尺寸不一致的mask会直接报错。def post_process_mask(mask, expand3): kernel cv2.getStructuringElement(cv2.MORPH_RECT, (expand * 2 1, expand * 2 1)) mask cv2.dilate(mask, kernel, iterations1) return mask我记得第一次跑批量时脚本里没做膨胀结果几十张图的文字水印修完后都留下了一道淡淡的白色边线看起来很脏。后来把膨胀加上去这个问题才消失。这种细节不实际跑一遍真的很难预料。5. 实测效果与踩坑记录5.1 常见水印类型的成功率我拿不同类型的水印实测过一批图主观效果如下水印类型实测效果备注半透明白色文字高最理想lama基本能完全抹干净底部条带水印高区域大反而对lama有利上下文充足深色文字水印中高需要调阈值方向提取成功后效果不错彩色渐变Logo中处理简单背景时会留轻微残影大面积透明Logo叠加复杂花纹低建议人工处理别硬跑模型彩色渐变logo是相对难啃的骨头。因为橙红渐变色被阈值检测出来后容易把logo内部的原本颜色误判成待修复区域提交给模型后模型会尝试重绘这块区域出来的颜色有时会和周围不融合。如果批量遇到这种图我的建议是mask只覆盖logo的文字轮廓和色块边界不要大范围填白减少模型自由发挥的空间。5.2 踩坑清单这里把我在批量跑图过程中真正踩过、并且花时间排查过的坑整理成表后面你遇到了可以直接对照现象原因解决接口返回400图像带alpha通道或mask尺寸和原图不一致统一转RGBmask用单通道且尺寸对齐输出和原图一样mask全黑接口没收到有效待修复区域mask白区域才是要修复的部分修复后水印区域发灰mask太小或没膨胀模型未能覆盖残边膨胀3-5像素再提交请求卡住不返回单张处理超时或服务端异常设timeout重试一次重启服务跑了几十张后开始全失败并发太高或服务端进程不稳降并发重启服务必要时分批执行其中“输出和原图一样”这个坑最隐蔽它不会报错接口200正常返回肉眼不仔细看根本发现不了。我那次是脚本里mask生成逻辑写反了整批几百张全白跑一遍浪费了不少时间。所以批量跑完之后一定不要直接信脚本的“全部完成”必须抽几张图看看结果。5.3 批量验收用差异热力图筛选需要人工看的图批量跑完后几百张图一张张点开检查不现实。我的做法是生成差异热力图快速锁定哪些图需要人工复审。思路是把原图和修复图都转灰度做像素级差值的绝对值再统计差异较大的像素比例。修复区域如果被模型重绘过这些地方与原图的差异通常比较大正好可以用来定位。但需要注意模型重绘后即使修复成功差异依然存在所以这个指标不能直接等于“是否失败”我只会把它当“需要看一眼的排序依据”。def diff_ratio(src_path, dst_path, threshold30): a cv2.imread(src_path, cv2.IMREAD_GRAYSCALE) b cv2.imread(dst_path, cv2.IMREAD_GRAYSCALE) diff cv2.absdiff(a, b) return float((diff threshold).mean())批量计算每个输出文件的diff_ratio把结果从高到低排序优先检查前面那些差异大的图。这个流程能帮我快速过滤掉90%没问题的图把有限的肉眼时间全部花在可能存在问题的少数图上。最后再分享一个小技巧把原图、mask、修复图三张图横向拼成一张长图然后在文件夹里按“缩略图”模式滚动浏览一眼就能扫完整个批次的修复质量。比单独点开每一张图要高效得多。这套流程我目前一直在用后续如果再遇到新的水印形态只需要在mask生成层多写几个策略请求和调度层基本不用动。希望这篇能帮你把那堆带水印的素材早点处理干净。