FFT NPainting LaMa自动化脚本设想：批量修复可行性探讨
1. 背景与核心价值：为什么需要批量修复能力？
你有没有遇到过这样的场景：手头有200张电商商品图，每张都带平台水印；或者整理老照片时发现几十张合影里都有路人闯入；又或者在做设计素材库时，需要统一清除上百张图片中的临时标注线？手动一张张打开WebUI、上传、画笔标注、点击修复、下载……光是重复操作就足够让人崩溃。
FFT NPainting LaMa这套图像修复系统，本身已经非常成熟——它基于LaMa模型，结合频域增强（FFT）优化，在移除物体、擦除水印、修复瑕疵等任务上效果自然、边缘融合度高。但它的默认形态是交互式WebUI，面向单图精细操作。而真实工作流中，大量需求恰恰是“模式固定、数量庞大、质量要求可控”的批量任务。
本文不讲原理、不堆参数，只聚焦一个工程师最关心的问题：能不能绕过浏览器，用脚本把这套能力“工业化”？换句话说——如何让LaMa修复从“手工作坊”升级为“自动产线”？我们将从技术路径、可行方案、实操陷阱和落地建议四个维度，给出一条清晰、可验证、不依赖魔改模型的批量修复路线。
2. 技术可行性分析：WebUI不是黑箱，而是可编程接口
很多人误以为WebUI只是个图形界面，背后逻辑不可触达。实际上，FFT NPainting LaMa的WebUI（基于Gradio构建）本质是一个HTTP服务，所有按钮点击、图像上传、参数调整，最终都转化为标准API调用。只要找到入口，就能用Python脚本直接驱动。
2.1 WebUI底层通信机制解析
当你点击“ 开始修复”时，浏览器实际发送了一个POST请求到：
http://localhost:7860/run/predict携带的JSON体包含三类关键数据：
data: 图像Base64编码 + 标注掩码（mask）的Base64 + 模型参数fn_index: 函数索引（对应WebUI中第几个处理函数）session_hash: 会话标识（用于状态管理）
这意味着：你不需要模拟鼠标点击，也不需要Selenium爬网页，只需构造合法请求即可完成全流程。
2.2 批量修复的两种实现路径对比
| 路径 | 原理 | 优势 | 风险点 | 适合场景 |
|---|---|---|---|---|
| API直连模式 | 直接调用/run/predict接口，传入图像+mask | 响应快、无GUI开销、易集成进CI/CD | 需解析Gradio内部协议，对fn_index敏感，版本升级易失效 | 已稳定运行的生产环境，追求极致效率 |
| Headless Gradio模式 | 启动Gradio服务后，用gradio_client库调用（官方推荐） | 接口稳定、自动适配版本、支持异步、文档完善 | 需额外安装gradio_client、首次连接略慢、内存占用稍高 | 快速验证、多模型切换、非强实时场景 |
结论明确：两种路径均完全可行。本文后续示例采用
gradio_client方式——它更鲁棒、更贴近开发者日常习惯，且无需深挖Gradio私有协议。
3. 实战脚本：50行代码实现全自动批量修复
以下是一个完整、可直接运行的Python脚本，目标：读取input/目录下所有PNG/JPG图片，对预设区域（如右下角100×100像素）自动打掩码并修复，结果存入output/目录。
3.1 环境准备（仅需3步）
# 1. 确保WebUI已启动（后台运行，不阻塞终端） nohup bash /root/cv_fft_inpainting_lama/start_app.sh > /dev/null 2>&1 & # 2. 安装客户端（仅需一次） pip install gradio-client # 3. 创建输入输出目录 mkdir -p input output3.2 核心脚本（batch_inpaint.py）
# -*- coding: utf-8 -*- """ FFT NPainting LaMa 批量修复脚本 功能：自动对图片右下角100x100区域打掩码并修复 作者：科哥（适配v1.0.0 WebUI） """ import os import time from PIL import Image, ImageDraw, ImageOps import numpy as np from gradio_client import Client # ===== 配置区（按需修改）===== INPUT_DIR = "input" # 输入图片目录 OUTPUT_DIR = "output" # 输出目录 MASK_REGION = (100, 100) # 掩码尺寸：宽×高（像素） MASK_OFFSET = (-100, -100) # 掩码位置偏移（负值=右下角） WEBUI_URL = "http://127.0.0.1:7860" # 本地服务地址 # ===== 初始化客户端 ===== print("🔧 正在连接WebUI服务...") try: client = Client(WEBUI_URL) print(" 连接成功！") except Exception as e: print(f"❌ 连接失败：{e}") exit(1) # ===== 批量处理主循环 ===== for filename in sorted(os.listdir(INPUT_DIR)): if not filename.lower().endswith(('.png', '.jpg', '.jpeg', '.webp')): continue input_path = os.path.join(INPUT_DIR, filename) output_path = os.path.join(OUTPUT_DIR, f"fixed_{filename}") print(f"\n🖼 处理 {filename} ...") # 步骤1：加载原图并生成掩码（白色区域=待修复） try: img = Image.open(input_path).convert("RGB") w, h = img.size # 创建全黑掩码图（LaMa要求：黑色=保留，白色=修复） mask = Image.new("L", (w, h), 0) # 黑底 draw = ImageDraw.Draw(mask) # 计算右下角100x100区域坐标 x1 = max(0, w + MASK_OFFSET[0] - MASK_REGION[0]) y1 = max(0, h + MASK_OFFSET[1] - MASK_REGION[1]) x2 = min(w, x1 + MASK_REGION[0]) y2 = min(h, y1 + MASK_REGION[1]) draw.rectangle([x1, y1, x2, y2], fill=255) # 白色矩形 # 步骤2：调用WebUI修复（关键：传入图像+掩码） result = client.predict( dict(image=img, mask=mask), # 输入：字典格式，含image和mask api_name="/inpaint" # 固定端点，对应WebUI的inpaint函数 ) # result是元组，第一个元素是修复后的PIL Image fixed_img = result[0] fixed_img.save(output_path) print(f" 已保存 → {output_path}") except Exception as e: print(f"❌ 处理失败：{e}") continue # 步骤3：防抖动，避免请求过密（可选） time.sleep(0.5) print("\n 批量修复全部完成！")3.3 脚本关键点说明（为什么能跑通？）
- 掩码生成逻辑：LaMa要求掩码中白色（255）表示待修复区域，黑色（0）表示保留区域。脚本用PIL动态生成，精准控制位置和大小。
- API调用精简：
client.predict()直接传入dict(image=img, mask=mask)，无需手动Base64编码——gradio_client自动处理。 - 错误防御：每个文件独立try-catch，单张失败不影响整体流程。
- 零GUI依赖：全程无浏览器、无截图、无坐标定位，纯HTTP通信。
小技巧：若需修复“任意物体”，可先用YOLOv8检测出物体框，再将框坐标转为掩码区域——这正是工业级自动化的起点。
4. 进阶能力拓展：从“能跑”到“好用”的4个关键升级
脚本跑通只是第一步。要真正投入生产，还需解决四个现实问题：
4.1 掩码智能化：告别固定区域，拥抱语义理解
手动画框太原始。升级方案：
- 方案A（轻量）：集成
segment-anything（SAM），对输入图一键生成物体分割掩码，再传给LaMa。 - 方案B（精准）：用CLIP文本引导，输入提示词如“remove watermark”，自动定位水印区域。
- 效果对比：固定掩码修复水印可能残留边角；SAM掩码可完美贴合文字轮廓，修复更干净。
4.2 流程自动化：串联上下游，打造完整流水线
单次修复只是环节之一。典型工作流：
原始图 → [去水印] → [统一尺寸] → [添加新Logo] → [生成多尺寸] → [上传CDN]脚本可扩展为：
# 伪代码示意 for img in batch: img = remove_watermark(img) # 调用LaMa API img = resize_to_1080p(img) # PIL处理 img = add_company_logo(img) # OpenCV叠加 upload_to_cdn(img) # 调用OSS/七牛API4.3 状态监控：拒绝“黑盒运行”，掌握每一步进展
生产环境必须可观测：
- 在脚本中加入日志记录：
logging.info(f"{filename} | mask_size:{mask_area} | time:{t}s") - 输出CSV统计表：文件名、原图尺寸、掩码面积、处理耗时、输出PSNR（可选）
- 集成Prometheus：暴露
/metrics端点，监控QPS、平均延迟、失败率
4.4 异常兜底：当AI失效时，人工快速介入
再好的自动化也需要逃生通道：
- 自动识别低置信度结果（如修复后PSNR < 28dB），标记为
needs_review - 将待审图片推送到企业微信/钉钉群，附带修复前后对比图+一键跳转WebUI链接
- 运维人员点击链接，直接在WebUI中微调掩码后重试，结果自动覆盖原文件
5. 风险与边界：哪些事批量脚本也搞不定？
技术乐观主义很重要，但清醒认知边界同样关键。以下场景不建议强行批量自动化：
高度依赖上下文判断的修复
例如：“把这张合影里穿红衣服的陌生人去掉，但保留他背后的风景和旁边人的影子”。当前LaMa无法理解“红衣服”“陌生人”等语义，需人工圈选。超大分辨率图像（>4000px）
WebUI默认限制显存，单图处理可能OOM。批量脚本会直接报错。解决方案：预处理缩放（影响精度）或改用Triton部署模型（工程成本高）。需要多轮迭代的复杂修复
如先去水印→再修反光→最后调色。每步依赖上步结果，且需人工评估中间效果。此时“半自动”（脚本+人工确认点）比全自动更可靠。版权敏感内容
批量处理用户上传图片时，务必确保：① 掩码生成逻辑不上传原始图到第三方；② 修复结果不缓存到公共服务器；③ 日志脱敏（不记录文件名中的用户ID）。
重要提醒：本文所有脚本均在本地离线环境运行，所有图像、掩码、模型均不离开你的服务器。这是保障数据安全的底线。
6. 总结：批量修复不是替代人，而是放大人的能力
回看开头那个200张水印图的场景——如果坚持手动，大概需要3小时；用本文脚本，12分钟搞定，且效果一致性远超人工。但这12分钟的价值，远不止于节省时间：
- 它把“重复劳动”转化成了“策略配置”：下次换水印位置？只需改两行代码里的
MASK_OFFSET。 - 它把“经验直觉”沉淀为了“可复用逻辑”：今天写的SAM+LaMa组合，明天就能用在视频帧修复上。
- 它让技术决策有了量化依据：当看到CSV里显示“98%的图片修复耗时<15秒”，你才有底气向业务方承诺SLA。
FFT NPainting LaMa的真正潜力，从来不在单张图的惊艳效果，而在于它能否成为你工作流中那个沉默却可靠的“数字工人”。而批量脚本，就是给这个工人发的第一份正式工牌。
现在，你只需要做一件事：把脚本复制进服务器，放入几张测试图，然后按下回车。剩下的，交给代码。
7. 下一步行动建议
- 立刻尝试：用脚本处理5张图，验证基础流程
- 定制掩码：将
MASK_REGION改为你的实际需求（如水印坐标、物体检测框） - 接入监控：加一行
logging，观察首张图的处理耗时 - 规划扩展：想清楚下一个要自动化的环节是什么？是尺寸统一，还是格式转换？
技术的价值，永远体现在它让什么变得“理所当然”。当移除水印不再需要思考，当修复瑕疵变成一个命令，那才是AI真正融入工作的时刻。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
