CNN图像风格迁移毕设实战：VGG16与PyTorch从训练到部署

简介：一套面向毕业设计场景的CNN图像风格迁移完整项目，基于PyTorch实现，提供Python源码、预训练模型与操作说明，适用于计算机、人工智能、自动化等专业学生进行毕设或课程设计参考。包内共93个文件，涵盖9个Python脚本（含Web端app.py、训练脚本train.py及模型工具）、4个预训练模型（pth格式）对应星空、马赛克、素描等风格，另有大量测试图片与示例视频，以及md格式的操作说明，压缩包约57MB。项目内置Flask网页界面，上传图片或视频即可即时应用多种艺术风格，也支持通过命令行自定义数据集与风格图片重新训练。代码模块划分清晰，包含模型定义、数据加载、风格迁移逻辑与Web交互部分，并附带详尽的环境配置指南，便于快速搭建运行环境。目前已有1143人学习下载，适合需要完整毕设参考、或希望在已有项目基础上修改扩展的开发者。

1. 图像风格迁移毕设源码包：能直接复现的 CNN 落地项目

如果毕设题目是“基于 CNN 的图像风格迁移”，而你手里只有一份 python 源码包，最怕的是拆开发现缺模型、缺依赖、跑不起来。这份资源把 VGG16 特征提取、内容与风格损失、生成器推理和 Flask Web 界面打包在一起，checkpoints 下已经放了 cuphead、sketch、starry_night、mosaic 四个训练好的模型，单张图片和视频都能直接出结果，训练命令也留了完整参数。适合两类人：一类是做毕设或课程设计的学生，需要快速复现并写进论文；另一类是刚入门 CNN 的开发者，想看清一条完整的风格迁移工程链路。下面按我拆包时的顺序讲。

2. 拆包以后先看什么：VGG16 特征提取与生成器推理的选型逻辑

2.1 风格迁移为什么离不开 CNN：内容损失与风格损失

图像风格迁移的本质是“保留内容结构，替换纹理风格”。早期做法是逐像素优化，把一张噪声图反复迭代成目标风格；后来大家发现 CNN 的特征图天生就是分层描述的——浅层保留边缘和纹理，深层保留语义内容。于是常见的方案变成：选一个预训练好的 VGG16 当特征提取器，把内容图和生成图都送进去，在指定层取出特征图做对比。

内容损失计算的是内容图与生成图在深层特征图上的欧氏距离，一般取 relu3_3 或者 relu4_2 这一层；风格损失则是把浅层特征图两两组合成 Gram 矩阵，再对比两个 Gram 矩阵的差异。Gram 矩阵的本质是特征图的二阶统计量，它丢失了空间位置信息，只保留了“哪些纹理模式会同时出现”，这正好对应人对“风格”的直觉。最终损失是 content_loss 乘内容权重，加上 style_loss 乘风格权重，训练生成器就是让这个总损失不断下降。

这里有个选型问题：为什么是 VGG16 而不是更深的 ResNet？常见做法是直接用 ImageNet 预训练的 VGG16，把分类头去掉，只用卷积部分。VGG16 虽老，但它的中间层特征对纹理和结构非常规整，神经风格迁移这套方法出来以后，业界验证了一圈，VGG16 的特征做风格损失最顺手，ResNet 的残差结构反而让纹理响应不够“干净”。

2.2 项目里存在两条链路：逐图优化与生成器推理

从文件结构能看出，这个项目保留了两种思路的痕迹。neural_style.py 是逐图优化式，CaffeLoader.py 是为了兼容旧权重格式写的，这类脚本每张图要迭代几百上千步，几分钟才能出一张图，视频基本跑不动。真正被 Web 端和视频测试用到的是 train.py + models.py + checkpoints 这条生成式链路：先训练一个生成器，推理时输入内容图，一次前向就输出风格化结果。

checkpoints 下的 pth 就是训练好的生成器权重。cuphead_10000.pth 训练了 10000 步，sketch_2000.pth 只训了 2000 步，starry_night_28000_vgg16.pth 用 VGG16 做损失网络训到了 28000 步，mosaic_10000.pth 又是 10000 步。注意命名里带 vgg16 的那个，说明它在计算损失时用的是 VGG16 的层输出，其余几个可能用的是相对浅或自定义的特征，加载时别混用。

