完整记录：第一次使用fft npainting lama的踩坑经历-平芜编程栈

完整记录：第一次使用fft npainting lama的踩坑经历

1. 为什么是“第一次”？——一个真实新手的出发点

这不是一篇教科书式的教程，也不是一份冷冰冰的部署文档。这是一份带着温度、留着汗渍、夹杂着几声叹气的真实操作手记。

我是一名做内容运营的从业者，日常要处理大量宣传图、产品截图、活动海报。上周收到一张客户发来的老照片：背景杂乱、中间有明显水印、右下角还贴着一行碍眼的二维码。老板说：“下午三点前，发我干净版。”

我打开Photoshop，试了5分钟内容识别填充——失败；又试了几个在线AI修图工具，要么上传卡住，要么修复后边缘发灰、纹理断裂。时间一分一秒过去，我盯着屏幕，突然想起前两天在技术群里看到有人提过一个叫“fft npainting lama”的镜像，说是“专治各种图片乱入”。

没多想，我直接拉取镜像，准备上手。结果，从启动服务到导出第一张可用图，我花了整整2小时17分钟——其中至少43分钟在查日志、重试、重启、翻文档、截图问人。

这篇文章，就是我把那2小时17分钟里踩过的每一个坑、绕过的每一条弯路、悟出来的每一点门道，原原本本记下来。如果你也正站在和我一样的起点：没用过lama、不熟悉WebUI、连conda都没装过，但又急需解决一张图的问题——那么，请放心往下看。你不需要懂傅里叶变换，也不需要会写Python，只需要知道：哪些地方容易卡住，卡住了怎么解，以及，为什么它会卡在那里。

2. 启动之前：三个被忽略的前提条件

镜像文档里第一行就写着cd /root/cv_fft_inpainting_lama && bash start_app.sh，看起来无比简单。但我第一次执行时，终端只回显了一行报错：

bash: start_app.sh: No such file or directory

我愣了三秒——文件明明在镜像里，为什么找不到？

后来才发现，问题出在三个根本没被写进文档里的前提条件上：

2.1 权限不是“有就行”，而是“必须root”

这个镜像默认路径是/root/cv_fft_inpainting_lama，所有脚本、模型权重、输出目录都硬编码在root路径下。如果你用普通用户（比如ubuntu或user）启动容器，即使挂载了目录，start_app.sh也会因权限不足无法读取模型文件，最终静默失败。

正确做法：
启动容器时，必须指定--user root参数。例如：

docker run -d \ --user root \ -p 7860:7860 \ -v /your/local/output:/root/cv_fft_inpainting_lama/outputs \ --name lama-fft \ your-registry/fft-npainting-lama:latest

注意：不要试图用sudo去运行容器内命令——Docker容器内的用户上下文和宿主机是隔离的。--user root才是唯一有效解法。

2.2 端口冲突不是“偶尔发生”，而是“大概率存在”

文档说“访问 http://服务器IP:7860”，但没提一句：7860端口极可能已被Jupyter、Stable Diffusion或其他WebUI占用了。

我第一次启动后，在浏览器输入地址，页面一直转圈。curl http://127.0.0.1:7860返回Connection refused。查进程发现：

$ lsof -ti:7860 12345 $ ps aux | grep 12345 ubuntu 12345 0.1 2.3 1234567 89012 ? Sl Jan01 12:34 python app.py

原来是我昨天跑的一个SD WebUI还在后台占着端口。

正确做法：
启动前先清空端口，或换端口映射：

# 查杀占用7860的进程（谨慎！确认不是关键服务） sudo lsof -ti:7860 | xargs kill -9 # 或者直接映射到其他端口（修改WebUI监听端口需改app.py，不推荐） docker run -p 7861:7860 ...

2.3 模型文件不是“自带”，而是“需手动补全”

文档截图里那个清晰的WebUI界面，背后依赖一个约1.2GB的预训练模型文件：big-lama。但镜像本身并未内置该模型——它只提供了加载逻辑和脚本框架。

我执行start_app.sh后，日志里反复出现：

