简介：这套去水印系统源码为全开源交付，所有解析与处理逻辑均在本地实现，不依赖第三方接口，适合个人站长、PHP开发者以及关注隐私的用户快速部署或二次开发。压缩包共21.36MB，内含165个文件，其中76个PHP文件承担后端核心逻辑，35个JSON文件用于平台参数与配置管理，26个HTML页面构成前端界面，7个JavaScript文件负责交互，6个SQL文件提供数据库表结构，另附CSS样式、配置文件与使用说明，目录结构清晰，方便定位与修改。系统覆盖短视频、社交平台等多种链接的无水印解析与提取，从入口页面到接口返回均有完整实现，部署到PHP环境后即可直接使用已有功能。目前已有59人学习，对希望拥有私有去水印工具或学习PHP项目分层、接口设计、数据入库等内容的开发者而言，这套源码既可作为可直接运行的解决方案，也能作为二次开发的基线，在此基础上扩展更多平台支持。
1. 去水印系统不是“按钮”的事：全开源、本地实现能守住的三个底线
如果只是想偶尔去掉一张图的水印，搜“去水印系统”会得到一堆在线站点；但真亲手处理过批量照片、质检视频、扫描合同的人，很快会发现云端方案的两个硬伤：上传即暴露，对方服务器会不会留底完全不可控。标题里的“去水印系统源码/全开源/所有去水印功能在本地实现”，指的是另一条路：水印检测、修复、视频再编码全部在本地程序里完成，依赖的开源库和模型权重也全部落在本地。“所有去水印功能在本地实现”不只是一个隐私卖点，它顺带守住了三个底线：素材不离开运行环境、批量任务不被外部限速、任何一版处理参数都可以复现重跑。
这篇文章面向两类人：一类是要把一批带水印图片、视频、PDF清理干净的从业者，另一类是准备做去水印小程序源码、但不想把请求转发到别人“免费接口”里的开发者。我会按“搭最小系统—实现三类算法—批处理工程化—避坑—封装成接口”的顺序展开，尽量做到新手能照着敲，熟手能直接抄参数。
2. 先跑通最小去水印系统：OpenCV+FFmpeg环境、掩膜样本和第一个脚本
2.1 “全开源”不等于“万能去水印”：把系统拆成检测、掩膜、修复三段
先说结论：单靠开源代码并不能解决所有水印类型，但可以覆盖绝大多数“固定文字水印、半透明Logo、周期性纹理”场景。一个本地化去水印系统源码的本质，是把水印去除拆成“检测—掩膜—修复—再编码”四个环节，每个环节都用开源库填掉，而不是自己关起门写底层算法。
常见的组成是这样的：输入解析和视频拆帧交给FFmpeg；图像读写、灰度化、形态学处理、修复交给OpenCV；涉及频域滤波时用NumPy直接操作；最后还要把处理完的帧重新拼回视频。和“去水印小程序源码”那种把视频传到你控制不了的服务器上的思路不同，全开源+本地的意思是四段都发生在你自己的进程里，上传接口、任务队列、修复模型都在本机以内。
这套流程决定后面的所有代码组织。打开一个去水印项目时，最该先看的不是一个“process函数”，而是三个数据：输入素材格式清单、掩膜存放位置、输出编码设置。掩膜mask是整个系统的“黑匣子”，也是最值得多花时间的地方；掩膜不准，后面无论换成多强的修复算法都只会把错误扩散开。所以我会先花一小节讲清掩膜约定：凡是水印覆盖过的像素，在掩膜里应该是白（255），其余是黑（0）。
2.2 搭建本地运行环境：Python venv、OpenCV包和FFmpeg三件套
整个系统我习惯用Python做调度层。原因很直接：OpenCV-Python提供稳定的inpaint、形态学操作，FFmpeg负责底层封装解析，Python自身不需要多少性能，只是把开源能力组装成型。建一个干净的虚拟环境，省得后面装PyMuPDF、FastAPI时和系统Python包互相污染：
python -m venv venv # Windows 下激活： venv\Scripts\activate；Linux/macOS 下： source venv/bin/activate pip install opencv-python numpy pyyamlOpenCV在pip上的包名是opencv-python，安装后import cv2即可；它已经包含inpaint、dilate、threshold这些最常用的模块。如果后面要碰SIFT这类非免费算法，才需要换成opencv-contrib-python，这里先不加。FFmpeg不在pip里，按平台装完后，在终端确认ffmpeg -version能打出信息，并且ffprobe -version也在，视频环节要依赖这两个可执行文件读取帧率和时长。
环境搭好之后，优先准备一个带水印的测试文件和对应的掩膜。测试文件找一张自己截图的、带固定半透明Logo的图片就好；掩膜我一般先用图像编辑工具手动把Logo区域涂白，其余涂黑，存成PNG灰图。这张掩膜会作为后面所有自动检测效果的对照真值，也方便判断修复算法到底改动了哪些区域。
提示：掩膜不要用JPEG保存，JPEG压缩会在黑白交界处产生噪声；统一使用PNG灰图，后续阈值化才不会出现碎点。
2.3 第一个可复现的本地去水印脚本：膨胀掩膜、二值化、inpaint修复
有了原图和掩膜，最小组件的去水印逻辑就是OpenCV的inpaint。下面这段脚本是后续所有去水印源码的基础雏形，输入是原始图和灰阶掩膜，输出是修复后的图片：
from pathlib import Path import cv2 import numpy as np img = cv2.imread("input/demo.jpg") mask = cv2.imread("masks/demo_mask.png", cv2.IMREAD_GRAYSCALE) # 水印边缘有一圈半透明过渡像素，先膨胀一次再修复 kernel = np.ones((3, 3), np.uint8) mask = cv2.dilate(mask, kernel, iterations=1) # 把浅灰噪声变成纯黑纯白的掩膜 _, mask = cv2.threshold(mask, 20, 255, cv2.THRESH_BINARY) # inpaintRadius 控制修复扩散范围，先从小半径开始 clean = cv2.inpaint(img, mask, 8, cv2.INPAINT_TELEA) Path("output").mkdir(exist_ok=True) cv2.imwrite("output/demo_clean.png", clean)先看掩膜处理这段。膨胀的作用是把原本涂得跟水印边缘齐平的掩膜向外扩1到2个像素，因为很多半透明水印在边缘有抗锯齿渐变，修复时如果掩膜只盖住中间实白区域，边缘那道灰印就会被漏掉。阈值化把掩膜里手动涂色时留下的浅灰杂质清干净，避免inpaint把那些无关像素当成待修复区域看待。
最后一行inpaint是真正的修复动作：inpaintRadius=8表示修复算法会参考待修复区域边界外半径8像素的信息，常见取值范围在3到15之间；半径太小会留下细线，半径太大则会让修复区域周边的纹理跟着变形。flags参数有两种，INPAINT_TELEA和INPAINT_NAVIER_STOKES，前者在大多数文字水印、细Logo上的观感更自然，后者对边缘较粗的实心块更友好，后面还会细说。
这一小节跑通后，你手里就有了一套“掩膜+inpaint”的本地最小闭环，后续所有批量、视频、封装都是在这里加壳，而不是另起炉灶。
3. 三类本地去水印实现：单图修复、频域滤波和视频逐帧处理
3.1 单图去水印：Telea与Navier-Stokes的选型依据，以及半透明水印的阈值策略
单图去水印场景里最常遇到的是广告类图片——角落一个半透明Logo、页面下压一条横幅。这两类的惯用解法都是“以背景内容填充水印区域”，也就是inpaint。到底边界该选浅还是深几层，取决于掩膜质量。我先给出一个可以让掩膜自动识别半透明水印的脚本：如果水印颜色是纯白或纯黑，可以直接按灰度阈值定位；如果颜色和背景混杂，就退回手工标注。常见做法是用色彩范围抠图：
import cv2 import numpy as np def build_mask_from_color(img, lower, upper): # lower/upper 是 BGR 颜色下限和上限，适用于纯色半透明水印 lower = np.array(lower, dtype=np.uint8) upper = np.array(upper, dtype=np.uint8) mask = cv2.inRange(img, lower, upper) mask = cv2.morphologyEx(mask, cv2.MORPH_CLOSE, np.ones((5,5), np.uint8)) return mask img = cv2.imread("input/photo.png") mask = build_mask_from_color(img, [240, 240, 240], [255, 255, 255]) clean = cv2.inpaint(img, mask, 10, cv2.INPAINT_TELEA) cv2.imwrite("output/photo_clean.png", clean)这个脚本的价值在于“先建掩膜，再修复”。cv2.inRange只对颜色比较稳定的水印有效，因此我给参数解释时从来不说“自动检测一切水印”，而是强调它适合白色、黑色、固定RGB纹理等可分离场景。MORPH_CLOSE这一步用来填补掩膜内部的细小空洞，比如文字中间的镂空部分，否则修复后字母中间还会残留碎点。
对修复算法的选择另有一套规律：细笔画文字水印，首选INPAINT_TELEA，边缘更锐利；大面积实心Logo，INPAINT_NAVIER_STOKES的等照度线填充对纹理延续更友好，边缘不容易出现两道重影。以上两种都要求掩膜覆盖稍微超出实际水印区域，这也是“膨胀”在实际调用中不能省掉的原因。
inpaint毕竟不是“无中生有”，遇到大面积水印，修复出来的纹理再自然也只是周边纹理的推演。校对时不要只盯水印区域，要看水印周围的重复性纹理是否出现断裂或错位。如果错位明显，把inpaintRadius从10降到6，再不行就在掩膜上加较窄的模糊边缘。
3.2 半透明周期性水印：FFT局域陷波滤波，处理整页斜纹与规则点阵
有些水印不是“角落Logo”，而是覆盖整个画面的半透明斜纹、点阵或规则纹理，像设计稿套了“开发预览”背景，这种情况inpaint基本失控——修复区域和背景纹理几乎没有差别，算法没法判断什么才是正确背景。幸而这些规则纹理有一个特征：在傅里叶频谱上表现为离散亮斑。可以用NumPy把图像换到频域，去除亮斑后再逆变换回空间域。
我经常用下面这段来做频域去纹：
import cv2 import numpy as np def remove_periodic_watermark(img_gray, notch_centers, radius=3): f = np.fft.fft2(img_gray.astype(np.float32)) fshift = np.fft.fftshift(f) for (dx, dy) in notch_centers: # 把亮点区域置为邻域均值 patch = fshift[dx-radius:dx+radius+1, dy-radius:dy+radius+1] fshift[dx-radius:dx+radius+1, dy-radius:dy+radius+1] = patch.mean() f_ishift = np.fft.ifftshift(fshift) img_back = np.fft.ifft2(f_ishift).real return np.clip(img_back, 0, 255).astype(np.uint8) gray = cv2.cvtColor(cv2.imread("input/pattern.png"), cv2.COLOR_BGR2GRAY) rows, cols = gray.shape cx, cy = rows // 2, cols // 2 # 示例坐标：可视化频谱后，手工或用局部极大值定位亮斑 clean_gray = remove_periodic_watermark(gray, [(cx-45, cy), (cx+45, cy)])代码里的notch_centers是陷波中心点坐标组，通常需要先把频谱存成热力图看两眼找亮斑。之所以不直接写“自动找亮点”，是因为频谱亮斑的位置与斜纹方向和间距相关，半自动定位远比全自动可靠。radius=3意思是消除中心点周围边长7像素的方块，把该区域的复数幅度替换成邻域平均，从而压制对应频率。
需要注意的是，频域滤波只针对单通道灰图，如果水印有颜色，先把彩色图转换到Lab空间，只在亮度通道上做陷波，保留ab通道不变，这样不会连带把照片的色彩漂移掉。FFT方法对JD版扫描件里的灰底白字水印也一样有效，处理完再用inpaint修一下仍残留的高频边线，效果会干净很多。
3.3 视频去水印：抽帧维护统一掩膜、批量修复、再编码回视频
视频情况比单图复杂在有时间轴，但处理结构反而是最好照搬的：先把视频拆成一帧帧图片，批处理去水印，再按原帧率拼回去。固定位置的台标、角标水印最合适这种流程，因为全程只用一张固定掩膜。
先读取参数，确定帧率和帧数：
ffprobe -v error -select_streams v:0 -show_entries stream=r_width,r_height,r_frame_rate,nb_frames -of csv=p=0 input.mp4拿到宽度、高度、帧率和总帧数后，抽帧：
mkdir -p frames out ffmpeg -i input.mp4 -qscale:v 1 -start_number 0 frames/f_%05d.png抽帧命令里没有指定分辨率，保留原尺寸；-qscale:v 1是高质量帧采样的常用参数，对PNG是合适选项。接下来遍历frames目录，对每一帧执行和3.1完全相同的“膨胀+修复”逻辑。这里固定掩膜很关键，不要在每帧重新做阈值，否则水印边缘出现或消失都会被逐帧识别成不同大小，修复结果会“闪”。
最后按原帧率重组，编码参数我一般固定在这两档：
ffmpeg -framerate 25 -i out/f_%05d.png -c:v libx264 -crf 18 -preset medium -pix_fmt yuv420p output.mp4-crf 18是高质量档，在体积可控的情况下接近无损；-pix_fmt yuv420p保证大部分播放器能兼容。如果原视频不是25帧，务必把-framerate替换成ffprobe输出的真实帧率，否则时长和画面稳定性都会出问题。整个批处理环节到第四章会讲怎么并行，这里只注意一个性能事实：给720p视频拆成PNG序列，三分钟视频约4500张图，单进程修复会拖到比较慢，要有一个并行的思路。
4. 批处理工程化：把单图脚本扩展成配置文件、并行池和可清理的帧缓存
4.1 配置与源码分离：YAML固定掩膜、修复半径和视频编码参数
去水印系统源码如果只是一个单脚本，用起来会非常被动：换一批素材要改代码，换一个水印也要改代码，时间一长必翻车。我的做法是把可变参数搬到YAML配置文件，代码只负责读取和执行。这样每换一批素材，只需要新建一个配置目录，掩膜、修复半径、并行数、编码参数各就各位：
# config.yaml input_glob: "input/*.mp4" mask_path: "masks/logo_mask.png" inpaint_radius: 8 inpaint_flag: "TELEA" # TELEA 或 NAVIER_STOKES parallel_workers: 4 frame_rate: 25 video_crf: 18 video_preset: "medium" keep_frames: false脚本侧用yaml.safe_load把配置加载成dict，再据此决定执行路径：图片模式下不需要frame_rate，视频模式下需要读取ffprobe结果。配置文件的核心价值是让算法参数与业务参数解耦，视频目录变化时只改input_glob；水印类型变化时只改mask_path和inpaint_radius，不要动主程序。
提示：把 mask 文件命名成带版本号的名称，例如 logo_mask_v2.png。因为后续调整掩膜后会重新跑一批素材，如果找不到已经存过的mask，回溯效果就成了猜谜。
4.2 本地并行：ProcessPoolExecutor与掩膜只读共享
图像和视频帧的处理是典型的“数据并行”：每张图之间几乎没有共享状态，完全可以用多进程加速。但直接用multiprocessing.Pool调用OpenCV时，会遇到底层的线程竞争，处理速度反而下降。常见做法是让每个进程内部禁用OpenCV自身多线程，由进程池在进程之间分配任务。
import cv2 import numpy as np from concurrent.futures import ProcessPoolExecutor from pathlib import Path MASK = None def init_worker(mask_path): global MASK MASK = cv2.imread(mask_path, cv2.IMREAD_GRAYSCALE) cv2.setNumThreads(0) def clean_one(item): src_path, out_dir = item img = cv2.imread(str(src_path)) clean = cv2.inpaint(img, MASK, 8, cv2.INPAINT_TELEA) out_path = Path(out_dir) / src_path.name cv2.imwrite(str(out_path), clean) return str(out_path) def run_batch(config): files = list(Path("input").glob(config["input_glob"])) out_root = Path("out") out_root.mkdir(exist_ok=True) tasks = [(p, out_root) for p in files] with ProcessPoolExecutor( max_workers=config["parallel_workers"], initializer=init_worker, initargs=(config["mask_path"],) ) as pool: list(pool.map(clean_one, tasks))这段代码有一个值得注意的点：mask不跟随每个任务传参，而是在init_worker里每个worker只读取一次。因为OpenCV的inpaint对掩膜是只读的，进程内共用一份掩膜不会发生并发写问题；如果像最初版本那样把mask当作任务参数传，大掩膜数组会每个文件都被pickle一次，开销很大。max_workers一般设置在CPU物理核心数附近，不建议超过逻辑线程数，否则在视频帧的大量小任务场景下，进程切换成本会把收益吃掉。
4.3 计算临时帧缓存：抽帧格式、磁盘占用与清理策略
视频抽帧去水印必然产生中间文件。这块一度被我忽略，结果一个5分钟1080p视频直接吃掉十几个GB磁盘，项目租的小服务器当场写满。现在我会在批量跑之前先估算，估完之后决定抽帧格式和清理策略。
中间文件有三个选择：PNG、无损压缩的TIFF、JPG，各有侧重。PNG单帧占用大但无损且后续修复稳定；TIFF在OpenCV读写上兼容性略差；JPG虽然省空间，但质量损失叠加到最终视频上会看到颗粒感。如果只是为了对比掩膜效果，临时用JPG没关系；一旦要产出最终文件，我建议保持PNG或高质量PPM。
| 帧格式 | 单张三分钟720p典型大小 | 适用阶段 |
|---|---|---|
| PNG | 2~4 MB | 最终流水线，修复稳定 |
| JPG(quality 92+) | 0.4~0.8 MB | 掩膜调试、试跑参数 |
| TIFF | 3~6 MB | 极少用，兼容性一般 |
一个三分钟720p@25fps视频有4500帧，用PNG总磁盘消耗约9~18GB。长视频或1080p更夸张。所以在批处理跑完后，临时frames和out下若没有保留价值，就直接清空；如果中途要暂停，也会先删掉已完成部分再继续。
du -sh frames out rm -rf frames out如果磁盘空间紧，另一种思路是不落盘、用管道把ffmpeg接入Python，让帧在内存中流转，但内存占用和部署复杂度都会上升，建议先落盘把效果跑通，再做优化。
5. 去水印系统避坑记录：重影、闪烁、PDF与中文路径的现场排查
5.1 修完反而多一圈轮廓：掩膜边缘没盖全
现象：文字水印修复后干净了，但水印四周反而留下一条更深更重的“阴影边”或半透明的反色轮廓，在浅色背景上尤其明显。
原因：掩膜只在纯白文字中心部分，水印文字的半透明渐变边缘没有被覆盖。inpaint会把这些边缘误当成需要保留的前景，结果在尝试用背景填充时，边缘像素与背景色混在一起，视觉上就成了重影。
解决：在掩膜上先膨胀一两圈，再做一次小半径的高斯模糊，让掩膜边缘从纯白平滑过渡到纯黑。代码上很容易补：
mask = cv2.dilate(mask, np.ones((3,3), np.uint8), iterations=2) mask = cv2.GaussianBlur(mask, (3,3), 0)这样inpaint会把膨胀后的区域也纳入填充，而高斯模糊让边缘信息参与修复时更自然。如果重影还很明显，就把iterations再增加1次或把GaussianBlur核扩大到5×5，接着用同一张掩膜重跑。
5.2 视频去水印后水印区域“闪烁”
现象：视频去水印完，角标区域整体干净，但播放到第几秒时，固定水印附近背景有轻微明暗变化，像灯光在呼吸。
原因：往深层看有两个叠加因素。第一，ffmpeg抽帧、逐帧修复后，压缩噪声在每一帧都不一样；第二，掩膜如果稍微覆盖到了水印边缘，边缘的小噪声被修复算法识别为待填充边界，修复结果依赖边缘噪声，导致每一帧拿到的新像素有微小差异。这些差异在单张图上几乎看不出来，但连续播放时就会形成闪烁。
解决：核心是让修复结果的时间一致性更高，而不是让程序每帧都自主发挥。步骤有三条：一是全序列复用同一张掩膜，绝不在每帧重新自动检测；二是输入帧先做一次轻微的降噪，再进inpaint；三是把inpaintRadius固定在一个值，不要在不同帧之间浮动。相关代码片段如下：
mask = cv2.imread("masks/logo_mask.png", cv2.IMREAD_GRAYSCALE) kernel = np.ones((3,3), np.uint8) mask = cv2.dilate(mask, kernel, iterations=2) for frame_path in sorted(frames_dir.glob("*.png")): frame = cv2.imread(str(frame_path)) frame = cv2.fastNlMeansDenoisingColored(frame, None, 3, 3, 7, 21) clean_frame = cv2.inpaint(frame, mask, 10, cv2.INPAINT_TELEA) cv2.imwrite(str(out_dir / frame_path.name), clean_frame)如果素材背景长时间静止，还有个更取巧的方案：用中位帧直接替换水印区域，可以彻底不闪烁，但这套方案只适合摄像机基本静止的视频，运动场景照样翻车。总来说，时间一致性比单帧像素精度更难，这也是我总说不要指望靠逐帧调参解决闪烁的原因。
5.3 PDF免费去水印对扫描件失效：文字对象和图像底料要分开处理
现象：网上常说PDF免费去水印，但把扫描版PDF导入本地去水印系统，处理后背景图变了，水印文字还在页面上；或者屏幕上看没了、打印出来又出现，异常诡异。
原因：对PDF而言，水印至少分两种。一种是文本图层里的文字对象，直接渲染在页面上，它的位置写在内容流里；另一种是扫描件里的半透明像素水印，躺在背景图片的像素里。只走图像修复通道，对第二种有效，对第一种根本没有作用，因为该像素的水印色来自文字对象的前景色，而背景像素本身是干净的。
解决：处理文字层水印时，要先读PDF文档对象，把特定文字块过滤掉。用PyMuPDF判断一个文字是不是水印，核心就是比对字体名、文本内容和位置：
import fitz # PyMuPDF doc = fitz.open("scanned_notice.pdf") for page in doc: for block in page.get_text("dict")["blocks"]: if block["type"] != 0: continue for line in block["lines"]: for span in line["spans"]: if "评估专用" in span["text"]: page.add_redact_annot(span["bbox"], fill=(255,255,255)) page.apply_redactions() doc.save("output.pdf")扫描件这种情况，正确的调用链是先用渲染方式把PDF每页导出成图片，走到第三章的inpaint通道把像素水印清掉，再用PyMuPDF重建页面。很多桌面PDF工具不敢开放去水印功能，就是因为他们统一当作图像处理，对文本水印没用还破坏排版。我们做源码系统时，一定要把这两条路径分到不同的处理函数里。
5.4 中文文件名和空格把FFmpeg子进程干崩
现象：素材“公司资料 最终版.mp4”进入批处理后，抽帧命令报错No such file or directory；换成中文文件名的小图又偶发，程序时好时坏，很玄学。
原因：多数情况下不是文件名本身非法，而是Python用shell=True调用命令时，路径中的空格和中文字节在Windows路径上被拆破或编码出错。尤其中文Windows默认控制台代码页和系统ANSI编码不完全一致，子进程传参一旦经过shell，就不可预测。
解决：我给自己定下的规则是——凡是批处理脚本，统一先把素材复制到一个纯ASCII的临时工作目录，再交给ffmpeg和OpenCV；处理完再移回原目录。这一步看似绕，实际上省掉后续90%的编码问题：
import shutil from pathlib import Path src = Path("公司资料 最终版.mp4") work_dir = Path("tmp_ascii") dst = work_dir / "input.mp4" shutil.copy(src, dst) # 后续 ffmpeg/Python 只用 dst 的纯 ASCII 路径其次，调用ffmpeg时别用subprocess.run(f"ffmpeg ... {file}")这种字符串拼接，换成直接把参数组成列表传：
cmd = ["ffmpeg", "-i", str(dst), "-qscale:v", "1", "frames/f_%05d.png"] subprocess.run(cmd, check=True)这样避免shell介入路径。排查顺序很简单：先确认ffprobe能读，再确认临时目录无空格、无中文，最后怀疑代码里的引号转义。按这个顺序查，基本能解决90%的“ffmpeg突然跑不了”。
5.5 把“自动识别任意水印”设为目标：预期管理比模型更重要
现象：系统刚做出来，拿给同事试用，同事丢来一张正中央大字水印、背景还很凌乱的宣传图，点名希望全自动识别并去除。结果系统没认出，同事直接说这个方案不行。
原因：水印的样式太分散，文字、Logo、半透明、纹理、人物本身都可能是水印，不可能用一套通用算法包打天下。所谓“所有去水印功能在本地实现”是指去水印的处理链完全在本地，并非指自动识别所有水印。本地系统在已知水印场景下可以做到准确，在未知水印场景下只能提供半自动辅助。
解决：给系统设计两块能力，一块是全自动批处理，专门处理同一套台标、同一套Logo的系列素材；另一块是半自动“框选—生成掩膜—修复”，由用户手动标出水印区域，代码只根据框自动生成掩膜。这样既安全又可用，更重要的是这符合真实业务场景，不会一上来就闹翻车。把预期管理的边界在系统文档里写清楚，比堆模型更实在。
6. 落地到本地API：用FastAPI暴露去水印接口，用PSNR/SSIM给效果“上秤”
6.1 FastAPI注入一个本地处理入口
当我不再需要打开终端手动跑脚本时，最常采用FastAPI给这套源码做一个HTTP封装。它能迎合两种部署场景：给内网同事一个可上传图片的Web页面；或者把后台服务挂到内网，供去水印小程序源码这类前端壳调用。
from fastapi import FastAPI, UploadFile from fastapi.responses import Response import cv2 import numpy as np app = FastAPI() @app.post("/clean-image") async def clean_image(file: UploadFile): data = await file.read() img = cv2.imdecode(np.frombuffer(data, np.uint8), cv2.IMREAD_COLOR) mask = cv2.imread("masks/current_mask.png", cv2.IMREAD_GRAYSCALE) result = cv2.inpaint(img, mask, 8, cv2.INPAINT_TELEA) ok, encoded = cv2.imencode(".png", result) return Response(content=encoded.tobytes(), media_type="image/png")接口本身没有任何云端第三方依赖，上传的图片只在本地进程中流转，这就是标题里所谓“所有去水印功能在本地实现”的落地形态。启动时用uvicorn app:app --host 127.0.0.1 --port 8000。注意不要在生产环境把worker数开很高，inpaint是纯CPU任务，并发量越大排队越多，内部加一个队列更稳。
6.2 用PSNR/SSIM给去水印效果做定量验收
最后要给自己一个“到底修得好不好”的可量化答案，不能只靠肉眼。常见做法是拿一段包含水印的素材，准备同一镜头无水印版的前几帧当参考，把修复结果和真值计算PSNR、SSIM。
def psnr(a, b): a = a.astype(np.float32); b = b.astype(np.float32) mse = np.mean((a - b) ** 2) if mse == 0: return 100 return 10 * np.log10(255.0 ** 2 / mse)PSNR在30dB以上基本可靠，SSIM则更看重结构相似性，计算时掩膜区域外不参与，避免干扰。我现在的习惯是每改一次参数就固定用同一组样例跑底，把PSNR、SSIM和当时用的radius、mask版本记下来，不然下次翻车时会记不清改动。这套记录习惯让我省了不少后悔药，希望帮到你。
本文还有配套的精品资源，点击获取