为什么作者要把不同步数的版本都留一份？因为风格强度不是步数越多越好。2000 步的素描可能只是轻微线条感，28000 步的星月夜已经波纹化得非常夸张，内容几乎被纹理盖住。同样一个风格，不同步数出来的效果差异极大，多存几份方便你选。这个点后面训练自己的模型时还会用到。

2.3 文件结构：哪些文件值得读，哪些可以放着不管

对做毕设的人来说，真正要读的是 train.py 和 utils.py，app.py 只要知道它怎么加载模型就够了。templates/index.html 是前端页面，static 目录放输出结果和样式，images 里是作者留下的测试图和风格图。拿 church.png、zurich.jpeg 这些图先验一遍效果，能确认模型本身是好的，后面排查问题才有基准。

我的阅读顺序是：先看 utils.py 的 load_image 和 save_image，搞清楚图像进模型之前的归一化、尺寸变化；再看 models.py 的生成器前向，确认输入输出通道；最后才打开 train.py 和 test_on_image.py。因为风格迁移的大部分坑，最终都指向数据预处理那一层，这一点在第 5 章会反复碰到。

3. 从环境到出图：让 Web 端和命令行都跑起来

3.1 安装依赖：按 Anaconda 路线走省一半的事

作者在说明里推荐 PyCharm Community Edition 2022.3.3 加 Anaconda。我的习惯是用 conda 建独立环境，避免把 Python 全局环境搞乱：

conda create -n style python=3.9 -y conda activate style pip install torch torchvision opencv-python numpy av pillow tqdm conda install -c conda-forge ffmpeg

说明几点。torch 和 torchvision 版本建议配套，CPU 机器就装 CPU 版，有 N 卡再装 CUDA 版；av 库是视频读取用的，ffmpeg 是底层编解码，这两样不装，后面的视频处理会直接挂。装完以后快速验证：

python -c "import torch, cv2, av; print(torch.__version__, cv2.__version__)"

三行 import 不报错，依赖就算过了。项目说明里提到的 skvideo，在新版 Python 下偶尔装不上，不影响核心功能，建议先忽略，等真需要再处理。

有一个依赖层面的老坑：pth 可能是老版本 torch.save 出来的，在新版 PyTorch 下加载有时会报反序列化错误。遇到这类报错，直接修改加载处，统一走 CPU 加载：

torch.load(pth, map_location=torch.device('cpu'))

这个参数在 CPU 机器上几乎是必加的，否则代码里默认 map_location 指向 cuda，没 N 卡的机器会直接报 RuntimeError。

3.2 启动 Web 端：app.py 与 5000 端口

依赖装好后，在项目根目录打开 Anaconda Prompt 或终端：

python app.py

正常会看到 Flask 启动日志，监听地址是 http://127.0.0.1:5000。浏览器打开这个地址，首页有两个板块：图片风格迁移和视频风格迁移。操作流程作者写得很清楚——点“选择文件”上传，下拉框选风格，点 apply style，等页面刷新看结果。下拉框里的风格名，一般就是程序扫描 checkpoints 目录后按 pth 文件名生成的，所以往 checkpoints 里多放几个训练好的 pth，下拉框就会多出选项。

上传文件名是个隐藏坑。我建议统一用英文文件名，中文名在某些 Windows 环境下的 Flask 静态路由里会变成乱码，页面能刷出结果但文件名读不出来。另外，如果是在 5000 端口上同时开了两个 app.py，后一个会直接报端口占用，先看终端日志再怀疑代码。

3.3 命令行单图推理：test_on_image.py 的常见用法

Web 端适合演示，批量测图时命令行更快。test_on_image.py 的入口参数在文件头部的 argparse 里，常见做法是这么传：

python test_on_image.py --model checkpoints/mosaic_10000.pth --input images/content/church.png --output static/church_mosaic.jpg

--model 指定风格模型，--input 指定内容图，--output 指定输出路径。实际运行前先看一眼文件开头的 add_argument，不同版本的脚本参数名会有差异。跑完后输出图会存到 static 目录，直接当图片打开即可。

