AI 图片与视频处理 — 从原理到实践
·
摘要：AI 图片/视频处理与文本 LLM 分属两种技术范式——前者处理"像素空间的生成与变换"，后者处理"语义空间的推理与补全"。图片模型的额外复杂度不在于"是否本地部署"，而在于推理过程是多个子模型协作的管线。
一、能力全景：AI 在图片与视频领域的边界
在深入技术细节之前，首先建立对 AI 图片/视频处理能力的整体认知——它能做什么、不能做什么，以及整个工具生态的分层结构。
1.1 六类图片任务
输入 输出 典型用例
─────────────────────────────────────────────────────────────
① 文生图 一段文字 一张新图 根据描述生成全新图片
② 图生图 一张图+文字 一张变体图 将照片转换为特定艺术风格
③ Inpainting 一张图+遮罩 一张修复图 移除画面中的多余物体
④ Outpainting 一张图 一张扩展图 扩展画幅，AI 补全新增区域
⑤ 超分放大 一张小图 一张大图 提升分辨率并保持清晰度
⑥ 图片理解 一张图 一段文字 识别内容、提取结构化信息
上述六类任务并非各自对应独立的模型——其底层共享同一套扩散模型架构，区别仅在于输入条件的不同组合。
1.2 视频任务
| 任务 | 输入 → 输出 |
|---|---|
| 文生视频 | 一段文字 → 一段数秒的视频 |
| 图生视频 | 一张静态图片 → 动态视频 |
| 视频编辑 | 一段视频 + 文字指令 → 修改后的视频 |
| 视频超分 | 低分辨率视频 → 高分辨率视频 |
| 风格迁移 | 视频 → 应用特定风格的视频 |
1.3 当前技术的局限性
- ❌ 在保留真实背景的前提下移除大面积物体——生成式模型倾向于"虚构"背景内容，而非"延续"原有场景
- ❌ 生成图片中的文字准确渲染（2026 年刚取得突破，仍未完全解决）
- ❌ 长视频（超过 2 分钟）中保持角色外貌和场景风格的一致性
- ❌ 精确控制人体细节部位（手指数量、牙齿形态等常见问题）
- ❌ 在消费级显卡（8GB VRAM）上进行 4K 视频生成
1.4 五层生态结构
AI 图片/视频处理的工具链可划分为五个层次。理解这一分层结构，有助于在接触新工具时快速定位其所属层级和依赖关系。
┌─────────────────────────────────────────────────────────┐
│ 第 5 层：用户界面 │
│ ComfyUI（节点式编排） / WebUI（图形界面） / 代码直接调用 │
├─────────────────────────────────────────────────────────┤
│ 第 4 层：模型权重（.safetensors / .ckpt 文件） │
│ FLUX.1 / SD 3.5 / Qwen-Image / Wan 2.7 / Kling ... │
│ 训练得到的参数文件，日常所说的"下载模型"即指此层 │
├─────────────────────────────────────────────────────────┤
│ 第 3 层：工具库（Python 包） │
│ diffusers / transformers / opencv / onnxruntime │
│ 将第 2 层的底层操作封装为高层 API │
├─────────────────────────────────────────────────────────┤
│ 第 2 层：深度学习框架 │
│ PyTorch / ONNX Runtime / llama.cpp │
│ AI 模型的运行时环境，类比 Java 程序的 JVM │
│ │
│ 注：文本 LLM 还有另一条技术路线——llama.cpp（C++ 实现）， │
│ 完全不依赖 PyTorch，直接被 Ollama 用作底层推理引擎。 │
│ 图片模型当前以 PyTorch + diffusers 路线为主，暂无 │
│ llama.cpp 等价物（多组件管线难以用统一 C++ 引擎覆盖）。 │
├─────────────────────────────────────────────────────────┤
│ 第 1 层：硬件与驱动 │
│ NVIDIA GPU + CUDA + cuDNN │
│ AI 推理的物理计算基础；无 GPU 时可使用 CPU，但速度大幅下降 │
└─────────────────────────────────────────────────────────┘
关键认知：
- 日常所说的"下载一个模型"，实际下载的是第 4 层的
.safetensors权重文件。但该文件必须依赖第 1~3 层的完整环境才能运行——下面三层缺一不可。 - Ollama 的特殊性：Ollama 的管理层（Go 编写）负责模型下载和 API 暴露，但其底层推理引擎是 llama.cpp（C++），这个引擎绕过了 PyTorch（第 2 层）直接从 CUDA/CPU 执行推理。因此 Ollama 在技术栈上跨越了第 2-3 层——它用一个统一的可执行文件同时替代了"框架+库"的角色。图片模型领域暂无此类统一工具。
1.5 远程 API 与本地部署
一个常见误解是"图片模型必须下载到本地才能使用"。实际上，图片模型与文本 LLM 一样，同时支持远程 API 调用和本地部署两种模式。
# 文本 LLM 的 API 调用（常见模式）
from openai import OpenAI
client = OpenAI(base_url="https://api.deepseek.com", api_key="sk-xxx")
response = client.chat.completions.create(model="deepseek-chat", messages=[...])
# 图片模型的 API 调用——调用方式完全一致，仅端点不同
from openai import OpenAI
client = OpenAI(base_url="https://api.siliconflow.cn/v1", api_key="sk-xxx")
response = client.images.generate(model="FLUX.1-dev", prompt="一只猫")
文本 LLM 图片模型
──────── ────────
远程 API 模式 调用 DeepSeek API 调用 Kling / SiliconFlow API
→ 模型运行在服务端 → 模型运行在服务端
→ 本地无需 GPU → 本地无需 GPU
→ 按 Token 量计费 → 按张数或时长计费
本地部署模式 Ollama + Qwen 本地运行 diffusers + FLUX 本地运行
→ 模型权重下载至本地 → 模型权重下载至本地
→ 免费，需配备 GPU → 免费，需配备 GPU
→ 单一模型推理 → 多子模型管线（额外复杂度来源）
远程 API 与本地部署并非互斥选择，而是两种按需切换的使用模式。 学习阶段建议走本地路线以理解管线原理，生产环境则按场景灵活选择。
二、环境地基：五层生态的逐层解析
第一章介绍了五层生态结构的全貌，本章自底向上逐层展开——说明每层是什么、为什么需要、以及如何验证安装正确。
2.1 第 1 层：CUDA — AI 推理的物理引擎
Python 代码
↓
PyTorch（"执行矩阵乘法运算"）
↓
CUDA（将运算指令翻译为 GPU 可执行的指令）
↓
GPU 硬件（数千计算核心并行处理）
↓
返回计算结果
- 无 NVIDIA 显卡 → 只能使用 CPU 进行推理 → 速度下降 10-100 倍，但推理仍可进行
- 有 NVIDIA 显卡但未安装 CUDA → PyTorch 检测不到 GPU → 自动回退至 CPU 模式
- CUDA 版本与 PyTorch 版本必须匹配——约 80% 的环境问题源于此二者版本不兼容
2.2 第 2 层：PyTorch — AI 模型的运行时
PyTorch 是所有 AI 模型推理的运行时环境。类比：运行 Java 程序需要 JVM，运行 AI 模型需要 PyTorch。
提供的两项核心能力：
- 张量运算：numpy 的 GPU 加速等价物（
torch.Tensor的数据模型与numpy.ndarray类似，但可在 GPU 上执行） - 自动求导：训练阶段使用，推理阶段不需要，但模型的网络结构定义依赖此机制
Python 3.14 无法安装 PyTorch 的原因：PyTorch 底层包含大量 C++ 扩展代码（CUDA 交互层、算子优化等），需针对各 Python 版本分别编译。每当新的 Python 版本发布，PyTorch 团队需要适配周期。截至 2026 年 7 月，PyTorch 最高支持 Python 3.12。
2.3 第 3 层：工具库 — 各 Python 包的功能定位
PyTorch 仅提供"张量运算"这一基础能力，不具备"加载模型并完成推理全流程"的高层功能：
# 仅使用 PyTorch 时，需手动实现以下全部步骤：
# - 从二进制文件解析模型权重
# - 按模型结构逐层构建网络（通常需要数百行代码定义 UNet）
# - 实现去噪循环（Scheduler 的完整数学公式）
# - 处理 Tokenizer 与 Text Encoder 的调用逻辑
# - VAE 编解码的前后处理
# 工作量约 500+ 行代码，且更换模型后大部分代码需重写
# 使用 diffusers 之后的等价代码：
from diffusers import StableDiffusionPipeline
pipe = StableDiffusionPipeline.from_pretrained("model-name")
image = pipe("a cat").images[0]
# 3 行代码。diffusers 封装了上述所有步骤。
| 库名 | 功能定位 | 若不使用的后果 |
|---|---|---|
| torch | GPU 加速的张量计算（GPU 上的 numpy） | 无法运行任何 AI 模型 |
| diffusers | 扩散模型的管线工厂，一行加载、一行推理 | 需手写数百行管线编排代码 |
| transformers | 文本编码器的管线工厂（diffusers 内部依赖其处理 Prompt） | diffusers 会自动安装 |
| opencv-contrib-python-headless | 经典图像处理操作 + DNN 模型推理 + 超分辨率模块 | 图片读写、缩放、超分均需另寻替代方案 |
| accelerate | 自动处理模型在 GPU/多 GPU/混合精度上的分配 | 需手动编写 .to("cuda") 及显存管理逻辑 |
| Pillow (PIL) | Python 最基础的图片读写库 | 无法打开/保存 jpg、png 等常见格式（同时也是 OpenCV 中文路径问题的兼容方案） |
| huggingface_hub | 从 HuggingFace 自动下载模型权重文件 | 需手动从网页下载并指定本地路径 |
| onnxruntime | 使模型脱离 PyTorch 环境独立运行（用于部署场景） | 部署包体积大、冷启动慢 |
| ultralytics | YOLO 目标检测（“识别图中所有人物位置”） | 无法执行目标检测任务 |
| xformers | 优化注意力机制的计算效率与显存占用（可节省约 30% 显存） | 同等条件下显存更紧张、推理更慢 |
| bitsandbytes | 8-bit/4-bit 量化推理（“将 23GB 模型压缩至 6GB”） | 大模型在消费级显卡上无法运行 |
2.4 第 4 层：模型权重 — .safetensors 文件的本质
# FLUX.1-dev 模型权重文件的目录结构
~/.cache/huggingface/hub/models--black-forest-labs--FLUX.1-dev/
├── model_index.json # 记录该模型由哪些子模型组件构成
├── transformer/ # 主去噪网络（UNet/DiT）的权重 → 约 23GB
│ └── diffusion_pytorch_model.safetensors
├── vae/ # VAE 编解码器的权重 → 约 300MB
│ └── diffusion_pytorch_model.safetensors
├── text_encoder/ # 文本编码器的权重 → 约 3GB
│ └── model.safetensors
└── scheduler/ # 去噪策略的配置（不包含权重，仅数学公式参数）
└── scheduler_config.json
模型权重文件不包含原始训练数据：
常见误解：下载 FLUX 模型（约 12GB）= 下载了模型训练时见过的所有图片的压缩版本
实际情况：原始训练数据（数十亿张图片，PB 级存储规模）
→ 经过训练过程（GPU 集群运行数周至数月）
→ 产出一个 .safetensors 权重文件（约 12GB 的浮点参数矩阵）
类比：一个人看过几千张猫的照片后，大脑中并未存储这几千张照片的副本，
但形成了"猫的外貌特征"这一抽象认知。
模型权重 = 训练得到的"识别与生成规律"，而非训练数据的压缩存储。
远程 API 服务与本地部署使用的是同一份模型权重。 区别仅在于由谁的硬件执行推理——API 服务商的 A100 数据中心 GPU，还是个人的 RTX 4060 消费级显卡。在硬件性能相当的前提下，推理结果的质量没有差异。
2.5 第 5 层：用户界面 — 两种交互范式
| 范式 | 适用场景 | 代表工具 |
|---|---|---|
| 编程接口 | 开发者、需要自动化或批量处理的场景 | diffusers Python API |
| 可视化编排 | 设计师、不编写代码、需要直观调节参数 | ComfyUI |
ComfyUI 的底层同样调用 diffusers 库。用户在 ComfyUI 中通过拖拽节点构建的工作流，本质上等价于一段 diffusers Python 脚本。掌握 diffusers 编程接口后，ComfyUI 只是换了一种交互方式，核心概念完全相通。
2.6 环境安装验证清单
以下 4 条验证命令全部通过，即说明环境已就绪：
# ① GPU 是否可用
python -c "import torch; print(torch.cuda.is_available())" # → True
# ② CUDA 版本与 PyTorch 版本是否匹配（示例为 CUDA 12.1）
python -c "import torch; print(torch.version.cuda)" # → 12.1
python -c "import torch; print(torch.__version__)" # → 2.x.x+cu121
# ③ diffusers 能否正常加载模型管线
python -c "from diffusers import DiffusionPipeline; print('OK')" # → OK
# ④ OpenCV 扩展模块（dnn_superres）是否完整安装
python -c "import cv2; cv2.dnn_superres.DnnSuperResImpl_create()" # → 对象创建成功
三、第一张 AI 图片：从代码到理解
环境就绪后，本章从一段最小可运行代码开始——先看到结果，再逐层拆解"一行推理调用背后发生了什么"，最终建立对扩散模型推理全流程的结构化认知。
3.1 最小可运行示例
from diffusers import AutoPipelineForText2Image
import torch
# ① 加载管线（首次运行自动下载 FLUX.1-schnell 模型，约 12GB）
pipe = AutoPipelineForText2Image.from_pretrained(
"black-forest-labs/FLUX.1-schnell",
torch_dtype=torch.bfloat16
)
pipe.to("cuda")
# ② 生成图片
image = pipe(
prompt="一只橘猫戴着墨镜坐在沙滩上，日落光线，电影质感"
).images[0]
# ③ 保存结果
image.save("my_first_ai_image.jpg")
以上共 6 行有效代码，运行后在当前目录生成一张 AI 创作的图片。
3.2 一行推理调用背后的六个步骤
pipe(prompt) 这一行看似简洁的调用，内部实际顺序执行了六个步骤：
用户输入：prompt="一只橘猫戴着墨镜坐在沙滩上..."
│
▼
┌─────────────────────────────────────────────────────────┐
│ 步骤①：Text Encoder（文本编码） │
│ │
│ "一只橘猫戴着墨镜..." → CLIP / T5 模型 → 语义向量 │
│ 将自然语言描述转换为模型可理解的数值条件信号 │
│ 输出：4096 维（FLUX）向量，编码了"猫""墨镜""沙滩"等语义 │
├─────────────────────────────────────────────────────────┤
│ 步骤②：随机种子 → 初始噪声 │
│ │
│ torch.randn(...) → 在潜空间中生成纯随机噪声 │
│ 512×512 像素空间经 VAE 压缩后，在潜空间仅 64×64 │
│ 随机种子固定 → 噪声固定 → 生成结果可精确复现 │
├─────────────────────────────────────────────────────────┤
│ 步骤③：Scheduler 初始化 │
│ │
│ 设定去噪总步数，建立从纯噪声到清晰图像的"调度计划" │
│ FLUX-schnell（蒸馏版）：仅需 1-4 步 │
│ SD 3.5（标准版）：需要 20-50 步 │
├─────────────────────────────────────────────────────────┤
│ 步骤④：去噪循环（推理核心）——重复 N 次 │
│ │
│ 循环每一步：当前噪声图 + 文本条件向量 + 当前步数编号 │
│ → UNet/DiT 预测"哪些像素更可能是噪声" │
│ → Scheduler 按预定公式减去预测的噪声分量 │
│ → 噪声略微减少，图像略微清晰，进入下一步 │
│ │
│ 第 1 步：完全随机噪点，无任何可辨识内容 │
│ 第 5 步：隐约出现色块轮廓（沙滩、天空区域） │
│ 第 10 步：可辨识出猫的色块与墨镜的大致形状 │
│ 第 20 步：细节全部完成——毛发纹理、镜片反光、日落光感 │
├─────────────────────────────────────────────────────────┤
│ 步骤⑤：VAE Decoder（潜空间 → 像素空间） │
│ │
│ 潜空间中 64×64×16 的张量 → VAE 解码 → 512×512×3 像素图 │
│ 类比：解压压缩文件——潜空间是压缩态，像素空间是展开态 │
├─────────────────────────────────────────────────────────┤
│ 步骤⑥：后处理 │
│ │
│ 值域裁剪（[-1,1] → [0,255]）→ 转换为 PIL Image 对象 │
│ → 返回给调用方 │
└─────────────────────────────────────────────────────────┘
3.3 四个核心组件的职责
| 组件 | 在管线中的职责 | 类比 |
|---|---|---|
| Text Encoder | 将 Prompt 自然语言编码为语义条件向量——告知模型"用户期望的内容" | 需求翻译 |
| UNet / DiT | 去噪循环的核心计算模块——从含噪图像中预测噪声分量 | 雕刻：每次削去多余的石料 |
| Scheduler | 控制去噪的节奏——每一步移除多少噪声、采用何种算法策略 | 节拍器：控制每次下刀的深度与频率 |
| VAE | 像素空间与潜空间的双向转换——压缩与还原 | 打包与拆包：运输时压缩，使用前恢复 |
3.3.1 UNet 与 DiT：两代去噪架构
§3.3 的组件表中将去噪网络写为"UNet / DiT"，两者是代际关系——当前旗舰模型（FLUX、SD 3.5）已全面转向 DiT。
UNet（2015-2023，以 Stable Diffusion 1.x/2.x/XL 为代表）：
UNet 结构（概念示意）：
输入（含噪潜空间 64×64×4）
↓
┌──────────────────────┐
│ 卷积下采样（Encoder） │ ← 逐步压缩空间分辨率，提取特征
│ 64→32→16→8 │ 基于 CNN 卷积层
│ ↓ 跳跃连接 │ 跳跃连接 = 将 Encoder 的中间结果
│ 8→16→32→64 │ 直接传给 Decoder 同分辨率层
│ 卷积上采样（Decoder） │ ← 逐步恢复空间分辨率
└──────────────────────┘
↓
输出（噪声预测 64×64×4）
文本条件注入方式：Cross-Attention（在特定层将文本向量与图像特征做交叉注意力）
DiT（Diffusion Transformer，2024-至今，以 FLUX/SD 3.5/SORA 为代表）：
DiT 结构（概念示意）：
输入（含噪潜空间 latent）
↓
┌──────────────────────────────┐
│ Patch Embedding │ ← 将图像切成小块（类似 ViT），每块映射为 token
│ （例如 2×2 像素 → 1 个 token）│
├──────────────────────────────┤
│ Transformer Block × N 层 │ ← 无需卷积，纯 Transformer
│ ┌────────────────────────┐ │
│ │ Adaptive Layer Norm │ │ ← 时间步条件注入：每个去噪步的"进度条"信号
│ │ ↓ │ │
│ │ Multi-Head Self-Attention│ │ ← 图像各 patch 之间互相注意
│ │ ↓ │ │
│ │ MLP（Feed-Forward） │ │
│ └────────────────────────┘ │
│ 文本条件注入方式： │
│ AdaLN（自适应归一化）或 │ ← 文本向量直接调制 Transformer 的归一化参数
│ Joint Attention（联合注意力）│ ← 文本 token 和图像 token 一起做注意力
└──────────────────────────────┘
↓
输出（噪声预测）
为什么 DiT 取代了 UNet：
| 维度 | UNet（CNN 卷积） | DiT（Transformer） |
|---|---|---|
| 扩展性 | 加深加宽收益递减 | 随参数量增大持续提升（Scaling Law） |
| 高分辨率 | 卷积感受野有限，需多层下采样 | Self-Attention 天然全局视野 |
| 文本对齐 | Cross-Attention 仅作用于特定层 | AdaLN 逐层注入，条件信号贯穿始终 |
| 训练效率 | CNN 在小规模上收敛快 | Transformer 在大规模数据上收敛更好 |
| 代表模型 | SD 1.5 / SDXL | FLUX.1 / SD 3.5 / SORA / Wan 2.7 |
与文本 LLM 的殊途同归：DiT 的思路是将图片生成问题重新表述为"序列到序列"的 Transformer 任务——图像被切分成 token 序列，去噪过程就是对 token 序列的逐步变换。这与文本 LLM 的"Token → Token 自回归"在数学形式上趋于统一。理解这一点后，你会发现图片模型和文本 LLM 的差异在缩小——它们共享同一个架构范式（Transformer），区别在于输入输出的模态和生成策略（逐步去噪 vs 自回归）。
3.4 参数含义与调节方向
image = pipe(
prompt="...", # 正向提示词：描述期望内容
negative_prompt="blurry, low quality", # 负向提示词：描述不希望出现的内容
num_inference_steps=4, # 去噪步数：schnell 版用 1-4，标准版用 20-50
guidance_scale=3.5, # 引导强度：越高越贴合 Prompt，但可能过饱和
height=1024, width=1024, # 输出尺寸（必须是 64 的整数倍）
generator=torch.Generator("cuda").manual_seed(42), # 固定随机种子以复现结果
).images[0]
| 参数 | 增大 | 减小 | 推荐值 |
|---|---|---|---|
num_inference_steps |
质量↑、速度↓ | 速度↑、质量↓ | schnell: 4 / 标准: 20-30 |
guidance_scale |
更紧密贴合 Prompt | 给模型更大自由度 | FLUX: 3.5 / SD: 7.5 |
height × width |
细节丰富度提升 | 推理速度加快 | 调试: 512² / 成品: 1024² |
关于
guidance_scale的机制：该参数背后是 Classifier-Free Guidance（CFG，无分类器引导） 算法。每一步去噪时，模型实际上执行两次预测——一次带上 Prompt 条件（“一只猫”），一次不带条件（空文本），然后按公式合成最终预测：最终噪声预测 = 无条件预测 + guidance_scale × (有条件预测 − 无条件预测)直观理解：
有条件预测 − 无条件预测是"Prompt 给模型额外注入了多少信息"。guidance_scale控制这个额外信息的放大倍数——越大越贴合 Prompt，但也可能放大伪影和过饱和。FLUX 推荐 3.5、SD 推荐 7.5 是经验值，与各自的训练策略和 Text Encoder 强度有关。
3.5 远程调用：三家国内服务商
除本地部署外，文生图同样可以通过远程 API 调用实现，调用方式与文本 LLM 的 API 一致，仅端点和模型名不同：
# SiliconFlow（OpenAI 兼容接口，可用模型种类最多）
from openai import OpenAI
client = OpenAI(base_url="https://api.siliconflow.cn/v1", api_key="sk-xxx")
resp = client.images.generate(model="black-forest-labs/FLUX.1-dev",
prompt="一只猫", size="1024x1024")
# 智谱（CogView-4，支持对话式迭代编辑）
from zhipuai import ZhipuAI
client = ZhipuAI(api_key="xxx")
resp = client.images.generations(model="cogview-4", prompt="一只猫")
# 阿里百炼（Qwen-Image，中文字符渲染能力领先，同时提供编辑 API）
import dashscope
from dashscope import ImageSynthesis
resp = ImageSynthesis.call(api_key="sk-xxx", model="qwen-image-max",
prompt="一只猫", n=1, size="1024*1024")
| SiliconFlow | 智谱 | 阿里百炼 | |
|---|---|---|---|
| 主要模型 | FLUX.1, SD 3.5, SANA | CogView-4 | Qwen-Image 2.0, 通义万相 |
| 接口风格 | OpenAI 兼容 | 自有 SDK + OpenAI 兼容 | 自有 SDK + OpenAI 兼容 |
| 差异化优势 | 可用模型种类最多 | 对话式迭代编辑 + 成本最低 | 中文文字渲染 + 图片编辑 API |
四、噪声与遮罩：扩散模型的两个基础概念
在进入图生图、Inpainting 等具体操作之前，需要先理解两个贯穿全部图片编辑任务的基础概念——噪声和遮罩。它们是扩散模型实现"可控生成"的核心机制。
4.1 噪声的本质
噪声是一张与目标图片尺寸相同的纯随机像素矩阵，其中每个像素的值独立随机生成，不携带任何有意义的信息。
真实图片（256×256） 纯噪声（256×256）
┌────────────────────┐ ┌────────────────────┐
│ 🐱 清晰可见的猫 │ │ ░▒▓█▒░▓▒▓█░▓▒▓█ │
│ 具有毛发、眼睛、轮廓 │ │ ▓▒░▓█▓▒░▓█▒░▓█░ │
│ 这是"信号"（有意义） │ │ 这是"噪声"（无意义）│
└────────────────────┘ └────────────────────┘
扩散模型采用噪声作为起点的原因：噪声不包含任何预设信息，因此可以向任意方向演化。从同一份随机噪声出发，配合不同的 Prompt 条件，可以生成内容完全不同的图片——噪声是最公平的初始状态。
4.2 噪声对图片的影响
扩散模型的训练过程即为学习在不同噪声强度下如何恢复原始信号。噪声比例直接决定了图像的可见程度：
原图 加 25% 噪声 加 50% 噪声 加 100% 噪声
┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
│ 🐱 清晰 │ → │ 🐱 轻微模糊 │ → │ 🐱 严重模糊 │ → │ ░▒▓ 纯噪声 │
│ 细节完整 │ │ 细节开始丢失 │ │ 仅剩轮廓 │ │ 完全不可辨认 │
└────────────┘ └────────────┘ └────────────┘ └────────────┘
噪声 0% — 原图，全部细节完好
噪声 30% — 轮廓与颜色仍可辨识，细节已丢失
噪声 50% — 仅能分辨大致的形状与色彩分布
噪声 100% — 完全随机的像素，不含任何原始图像信息
图生图中的 strength 参数即对应"加噪比例"：strength=0 不加噪声，图片不变；strength=1 加 100% 噪声，等价于文生图。
4.3 遮罩的本质
遮罩是一张与原图尺寸相同的黑白二值图像，其每个像素的值仅表达一个含义：该位置是否允许模型修改。
原图 遮罩
┌──────────────────────┐ ┌──────────────────────┐
│ │ │████████ ████████ │
│ 👤围观 🧑主角 👤围观│ │████████ ████████ │
│ │ → │████████ ████████ │
│ 👤围观 👧主角 👤围观│ │████████ ████████ │
│ │ │████████ ████████ │
└──────────────────────┘ └──────────────────────┘
白色 = 允许模型自由修改
黑色 = 保持原始像素不变
4.4 遮罩与噪声在 Inpainting 中的协作机制
Inpainting 的每一步去噪过程，都是遮罩引导下的"局部生成 + 全局锁定"操作：
去噪步骤 i（总步数 20，当前为第 5 步）：
1. UNet 对整张图执行去噪预测（遮罩内外区域均参与计算）
2. 将遮罩外部区域强制覆盖为原图像素——"锁定不变区域"
3. 遮罩内部保留去噪结果——"AI 在此区域内自由生成"
4. 进入下一步迭代
每一步均需执行覆盖操作的原因：
→ UNet 的卷积运算会导致遮罩内外区域的信息相互渗透
→ 必须在每一步去噪后将遮罩外部重置为原图，确保只有遮罩内部发生修改
类比：装修施工中的成品保护
整张图 = 整个房间，遮罩内部 = 施工区域
遮罩 = 覆盖在不动区域上的保护层
每一步施工结束后检查保护层是否完整，确保无污损扩散至非施工区域
噪声决定"修改的程度"，遮罩决定"修改的位置"。 两者的组合构成了所有图片编辑任务的参数空间。
五、图片编辑的四种模式：同一管线，不同参数组合
核心认知：图生图、Inpainting、超分、Outpainting 并非四种独立技术——它们是同一套扩散管线，仅通过改变"起点噪声比例"和"遮罩范围"切换为不同模式。
5.1 四种模式的本质差异
起点噪声比例 遮罩约束 本质操作
─────────── ──────── ────────
文生图 100% 无（整图参与生成） 从零创造
图生图 30%~80% 无（整图参与生成） 基于原图重新演绎
Inpainting 遮罩内 100% 遮罩外锁定为原图 局部重新生成
遮罩外 0%
超分 10%~20% 无（整图微调） 细节增强
5.2 图生图 — 以 strength 控制修改幅度
from diffusers import AutoPipelineForImage2Image
import torch
from PIL import Image
pipe = AutoPipelineForImage2Image.from_pretrained(
"black-forest-labs/FLUX.1-schnell",
torch_dtype=torch.bfloat16
).to("cuda")
original = Image.open("my_photo.jpg")
result = pipe(
prompt="水彩画风格，柔和的色彩",
image=original,
strength=0.5, # 核心参数：0=保持原图不变，1=完全重新生成
num_inference_steps=4,
).images[0]
strength 参数效果对照：
strength = 0.1 几乎无可见变化，仅轻微调整色调与纹理
strength = 0.3 保留原图构图与结构，风格开始转变
strength = 0.5 可辨认原图内容，但风格发生显著变化（如照片 → 水彩画）
strength = 0.8 仅保留大致空间布局，内容变化幅度大
strength = 1.0 等价于文生图，与原始图像再无关联
5.3 Inpainting — 以遮罩控制修改位置
from diffusers import AutoPipelineForInpainting
pipe = AutoPipelineForInpainting.from_pretrained(
"black-forest-labs/FLUX.1-schnell",
torch_dtype=torch.bfloat16
).to("cuda")
original = Image.open("my_photo.jpg")
mask = Image.open("mask.png") # 白色=允许修改，黑色=保持原样
result = pipe(
prompt="干净的街道背景，自然的建筑外墙",
image=original,
mask_image=mask,
num_inference_steps=4,
).images[0]
遮罩占比与成功率的关系：
遮罩占比 <10% 10~30% >30%
成功率 高 中等 低
原因分析 模型有充足的周边 模型勉强可推断 模型"虚构"的概率显著上升
上下文作为参考 周边上下文 （实际使用中已验证的局限）
两种技术路线的适用场景：
- 移除路人、保持原始场景真实感 → 内容感知填充（Photoshop / OpenCV inpaint），利用原图纹理
- 将门改为窗、需要创造全新内容 → 扩散模型 Inpainting，由模型生成新内容
5.4 超分辨率 — CNN 方法与扩散方法的对比
方案 A：CNN 超分（不编造内容，推荐用于保真场景）
import cv2
from PIL import Image
import numpy as np
sr = cv2.dnn_superres.DnnSuperResImpl_create()
sr.readModel("LapSRN_x4.pb")
sr.setModel("lapsrn", 4)
pil_img = Image.open("small.jpg")
cv_img = cv2.cvtColor(np.array(pil_img), cv2.COLOR_RGB2BGR)
result = sr.upsample(cv_img)
| 模型 | 放大倍数 | 文件大小 | 速度 | 质量 | 适用场景 |
|---|---|---|---|---|---|
| LapSRN | ×2,×4,×8 | 1.3MB | 快 | 良好 | 通用推荐 |
| EDSR | ×2,×3,×4 | 37MB | 慢 | 最优 | 追求极致质量 |
| ESPCN | ×2,×3,×4 | 100KB | 最快 | 中等 | 实时应用 |
| FSRCNN | ×2,×3,×4 | 40KB | 快 | 中等 | 移动端部署 |
方案 B：扩散超分（视觉效果更好，但可能引入虚构细节）
result = pipe_img2img(
prompt="high resolution, sharp details, 4K quality",
image=original,
strength=0.15, # 极低值，仅在纹理层面增强，不改变内容
).images[0]
选择依据：要求"严格保真"（证件照、文档扫描件）→ CNN 超分；追求"视觉观感"（风景照、艺术作品）→ 扩散超分。
5.5 Outpainting — 扩展画面边界
Outpainting 的核心逻辑是 Inpainting 的变体：将原图放置于更大画布的中央，四周空白区域作为遮罩，由模型在遮罩区域生成与原图风格一致的延续内容。
canvas = Image.new("RGB", (w * 2, h)) # 创建扩展画布（宽度加倍）
canvas.paste(original, (w // 2, 0)) # 原图居中放置
mask = Image.new("L", canvas.size, 255) # 初始化为全白（全部允许生成）
mask.paste(Image.new("L", original.size, 0), (w // 2, 0)) # 原图位置锁定
result = pipe_inpaint(prompt="继续延伸该场景，保持一致的风格与光照",
image=canvas, mask_image=mask).images[0]
六、精确控制：LoRA、ControlNet 与 IP-Adapter
三者的定位：Prompt 是"建议"（语义层面），LoRA 是"训练"（身份/风格层面），ControlNet 是"命令"（空间/结构层面），IP-Adapter 是"参考"（图像风格层面）。
6.1 纯 Prompt 控制的局限性
使用 Prompt"一只猫在沙发上"时，模型在每次推理中可能生成不同的猫的品种、观察角度、动作姿态、沙发款式和光线条件——每次结果均不相同。Prompt 本质上是"语义意图"，而非精确的空间或身份指令。
三种控制技术在各自维度上解决了这一问题：
| 技术 | 控制维度 | 功能类比 | 文件大小 |
|---|---|---|---|
| LoRA | 内容 / 角色 / 风格 | “教会模型识别特定人物” | 10-200MB |
| ControlNet | 空间结构 / 构图 | “向模型提供构图骨架” | ~1.4GB |
| IP-Adapter | 图像风格 / 外观参考 | “以参考图的风格进行创作” | ~300MB |
6.2 LoRA — 控制"外观特征"
LoRA 是一种轻量级权重补丁，使基础模型获得其原本不具备的特定概念——特定角色、特定面部特征或特定艺术风格。
无 LoRA：Prompt "一个女孩，动漫风格" → 每次生成的面部特征均不同
加载 LoRA：相同 Prompt + "角色A.safetensors" → 每次生成均保持角色一致
工作原理：
基础 FLUX 模型（约 12GB） LoRA 文件（约 20MB）
┌──────────────────────┐ ┌──────────────────────┐
│ 理解通用视觉概念： │ + │ 仅存储学习到的"偏差"： │
│ "猫""狗""沙发""日落" │ │ "该角色的眼型参数应 │
│ 无法辨识你的特定角色 │ │ 向此方向偏移" │
└──────────────────────┘ └──────────────────────┘
↘ ↙
推理时融合计算 → 基础模型通用能力 + LoRA 特化知识
pipe.load_lora_weights("character_lora.safetensors")
pipe.fuse_lora() # 将 LoRA 权重融入基础模型，加速后续推理
image = pipe("my_character in a garden, cinematic lighting").images[0]
LoRA 权重的获取途径：
- 从 civitai.com 或 huggingface.co 下载社区训练的 LoRA（.safetensors 格式，10-200MB）
- 自行训练：准备 10-30 张同一角色或风格的图片，在 8GB VRAM 的消费级显卡上训练 30 分钟至数小时
适用：固定角色外貌、特定艺术风格、特定物体外观。不适用：精确控制构图中的空间位置。
6.3 ControlNet — 控制"空间位置与姿态"
ControlNet 在标准扩散模型上附加一个可训练的控制分支，接收额外的条件输入（边缘检测图、深度图、骨骼姿态图等），使生成结果精确遵循指定的空间结构。
控制信号类型：
| 控制信号 | 输入格式 | 约束内容 | 典型应用 |
|---|---|---|---|
| Canny 边缘 | 线稿轮廓图 | 物体的边界与轮廓 | 将设计草图转换为照片级渲染 |
| Depth 深度 | 灰度深度图 | 物体的前后关系与体积感 | 保持场景的空间层次 |
| OpenPose 姿态 | 骨骼关节点图 | 人物的动作与姿势 | 指定人物的精确姿态 |
| Scribble 涂鸦 | 手绘色块 | 构图的色彩分区 | 快速原型构图 |
| Segmentation | 语义分割色块 | 各类物体的空间分布 | 精确控制场景布局 |
# 以 Canny 边缘检测为例
from diffusers import StableDiffusion3ControlNetPipeline, ControlNetModel
import cv2, numpy as np
controlnet = ControlNetModel.from_pretrained(
"InstantX/SD3-Controlnet-Canny", torch_dtype=torch.float16
)
pipe = StableDiffusion3ControlNetPipeline.from_pretrained(
"stabilityai/stable-diffusion-3.5-medium",
controlnet=controlnet, torch_dtype=torch.float16
).to("cuda")
# 从参考图提取边缘作为控制图
edges = cv2.Canny(cv2.cvtColor(np.array(original), cv2.COLOR_RGB2BGR), 100, 200)
control_image = Image.fromarray(edges)
result = pipe(
prompt="a cat sitting on the sofa, photorealistic",
control_image=control_image,
controlnet_conditioning_scale=0.8, # 控制强度：0=不约束，1=严格遵循
).images[0]
6.4 IP-Adapter — 以图像替代文字 Prompt
IP-Adapter（Image Prompt Adapter）通过将参考图像的 CLIP 视觉特征注入去噪过程，实现"以图控图"——用图片描述期望的风格与外观，而非仅依赖文字 Prompt。
ControlNet 约束的是"结构"（线条走向、深度层次、关节位置）
IP-Adapter 约束的是"风格与质感"（色调氛围、纹理特征、物体类别）
输入水墨画参考图 → 生成结果的色彩与笔触呈现水墨质感
输入人物照片 → 生成结果具有该人物的面部特征
pipe.load_ip_adapter("h94/IP-Adapter", subfolder="sd3",
weight_name="ip-adapter_sd3.safetensors")
result = pipe(
prompt="a cat sitting on a windowsill",
ip_adapter_image=reference, # 参考图像
ip_adapter_scale=0.6, # 影响力：0=不使用参考图，1=完全遵循
).images[0]
6.5 LoRA 与 ControlNet 的边界辨析
这是最容易混淆的一对概念，区别在于约束的维度不同：
LoRA 回答的问题： "该物体长什么样？"（身份标识 / 外观特征）
ControlNet 回答的问题： "该物体在画面中的哪里、呈现何种姿态？"（空间坐标 / 几何结构）
以角色生成为例：
LoRA → 眼睛为杏仁形，虹膜深褐色，睫毛具有特定卷曲形态（"外观配方"）
ControlNet → 眼部中心位于像素 (256,180)，左右眼间距 64px（"空间坐标"）
同一角色在不同角度下：
正面 / 侧面 / 俯视 → LoRA 保证五官的形态特征一致
→ ControlNet 指定头部朝向与画面位置
决策标准：
问题一：“关注的核心是该物体的外观特征吗？” → 是 → LoRA
问题二：“关注的核心是该物体的空间位置与姿态吗？” → 是 → ControlNet
两者均关注 → 联合使用。
6.6 三者的协同使用
任务：生成特定角色，在樱花树下，以指定姿势站立，并参考某张图片的色调氛围
Prompt: "樱花树下，花瓣飘落" ← 语义场景描述
LoRA: 角色A.safetensors ← 固定角色外貌特征
ControlNet: OpenPose 骨骼关键点图 ← 指定身体姿态
IP-Adapter: 色调参考图 ← 引导色彩与氛围
→ 模型同时接收四种条件信号，综合生成最终图像
七、视频处理与工程落地
7.1 视频生成的本质：在图片扩散模型上增加时间维度
图片生成：噪声 → 去噪循环 × N → 一张静态图像
视频生成：噪声 → 去噪循环 × N → 帧₁
→ 去噪循环 × N → 帧₂（须与帧₁ 保持物体位置与外观一致）
→ 去噪循环 × N → 帧₃（须与帧₂ 保持光影与背景连贯）
...
→ 去噪循环 × N → 帧₁₂₀（10 秒 × 24fps）
核心机制：每一帧的去噪过程均能访问相邻帧的信息——"时序注意力机制"
为实现上述机制，视频模型在图片模型架构的基础上加入了时间维度的建模：
- 3D VAE：将图片 VAE 的 2D 卷积核（空间 H×W）升级为 3D 卷积核（空间 H×W + 时间 T），同时对多帧执行压缩和重建，保证帧间视觉一致性
- 时空注意力（Spatio-Temporal Attention）：在标准 Self-Attention（空间维度上各 patch 相互注意）之后增加一层 Temporal Attention（时间维度上同一空间位置的 patch 跨帧相互注意），使每一帧在去噪时能看到相邻帧的状态
- RoPE 三维位置编码：将文本 LLM 中使用的旋转位置编码（RoPE）扩展到三维（空间 X/Y + 时间 T），帮助模型区分"同一帧内的相邻像素"和"相邻帧的同一位置"
Wan 2.7、CogVideoX 等主流视频模型均采用上述机制，而非简单地将 2D 卷积替换为 3D 卷积。
7.2 主流视频生成模型
| 远程 API（推荐入门） | 本地部署（高显存需求） | |
|---|---|---|
| 顶级质量 | Runway Gen-4.5, Veo 3.1 | Wan 2.7（27B, Apache 2.0） |
| 中文生态 | Kling 3.0（最长 2 分钟）, Jimeng | Wan 2.7, CogVideoX |
| 性价比 | Kling 免费额度, Pika 2.5 | SANA-1.5 视频版（8GB VRAM 可运行） |
| 入门门槛 | 无硬件要求 | 8GB（SANA）→ 24GB+（Wan） |
视频本地部署的硬件门槛远高于图片任务。入门阶段建议先通过远程 API 了解各类模型的效果与能力边界，再决定是否投入高显存硬件。
7.3 视频编辑的工程方法：逐帧处理
对于不具备专用视频编辑模型的场景，可将视频拆分为帧序列，逐帧应用图片处理管线，再合成为视频：
import cv2
from PIL import Image
import numpy as np
# 1. 拆帧
cap = cv2.VideoCapture("input.mp4")
frames = []
while True:
ret, frame = cap.read()
if not ret: break
frames.append(frame)
# 2. 逐帧应用图片处理管线（以风格迁移为例）
processed = []
for frame in frames:
pil_frame = Image.fromarray(cv2.cvtColor(frame, cv2.COLOR_BGR2RGB))
result = pipe_img2img(prompt="油画风格", image=pil_frame, strength=0.4).images[0]
processed.append(cv2.cvtColor(np.array(result), cv2.COLOR_RGB2BGR))
# 3. 合成视频并合并原始音频
# ffmpeg -i output.mp4 -i input.mp4 -c:v copy -c:a aac -map 0:v:0 -map 1:a:0 final.mp4
7.4 FastAPI 封装：将图片处理能力服务化
将前述各章的能力封装为 HTTP API，使任意客户端均可通过网络请求调用：
from fastapi import FastAPI, UploadFile, File, Form
from fastapi.responses import Response
from diffusers import AutoPipelineForText2Image
from PIL import Image
import io, torch
app = FastAPI()
# 服务启动时一次性加载模型，常驻显存
@app.on_event("startup")
async def load_models():
global pipe
pipe = AutoPipelineForText2Image.from_pretrained(
"black-forest-labs/FLUX.1-schnell",
torch_dtype=torch.bfloat16
).to("cuda")
@app.post("/generate")
async def generate(prompt: str = Form(...)):
image = pipe(prompt=prompt).images[0]
buf = io.BytesIO()
image.save(buf, format="JPEG", quality=95)
return Response(content=buf.getvalue(), media_type="image/jpeg")
# 启动：uvicorn image_service:app --port 8000
# 调用：curl -X POST http://localhost:8000/generate -F "prompt=一只猫" -o cat.jpg
服务化前后的对比：
- 每次编写独立脚本 → 统一 HTTP 接口调用
- 模型重复加载（每次 5-30 秒冷启动） → 模型常驻显存，请求即时响应
- 仅限本地使用 → 局域网内任意设备均可调用
7.5 全文回顾
第一章：能力全景 — AI 在图片与视频领域的边界、五层生态结构、远程与本地两种模式
第二章：环境地基 — 自底向上逐层解析，每层的功能定位与安装验证
第三章：第一张图片 — 扩散模型推理全流程的六步骤拆解与四个核心组件
第四章：噪声与遮罩 — 两个贯穿全部图片编辑任务的基础概念
第五章：四种模式 — 同一管线、不同参数组合（图生图/Inpainting/超分/Outpainting）
第六章：精确控制 — LoRA（外观）+ ControlNet（空间）+ IP-Adapter（风格）
第七章：视频与落地 — 视频 = 图片 × 时间维度 + FastAPI 服务化封装
配套阅读：《AI图片视频处理-工具使用手册.md》——各知识点的可执行代码、命令速查、实践经验记录与常见问题解决方案。
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
12
0- 0
已为社区贡献4条内容
所有评论(0)