FileNotFoundError: [Errno 2] No such file or directory: '/root/cv_fft_inpainting_lama/models/best.ckpt'

翻源码才明白：start_app.sh会检查models/目录，若无best.ckpt，则自动退出，且不提示下载方式。

正确做法：
手动下载模型并放入对应路径：

# 进入容器 docker exec -it lama-fft bash # 创建目录并下载（官方模型，非盗链） mkdir -p /root/cv_fft_inpainting_lama/models cd /root/cv_fft_inpainting_lama/models wget https://github.com/saic-mdal/lama/releases/download/latest/big-lama.zip unzip big-lama.zip mv models/* . rm -rf models big-lama.zip

小技巧：模型文件名必须是best.ckpt，不能是model.ckpt或带版本号的文件。重命名即可。

3. 界面初体验：那些“看起来能点，其实点不动”的按钮

WebUI启动成功后，界面如文档截图所示，简洁明了。但真正开始操作，才发现几个“视觉陷阱”：

3.1 “上传区域”不支持中文路径，但错误提示为“空”

我拖拽一张名为会议现场_水印待去除.jpg的图进去，界面毫无反应，状态栏显示：

请先上传图像

我以为是网络问题，反复拖拽、刷新。直到我把文件重命名为test.jpg再试——立刻成功。

原因：前端JavaScript对中文文件名解析异常，触发了未捕获的Promise reject，但UI层未做兜底提示。

解决方案：

上传前，将文件名改为纯英文+数字（如pic1.jpg）
或使用“点击上传”而非拖拽（部分浏览器对拖拽中文路径兼容性更差）

3.2 “画笔大小滑块”调了没用？其实是单位理解错了

我拖动滑块从最左调到最右，发现画笔粗细几乎没变。放大画布仔细看，才发现：
滑块控制的是“像素直径”，不是“相对比例”。而我的图是4000×3000的大图，滑块最大值才64px——在整张图上，确实像一根细线。

正确姿势：

先用鼠标滚轮放大画布（Ctrl + 鼠标滚轮）
再调整滑块至32–48区间
对小瑕疵用8–16，对大水印用40–64

关键认知：这不是PS里的“画笔硬度”，而是“mask掩码的像素宽度”。它决定的是系统“认为多大范围属于待修复区”，不是“画得多粗”。

3.3 “ 开始修复”按钮灰色不可点？检查两个隐藏状态

按钮置灰，常见于两种情况：

图像已上传，但未生成mask（即没用画笔涂白）
→ 状态栏提示：“ 未检测到有效的mask标注”
图像已上传，也涂了白，但mask是纯黑（即误用了橡皮擦）
→ 界面无提示，按钮静默灰色。这是最隐蔽的坑。

快速自检法：
点击右上角“图层”按钮（Layers），查看当前mask图层是否为白色块。若为全黑或半透明灰，说明你刚用橡皮擦把整个mask擦没了。

救命操作：
点击“ 清除”按钮 → 重新上传 → 用画笔涂白 → 确保涂完后，左侧编辑区能看到清晰白色覆盖区（哪怕只是一个小点）。

4. 修复过程实录：从“边缘发虚”到“以假乱真”的三次迭代

我拿那张带水印的老照片做了三次尝试。每一次，都暴露了一个新认知：

4.1 第一次：边缘发灰、色差明显

操作：用大画笔（64px）直接涂抹水印区域，一键修复
结果：水印消失了，但修复区域明显比周围暗一个色阶，边缘有毛边
原因分析：
- 涂抹过宽，导致模型过度参考远处低频纹理，丢失局部色彩细节
- 未启用“边缘羽化”机制（该功能默认开启，但需mask有合理过渡）

改进方案：

用中等画笔（32px）沿水印边缘精细勾勒，让白色区域刚好覆盖水印+1–2像素外延
不追求“全覆盖”，而追求“精准包围”

4.2 第二次：纹理错乱、方向感丢失