这个命令适合两件事：验证新拿到的模型、批量出毕设对比图。我一般会写一个循环，把 images 目录下的内容图全部过一遍，得到一组四种风格的对照素材：

for img in images/content/*.jpg; do python test_on_image.py --model checkpoints/mosaic_10000.pth --input "$img" --output "static/batch_$(basename "$img")" done

循环里每次重新加载模型会慢一点，但胜在不用改代码；如果内容图比较多，更高效的做法是在 test_on_image.py 里把模型加载移出循环，一次加载跑完所有图。

3.4 视频风格迁移：逐帧处理与 av 库的配合

视频版走的是 av 库逐帧读取——每一帧过一遍生成器，再写回 mp4。命令和单图类似，输入换成视频路径即可：

python test_on_video.py --model checkpoints/cuphead_10000.pth --input images/content/111.mp4 --output static/output.mp4

两个点必须提醒。一是视频编码最好已经是 H.264 的 mp4，否则 av 库经常报 Unknown format；二是逐帧推理在 CPU 上很慢，一段 10 秒 1080p 视频可能要几分钟到十几分钟，毕设演示建议先压缩分辨率再跑。声音轨道不参与风格迁移，处理完的视频一般没有声音，答辩前记得说明这一点，或者用 ffmpeg 把原视频音轨拼回去。

4. 训练自己的风格模型：train.py 参数怎么调才不翻车

4.1 训练命令逐项拆解

作者在说明里给的训练命令是：

python train.py --dataset_path data/coco/images/ --style_image images/styles/adriaen-van-ostade_landscape.jpg --epochs 1 --batch_size 4 --image_size 256

每个参数都有讲究。--dataset_path 是内容图数据集目录，训练时随机抽图片喂给生成器，内容和风格不需要预先配对；--style_image 是风格参考图，也就是你想要的纹理来源；--epochs 1 表示训练一个 epoch，注意这里的 epoch 不是跑完整数据集才算一次，具体迭代步数由数据集大小和 batch_size 共同决定；--batch_size 4 是同时处理 4 张图，影响显存占用和梯度稳定性；--image_size 256 是训练时输入尺寸，越小越快，但纹理细节会丢。

第一次跑建议完全照抄这条命令，先把链路打通。train.py 在 CPU 上也能跑，但速度慢得怀疑人生，一个 epoch 可能几十分钟起步。我的建议是：先用 CPU 加上一个只有几十张小图的数据集跑通，确认能正常保存 checkpoint，再换 GPU 上大配置。

4.2 数据集准备：别一上来就下全套 COCO

很多第一次跑的人直接去找 COCO 完整数据集，几十 GB 下到一半心态就崩了。实际跑通只需要几百张图，train.py 是随机取图，图片多样性比数量更影响风格效果。常见做法是准备一个文件夹，放 200-500 张自然风景或人像照片，jpg/png 都行，把 --dataset_path 指过去即可。作者默认写的 data/coco/images/ 只是一个占位路径，你不需要真的按 COCO 的 train/val 结构组织目录。

风格图的选择更考究。纹理明显的风格图（比如马赛克）几千步就能出效果；线条复杂的素描，可能训到一万步风格还是不够。建议先拿作者验证过的 adriaen-van-ostade_landscape.jpg 复跑一遍，确认链路通，再换自己的风格图。这里的玄学就是：同样一组超参，换一张风格图效果可能差距巨大，跟风格图本身的纹理复杂度强相关，不是参数写对就一定能复现别人的效果。

内容图和风格图尺寸差异大时，也会影响训练。我一般会先把大图统一缩到 512 以内，省得 transform 里做等比缩放时把某些极端宽高比拉变形。项目里的 make_style_new_dataset.py 就是干这个的——按风格图把内容图做增强，生成一批带风格的训练对；等基础训练跑通后，可以拿它试试扩数据集。

4.3 训练过程看什么：loss 下降与 checkpoint 输出

训练日志主要看总 loss 的变化。如果 loss 一路横盘甚至上涨，先调低学习率；如果 loss 降得很快但生成图噪点多，说明内容损失权重过低，风格已经压过内容。fast-neural-style 这条路的常见默认值大约是 content_weight 在 1.0 左右、style_weight 在 10 左右、tv_weight 在 1e-4 附近，改的时候不要一次动一个数量级。

生成器训练时一般会定期存 checkpoint。看 checkpoints 的命名就知道作者习惯按步数存，比如 10000 步存一次。train.py 里通常有对应的保存参数，常见的是：

# train.py 中的示意：每 N 步保存一次 if step % 1000 == 0: torch.save(generator.state_dict(), f'checkpoints/{style_name}_{step}.pth')

这个逻辑不一定存在于当前版本里，如果你的 train.py 没有，就自己加上这段，非常值得。因为训练过程中间产物的风格强度往往比最终结果更合适，比如 5000 步的某个风格可能刚好符合答辩要求，28000 步反而过度风格化。

4.4 训练完怎么用：从 pth 到 Web 端下拉框

训练完成后，把 pth 放进 checkpoints 目录，Web 端下拉框就会按文件名出现对应选项。想保留中间步数版本，直接按原文件名存放即可；想要一个“更淡”的风格，可以刻意存一个低步数版本。我发现很多人训练完只留最后一个 pth，这是浪费——对同一个风格名保留 2000 步、8000 步、20000 步三个版本，做对比实验时有很大用处。

提示：train.py 参数不要一次改多个，先复现作者的默认命令，再逐个变量调整。

新手最容易犯的错是一下子同时改好几个参数：换了风格图、调了 batch_size、改了 image_size，结果训练发散，根本说不清是哪一步造成的。正确做法是每次只动一个变量，其余保持默认，用 notebook 或注释把每次实验的参数记下来。

5. 避坑指南：这个项目最容易翻车的 5 个场景

先说排查顺序。遇到问题别急着怀疑代码，按“环境 -> 路径 -> 显存 -> 数据预处理 -> 模型结构”的顺序走。以下 5 个场景是我拆这个包时实际概率最高的坑。

5.1 模型加载直接报错：路径问题排在第一位

现象：python app.py 启动后日志里提示 checkpoints 下的 pth 找不到，或者模型加载时出现 unexpected keys / KeyError。

原因：主要是相对路径问题。app.py 和 train.py 默认以项目根目录为基准，如果你在子目录里启动，或者把 pth 挪到了别的文件夹，路径自然就断了。另一个少见原因是 pth 的 state_dict 和 models.py 定义的生成器结构不匹配，比如从别的仓库拿个模型文件硬塞进来。

解决：先在项目根目录运行；再核对文件名大小写，Linux 下区分大小写；最后确认 pth 的 key。验证 pth 是否损坏，一步到位：

python -c "import torch; sd = torch.load('checkpoints/sketch_2000.pth', map_location='cpu'); print(sd.keys())"

能看到 key 列表就说明文件能读，看不到就要考虑重下。这一步能过滤掉至少三分之一的加载报错。

5.2 显存不够：OOM 不一定怪显卡

现象：训练时直接 CUDA out of memory，或者 CPU 推理时内存占用涨到十几个 G。

原因：image_size 256 + batch_size 4 是给中高端显卡准备的。我自己的经验是 6G 显存的卡跑这个配置很危险，GTX 1650 这种 4G 卡基本必爆；视频推理时解码器还会额外吃一块内存。

解决：先缩图再训练，把 --image_size 降到 192；batch_size 试 1 或 2。训练前先用 nvidia-smi 看一眼当前显存占用，确认没有别的进程占着卡再启动。CPU 机器跑视频时，先把视频压缩到 720p 以下再喂进去。另一个容易被忽略的点：不要同时开 Web 端和训练脚本，两者都占显存，抢起来会一起崩。

5.3 视频读取失败：编码格式比分辨率更磨人

现象：test_on_video.py 跑 mp4 时报 av open failed，或者读出来全是黑帧、花屏。

原因：av 库对编码格式敏感。很多手机录的 mp4 是 HEVC，或者带 B 帧的变体，av 库读不进来；还有一种是文件本身只是改了后缀名的流媒体文件，根本不是标准 mp4。

解决：先用 ffmpeg 看真实编码：

ffmpeg -i input.mp4

看到 Video: h264 才能直接跑；如果是 hevc 或者其他编码，强制转成 H.264 再喂：

ffmpeg -i input.mp4 -c:v libx264 -pix_fmt yuv420p input_h264.mp4

我把这条转换命令写进了批处理脚本，每次跑视频前自动检查编码，这比反复试错高效得多。另外，风格迁移只处理画面，输出视频没有声音；如果答辩需要带音频，用 ffmpeg 把原视频音轨拼回去。

5.4 结果发灰或噪声爆炸：预处理不匹配

现象：生成图整体灰蒙蒙，或者出现明显彩色噪点，但模型文件理论上没坏。

原因：训练和推理时图像归一化不一致。训练时像素范围是 [-1,1]，推理时按 [0,1] 处理，生成器输出的分布就对不上；另外 VGG16 的 RGB 均值没有按训练时的值减掉，风格损失计算就会漂移。这类问题不像路径错误那样直接报错，是静默翻车。

解决：把 utils.py 里的 load_image 从头看一遍，确认 transform 与 train.py 里的预处理分支完全一致。这是这份源码里最难发现的坑，也是最值得自己动手核对的地方，因为改错一个归一化参数，出来的图就是灰蒙蒙一片，肉眼很容易误判成模型不行。

5.5 Web 端打不开：端口与代理的二三事

现象：浏览器访问 http://127.0.0.1:5000 超时或拒绝连接，但终端里 app.py 的日志显示服务在运行。

原因：端口被其他程序占了；访问地址写成了局域网 IP；或者 Flask 绑定到了 IPv6 的 ::1，而浏览器在走 IPv4。

解决：先看终端日志里实际打印的监听地址；换端口可以在 app.py 里改 app.run 的 port 参数；然后用 curl 验证服务是否真的通：

curl http://127.0.0.1:5000

curl 能通、浏览器不通的，基本是浏览器代理或缓存问题，换无痕窗口再试一次。Windows 下首次运行 Flask 会自动弹防火墙授权，如果只在本机演示，直接取消授权保持 127.0.0.1 访问就好；如果要在局域网内展示，再允许访问并改用局域网 IP。

6. 验证结果与进阶：把风格迁移从“能跑”变成“能讲”

6.1 四种风格的结果对照与参数特征

先看效果。同一个内容图用四个预训练模型跑：

这个表不是让你背的，是给你做答辩素材用的：拿同一张 church.png 过四个模型，拼一张四宫格，导师一眼就能看懂“不同风格模型之间的差异”。我演示时最爱用的就是这个问题：同一张内容图，为什么四个模型出四种完全不同的图？答案就落在训练步数和损失网络的差异上，比空谈原理有说服力。

6.2 量化验证：风格迁移成功与否不能只靠肉眼

肉眼判断主观性太强，答辩时容易被追问。更稳妥的是做一个简单的损失验证：加载同一张内容图，分别过四个模型，再用 models.py 里的 VGG16 损失网络算出风格损失和内容损失。思路示意如下：

# 思路示意：对比不同模型在同内容图上的损失 import torch from models import get_vgg, get_generator from utils import load_image content = load_image('images/content/church.png') for pth in ['checkpoints/sketch_2000.pth', 'checkpoints/cuphead_10000.pth']: gen = get_generator() gen.load_state_dict(torch.load(pth)) out = gen(content) l_c, l_s = compute_losses(get_vgg(), content, out) print(pth, 'content_loss:', l_c.item(), 'style_loss:', l_s.item())

这段不直接可跑，compute_losses 需要你按 models.py 的定义补全，但思路很明确：风格损失越低，说明生成图越贴近风格图；内容损失越低，说明原图内容保留越完整。答辩时拿一张数据表出来，比一百句“效果不错”有说服力。

6.3 一个值得养成的习惯

我拿到新模型或新代码，第一件事永远是按原命令跑一遍默认流程，保存基准结果；确认没翻车后，再动一个变量，对比输出差异。最初拿这个项目时，我上来就换了自定义风格图、改了 batch_size，结果训练发散，排查了大半天才发现是数据预处理分支不一致。从那以后，我每次拿到新代码都强制先看 utils.py 的预处理和加载逻辑，再决定改哪里；训练前固定随机种子，让效果可复现。希望这个习惯能帮你在项目里少走一段弯路。

本文还有配套的精品资源，点击获取