操作：按改进方案重涂，修复后水印消失，但原图中一排整齐的砖墙纹理，在修复区变成了歪斜的波浪线
原因分析：
- 砖墙是强周期性结构，而lama基于频域建模（FFT核心），对高频重复纹理的相位重建敏感度高
- 单次修复试图“脑补”整块区域，易引入相位误差

改进方案：

分块修复：将砖墙区域横向切成3段，逐段涂抹、逐段修复
每次修复后，立即下载结果图，再作为新输入上传，继续下一段
利用“修复图→新输入”的链式处理，让模型每次只专注局部一致性

4.3 第三次：完美融合，肉眼难辨

操作：
1. 分三段修复砖墙（耗时约45秒）
2. 对水印正上方一小片天空区域，单独用小画笔（12px）修补云朵细节
3. 最后整体轻度锐化（此步在外部用GIMP完成，非lama能力）
结果：交付给老板，他盯着看了半分钟，问：“你是不是换了张原图？”

核心领悟：
lama不是“一键魔法”，而是“精准外科手术”。它的强大，不在于吞掉整张图然后吐出新图，而在于你指哪，它打哪，且打得足够深、足够准。你提供的mask越像“手术划线”，它给出的结果就越像“自然愈合”。

5. 输出与验证：别让成果卡在最后一步

修复完成后，右侧显示图像，状态栏写着：

完成！已保存至: /root/cv_fft_inpainting_lama/outputs/outputs_20260105142318.png

我兴冲冲去/root/cv_fft_inpainting_lama/outputs/找文件，却发现目录为空。

5.1 文件确实生成了，但权限锁死了

ls -l outputs/显示：

-rw------- 1 root root 2.1M Jan 5 14:23 outputs_20260105142318.png

权限是600，只有root可读。而我宿主机用普通用户挂载该目录，自然看不到。

解决方案（二选一）：

方法一（推荐）：启动容器时，加-u $(id -u):$(id -g)参数，让容器内进程以宿主机用户身份运行
方法二：进入容器，手动改权限：

docker exec -it lama-fft bash chmod 644 /root/cv_fft_inpainting_lama/outputs/*.png

5.2 PNG质量高 ≠ 显示效果好：注意Gamma校正

我下载的PNG在Windows照片查看器里看着偏暗，但在Chrome里正常。用Python读取像素值对比发现：

import cv2 img = cv2.imread("outputs_20260105142318.png") print(img[100,100]) # [124 131 138] —— 灰度正常

问题出在PNG元数据中的gAMA块（Gamma值）。某些旧版查看器会错误应用Gamma校正。

终极保险方案：
用PIL重存一遍，剥离所有非必要元数据：

from PIL import Image img = Image.open("outputs_20260105142318.png") img.save("clean_output.png", pnginfo=None)

6. 总结：这2小时17分钟教会我的6件事

1. 镜像不是“开箱即用”，而是“开箱即调”

它提供的是能力骨架，但肌肉（模型）、神经（权限）、血液（路径）都需要你亲手接上。

2. WebUI的“直观”，常掩盖底层的“脆弱”

拖拽上传、滑块调节、一键修复……这些交互设计极大降低了上手门槛，但也让你更容易忽略环境依赖、编码限制、权限边界等工程细节。

3. Mask不是“涂白”，而是“下指令”

你涂的每一笔，都在告诉模型：“这里的信息不可信，请用周围可信区域的统计规律重建”。涂得越准，指令越清晰，结果越可控。

4. 大图修复 ≠ 一次搞定，而是一次次“缩小问题域”

面对复杂场景，分区域、分层次、分阶段处理，比追求单次完美更高效、更可靠。

5. 输出路径只是起点，不是终点

文件生成了，不等于你能拿到；你能拿到了，不等于它能在所有设备上正确显示。交付前，务必在目标环境（客户电脑、微信、网页）做真机验证。

6. 所有“踩坑”，终将成为你的“直觉”

第一次花2小时修一张图，第二次可能只要20分钟；第三次，你会本能地避开所有坑，甚至开始优化流程——这才是技术落地最真实的成长曲线。

获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。

完整记录：第一次使用fft npainting lama的踩坑经历