简介这套资源是基于VGG网络和Flask框架开发的在线图像风格迁移系统属于计算机视觉方向的完整毕业设计。项目形态为可交互的Web应用用户上传图片后即可应用任意风格迁移并可调节风格化程度、选择是否保留颜色适合毕业设计答辩、课程项目演示也是入门深度学习和风格迁移的实践范本。压缩包共19个文件整体大小约106.65MB其中7个Python脚本覆盖后端Flask服务、网络模型构建、图像采样、训练与测试流程3个PTH模型权重文件如vgg_normalised.pth、decoder.pth提供预训练VGG及解码器参数配合前端HTML、项目书面报告PDF、答辩PPT和README说明可直接运行与展示。目前已有2144人学习是下载热度较高的毕设资料。整套代码从训练到部署链路完整train.py和test.py可复现训练与推理server.py和index.html实现支持并发访问的网页交互结合报告与PPT能快速理解VGG风格迁移原理并为进一步二次开发提供良好基础。1. 图像风格迁移毕设VGG 提特征、Flask 当门面核心一次说清“基于 VGG 网络和 Flask 设计的图像风格迁移系统”听起来像两个独立模块拼在一起一边是深度学习模型一边是 Web 框架。其实它只解决一个问题——把一张照片的内容与一张名画的笔触融合成新图然后让普通用户能在浏览器里上传图片、点一下就看到结果。对毕设来说这是好选题VGG19 只做特征提取器风格迁移核心算法只有几十行Flask 把模型包成 Web 服务前后端链路完整报告有东西可写、演示不依赖命令行。适合选这个方向的人是那些想以“深度学习模型部署成可演示系统”为主线、又不想把大量时间耗在工程基建上的同学。先说一个反直觉的结论风格迁移不是“训练”出来的而是“优化”出来的——整个过程中 VGG 权重一动都不动真正被反复修改的是输入图片本身。2. VGG19 与 Gram 矩阵风格迁移的数学原理与选型理由2.1 为什么风格迁移必须用 VGG而且默认 VGG19风格迁移的祖师爷论文Gatys 等人那篇选择 VGG 不是因为它分类精度最高而是因为 VGG 的卷积层特征对“内容”和“风格”的分离性足够好。它没有残差结构层的语义边界非常清晰浅层 ReLU 输出保存边缘、颜色、局部纹理深层 ReLU 输出保存物体部件和空间布局。这个特性让损失函数可以精确指定“我从第几层取内容、从哪几层取风格”。选 VGG19 而非 VGG16 的理由很实际VGG19 只比 VGG16 多三层卷积预训练权重在 PyTorch / Torchvision 里是现成的答辩时也好解释“我用了官方 ImageNet 预训练权重做迁移学习”。从经验看VGG19 的 relu_4_2 特征做内容约束比 VGG16 更稳风格层的纹理细节也略丰富一点。代价是显存和推理时间增加但对 512×512 的输入两者差距并不大。需要注意torchvision 里的 VGG 是 RGB 输入、ImageNet 的 mean/std 归一化和早期 Caffe 版 VGG 的 BGR 输入规则不一样。写代码时别照抄老博客里的通道反转按 PyTorch 惯例走即可。2.2 内容损失用一张特征图卡住画面结构内容损失的思路非常朴素把内容图和生成图都送进 VGG取某一层输出的特征图然后算两张特征图的欧氏距离MSE。这一层的特征图浓缩了图像的空间结构让生成图在这个“语义空间”里靠近内容图画面构图就不会跑偏。实践中内容层固定取 relu_4_2也就是 VGG19 features 部分的第 21 个模块下标从 0 数。为什么不取浅层浅层特征保留太多像素级细节优化时会要求生成图在颜色和纹理上和内容图几乎一致风格迁移就没有发挥空间。为什么不取深层深层特征过于抽象对空间位置的约束弱画面容易出现结构漂移。relu_4_2 是“结构信息足够、像素细节不过度”的平衡点这层选错后面所有调参都是白费。2.3 风格损失Gram 矩阵到底在算什么风格损失的数学工具是 Gram 矩阵。给定某一层输出的特征图形状是 C×H×W把它拉平成 C×(H·W)再与自己的转置相乘得到 C×C 的矩阵。矩阵中第 i 行第 j 列的值表示第 i 个通道和第 j 个通道在这个层的特征响应相关性。用一个直觉解释如果第 i 个通道认领“橙色笔触”、第 j 个通道认领“粗糙纹理”它们在梵高的画里总是同时出现Gram 矩阵就记录下这组“共现关系”。优化生成图时让生成图的 Gram 矩阵逼近风格图的 Gram 矩阵本质上是在逼近“通道之间的统计相关性”而不是逐像素复制。这也是风格迁移能保留笔触和配色、却不保留风格图构图的原因。风格损失不取单层而是取多层加权求和。我一般取 relu_1_1、relu_2_1、relu_3_1、relu_4_1、relu_5_1 五层靠浅层约束细密纹理靠深层约束大尺度色彩分布。常见实现里这五层权重等权实际调试时可以微调某幅画纹理太碎就降低浅层权重整体颜色不对就加大深层权重。2.4 损失组合与权重为什么风格权重要大到 1e4总损失是内容损失和风格损失的加权和。一个经典的默认配置是内容权重 1.0风格权重 1e4 到 1e6优化器用 LBFGS。风格权重为什么这么大因为 Gram 矩阵的数值尺度远小于特征图的逐点数值尺度如果不拉大权重最终结果会退化成“内容图加一点滤镜感”笔触完全出不来。损失分量取层距离度量控制作用内容损失relu_4_2特征图 MSE保住构图和物体位置风格损失relu_1_1 ~ relu_5_1Gram 矩阵 MSE 求和迁移笔触、配色、纹理组合方式加权相加内容 1.0 风格 1e4~1e6决定“像内容”还是“像风格”一个常见误解是“风格权重越大风格越强”。实际上权重过大时 Gram 匹配的梯度会压制内容损失结果出现纹理密到看不出原图主体权重过小则只是给照片加了一层色调。正确做法是先固定内容权重风格权重从 1e4 开始按数量级试效果不够再乘 10发现问题再退回。这个“按数量级调试”的习惯能省掉大量无用试参时间。3. 用 PyTorch 实现风格迁移完整代码与四个关键参数3.1 最小可运行代码vgg_stylize.py下面这份代码可以直接跑通“一张内容图 一张风格图 → 输出风格化结果”。模型只加载 VGG19 的 features 部分去掉分类头所有预训练权重冻结。核心对象是一个自动收集指定层输出的封装类。import torch import torch.nn as nn import torch.nn.functional as F import torch.optim as optim from torchvision import models, transforms from torchvision.models import VGG19_Weights from PIL import Image device torch.device(cuda if torch.cuda.is_available() else cpu) # 归一化参数要与 ImageNet 预训练一致 mean torch.tensor([0.485, 0.456, 0.406]).view(3, 1, 1).to(device) std torch.tensor([0.229, 0.224, 0.225]).view(3, 1, 1).to(device) class VGG19Features(nn.Module): def __init__(self, style_layers(1, 6, 11, 20, 29), content_layer21): super().__init__() # 新版 torchvision 用 weights 参数老版本用 pretrainedTrue self.features models.vgg19(weightsVGG19_Weights.IMAGENET1K_V1).features.eval() for p in self.features.parameters(): p.requires_grad_(False) self.style_layers style_layers self.content_layer content_layer def forward(self, x): out {} for idx, layer in enumerate(self.features): x layer(x) if idx in self.style_layers: out[fstyle_{idx}] x if idx self.content_layer: out[content] x return out def gram_matrix(y): b, c, h, w y.shape feat y.view(b, c, h * w) gram torch.bmm(feat, feat.transpose(1, 2)) / (c * h * w) return gram def preprocess(pil_img, size512): img pil_img.convert(RGB) w, h img.size scale size / max(w, h) if scale 1: img img.resize((int(w * scale), int(h * scale))) x transforms.ToTensor()(img).unsqueeze(0).to(device) return (x - mean) / std def deprocess(tensor): img tensor.detach().cpu().squeeze(0) img img * std.cpu() mean.cpu() return img.clamp(0, 1) def stylize(content_pil, style_pil, content_weight1.0, style_weight1e5, iterations300, size512): extractor VGG19Features().to(device).eval() content_t preprocess(content_pil, size) style_t preprocess(style_pil, size) with torch.no_grad(): content_feat extractor(content_t)[content] style_grams { k: gram_matrix(v) for k, v in extractor(style_t).items() if k.startswith(style) } target content_t.clone().requires_grad_(True) optimizer optim.LBFGS([target], lr1.0, max_iter20) for step in range(iterations): def closure(): optimizer.zero_grad() gen extractor(target) loss_c F.mse_loss(gen[content], content_feat) loss_s 0.0 for k, gram_style in style_grams.items(): loss_s F.mse_loss(gram_matrix(gen[k]), gram_style) loss content_weight * loss_c style_weight * loss_s loss.backward() return loss optimizer.step(closure) if step % 50 0: print(fstep {step} finished) return deprocess(target)这份代码的关键点有三个。第一VGG19Features通过enumerate遍历 features 模块避免了手写下标出错的概率style_layers 取 relu 输出而不是卷积输出因为 ReLU 之后特征更稀疏、数值分布更稳定。第二Gram 矩阵除以c*h*w做归一化让不同尺寸特征图的损失尺度可比不然大图的 Gram 数值天然偏大损失会抖。第三LBFGS 要求 closure 内部完成zero_grad和backward优化器才能做线搜索这个结构不能按 Adam 的写法来。3.2 四个必须调好的参数第一个是size。毕设演示不必贪大长边 512 是 CPU 能勉强跑、GPU 很轻松的大小长边 768 细节更好但显存占用涨一倍。首次跑通建议直接用 256确认链路没问题再往上加。第二个是content_weight与style_weight的比例。默认 1.0 比 1e5如果结果像“原图加滤镜”把 style_weight 调大到 1e6如果纹理已经盖过主体把 content_weight 提到 5 到 10 而不是死磕 style_weight。这两个参数的调试不要同步调一次只动一个。第三个是iterations。LBFGS 300 步通常够了200 步能出可用结果500 步以上的收益很小。显存允许的情况下max_iter20保持默认这是 LBFGS 内部每次线搜索的最大迭代数。第四个是风格层集合。默认五层等权适合大多数场景。如果风格图是笔触粗犷的油画可以适当降低 relu_1_1、relu_2_1 的权重免得高频噪点过多如果是浮世绘这类线条画反而应该加大浅层权重。这个调节在代码里就是把 style_layers 的权重做成列表逐层乘系数。3.3 想换成 Adam 怎么办LBFGS 是论文原版配置收敛快、结果平滑但 closure 写法和“梯度更新可能越过合理值域”这两个特性对新手不友好。想快速看到效果可以换 Adam代码改动只有几行把优化器换成optim.Adam([target], lr0.02)外层循环改成传统的zero_grad - forward - backward - step并且在每步更新后加一行target.data.clamp_(0, 1)防止数值漂移。Adam 对学习率更敏感lr 太大容易出噪点太小则 300 步不够收敛。我的建议是毕设代码交 LBFGS 版本答辩前自己用 Adam 版本做对比实验两种优化器的损失曲线差异本身就是一个很好的分析章节。4. Flask 封装风格迁移服务上传、推理、回传图像的完整链路4.1 Flask 与 FastAPI、Django 的选择边界风格迁移的推理是一个 CPU/GPU 密集的同步计算过程不是 IO 密集的异步任务。FastAPI 的异步优势在这里几乎用不上Django 自带 Admin、ORM、迁移工具对这个项目又明显过重。Flask 是合适的选择路由简单、模板渲染容易、网上资料多毕设答辩时老师问“为什么选 Flask”可以答“轻量、灵活、与 PyTorch 集成成本低”。部署边界也要心里有数Flask 自带的开发服务器是单进程单线程的只能用于演示不能扛并发。本地跑通后如果要放到服务器上给老师在线看常见做法是 gunicorn 多 worker 启动 Flask再用 nginx 把 80 端口转发到 Flask 的 5000 端口。4.2 把风格迁移封装成 Flask 路由完整 app.py模型加载要放在模块级别不能在请求处理函数里反复加载否则每来一个请求就要等几十秒的权重初始化。另外风格迁移的优化过程会占用大量 CPU/GPU多个用户同时提交请求会导致资源争抢我一般在推理外面加一个全局锁把请求串行化。import io import base64 import threading from PIL import Image from flask import Flask, request, jsonify, render_template_string from vgg_stylize import stylize app Flask(__name__) app.config[MAX_CONTENT_LENGTH] 10 * 1024 * 1024 # 限制上传 10MB _lock threading.Lock() _HTML !doctype html html body stylefont-family:sans-serif;padding:24px h2图像风格迁移系统/h2 input typefile idcontent acceptimage/* input typefile idstyle acceptimage/* button onclickrun()开始迁移/button img idout stylemax-width:420px;margin-top:16px;display:block/ script async function run() { const fd new FormData(); fd.append(content, document.getElementById(content).files[0]); fd.append(style, document.getElementById(style).files[0]); const resp await fetch(/transfer, {method: POST, body: fd}); const result await resp.json(); if (result.code 0) { document.getElementById(out).src result.data; } } /script /body /html app.get(/) def index(): return render_template_string(_HTML) app.post(/transfer) def transfer(): f1 request.files.get(content) f2 request.files.get(style) if f1 is None or f2 is None: return jsonify(code1, msg请同时上传内容图和风格图) content_img Image.open(f1.stream).convert(RGB) style_img Image.open(f2.stream).convert(RGB) with _lock: # 推理串行化防止并发把 CPU 打满 try: out_tensor stylize(content_img, style_img, content_weight1.0, style_weight1e5, iterations200, size512) except RuntimeError as e: return jsonify(code1, msgf推理失败: {str(e)}) out_pil Image.fromarray( (out_tensor.permute(1, 2, 0).numpy() * 255).astype(uint8)) buf io.BytesIO() out_pil.save(buf, JPEG, quality90) b64 base64.b64encode(buf.getvalue()).decode() return jsonify(code0, datadata:image/jpeg;base64, b64) if __name__ __main__: app.run(host0.0.0.0, port5000)这里有几个容易忽略的细节。request.files.get拿到的对象自带stream属性Image.open(f1.stream)直接读内存字节流不要先save到临时文件再打开省掉附件路径管理。输出图不落盘用 base64 data URL 直接回给前端绕过“服务器上找不到图片路径”这类部署麻烦。MAX_CONTENT_LENGTH是对上传体积的硬限制不设的话一张手机原图可能 5MB 到 10MB会被 Pillow 完整读入内存推理时间直接翻倍。4.3 Flask 部署到服务器路径、超时与资源限制如果毕设要求“可本地部署运行”就够了app.run启动后在浏览器打开http://127.0.0.1:5000即可。如果要在服务器上跑给老师看内存和带宽都要提前规划。一个 CPU 推理请求最长可能耗时 30 到 60 秒nginx 默认的读取超时时间不够需要在配置里把上游读取超时调大否则浏览器转圈到一半直接被切断连接。这是毕设部署最常见的翻车点比代码本身更容易让人崩溃。gunicorn 的 worker 数不要盲目开多。每个 worker 都会加载一份 VGG19 模型副本4 个 worker 就是 4 份模型驻留内存小内存服务器会直接 OOM。我的建议是 2 个 worker 加 1 个线程备用配合应用层的锁能应付答辩现场几个人同时点按钮的场景。模型加载完成后进程占用的 RSS 大约在 600MB 到 1GB 之间服务器内存至少留 2GB 才保险。4.4 用 fetch 做异步提交避免页面刷新阻塞前端不要用表单同步提交否则推理的几十秒里浏览器只有一张空白页用户体验很差。上面的代码用fetch异步发送在按钮点击后可以显示“处理中”文案拿到结果再更新图片。如果需要显示进度可以改成两步接口先 POST 提交返回 task_id再由前端轮询 GET 获取状态。这个进阶版本毕设加分明显但注意 Flask 开发服务器默认不支持长任务异步回调轮询是最稳妥的。5. 毕设调试避坑6 个把风格迁移系统搞炸的高频问题5.1 搜资料把 VGG 网络和 VGG Image Annotator 搞混现象搜索“vgg 图像”时跑出来一堆 json 标注工具、多边形标注教程代码风格完全不对路。 原因VGG 团队除了发布 VGG 网络还开发过一款叫 VGG Image Annotator 的在线图像标注工具英文缩写 VIA 不明显中文搜索时极易撞车。 解决搜技术方案时直接用“pytorch vgg19 style transfer”或“gatys style transfer github”这类精确组合不要只搜“vgg 图像迁移”。5.2 torchvision 加载 vgg 报参数名错误现象照老代码写models.vgg19(pretrainedTrue)运行时报TypeError提示pretrained不是有效参数。 原因torchvision 0.13 之后弃用了pretrained参数统一改成weightsVGG19_Weights.IMAGENET1K_V1。 解决按第 3 章的写法用VGG19_Weights枚举导入如果环境里的 torchvision 太老先把weights参数换成pretrainedTrue再跑通不要在两个版本之间反复试。5.3 输出图全黑或全是彩色噪点现象损失在下降但保存出来的图黑糊糊一片或者像打翻的调色盘。 原因归一化和反归一化的 mean/std 对不上。最常见的是 preprocess 里用了 ImageNet 的 mean/stddeprocess 里却只做了简单tensor / 255另一种是 target 更新过程数值越过合理范围LBFGS 行搜索后没有做值域约束。 解决把 deprocess 写成img * std mean然后clamp(0, 1)和 preprocess 严格互逆。显示前一定看一下张量的 min/max如果分布集中在一个很窄的区间先怀疑归一化再怀疑损失权重。5.4 内容图变成色块拼接笔触比风格图还粗现象迁移结果里物体的边缘完全散了像是把内容图分成几块画布重新填色。 原因content_weight太低或style_weight高到离谱relu_4_2 的内容约束被 Gram 匹配梯度淹没了。 解决把 content_weight 提到 5 到 10或者把 style_weight 从 1e5 降到 1e4看到主体轮廓回来后再微调。调参时每改一版保存一张中间图按时间顺序整理成对比表报告里直接能用。5.5 Flask 请求一直转圈CPU 风扇狂转现象点击按钮后浏览器无限等待服务器日志没有报错但 CPU 占用持续 100%。 原因图片没有被限制尺寸。手机原图往往是 4000×3000直接喂进 VGG19前向计算量比 512×512 大几十倍推理时间从几十秒变成几十分钟。 解决在 preprocess 里强制限制长边 512这是风格迁移最关键的工程约束。同时给 Flask 加MAX_CONTENT_LENGTH上传环节就把超大文件挡在门外。还有一个隐藏因素app.run默认单线程锁会串行化请求如果前端 fetch 没有超时提示第二个用户会排在第一个后面等很久页面上要显式提示“队列处理中”。5.6 部署到服务器后找不到图片附件路径现象本地跑得好好的用 nginx gunicorn 启动后报FileNotFoundError日志里路径是相对路径。 原因本地启动目录和 gunicorn 的工作目录不同代码里用了uploads/xxx.jpg这种相对于当前工作目录的路径。 解决所有需要落盘的文件路径都用Path(__file__).resolve().parent拼接绝对路径如果输出图不落盘按第 4 章的 base64 方案根本不存在这个坑。非要在服务器上保留中间产物就把上传图片集中放进一个uploads目录启动脚本里先mkdir -p再让 Flask 用绝对路径读写。6. 效果验证与进阶路线损失曲线、权重滑杆与快速迁移效果验证不要只贴几张“看起来不错”的图答辩时老师会问“你的系统怎么评价好坏”。两个可复现的手段一是记录每一轮的 content_loss 和 style_loss用 matplotlib 画出两条下降曲线证明过程收敛二是固定同一张内容图风格权重分别取 1e4、1e5、1e6 生成三张结果并排对比直观展示权重对风格强度的影响。这两张图放进报告比任何文字描述都有说服力也证明你不是只跑通了代码而是真理解了参数。参数组合content_weightstyle_weight典型效果弱风格1.01e4整体配色偏移笔触不明显标准1.01e5构图清晰纹理适中默认推荐强风格1.01e6笔触强烈深层纹理突出主体细节减少进阶可以做两件事。第一在 Flask 前端加两个 range 滑块把 content_weight 和 style_weight 变成可实时调整的请求参数后端每次按新参数重新优化交互感立刻提升。第二把在线优化换成快速风格迁移路线训练一个小型生成网络U-Net 或 ResNet 结构用“内容损失 风格损失 全变差正则”蒸馏 VGG 的优化结果推理时一次前向就能出图耗时从几十秒降到一秒内这是风格迁移真正走向工程落地的方向。我最早做这个题也翻过车Gram 矩阵把特征图 resized 成二维时通道顺序写错损失曲线一路向下但生成图越来越糊后来打印每一层输出形状才发现是风格层取错了下标。这类 bug 没有捷径多打印形状、多保存中间图是最实在的手段。希望帮到你。本文还有配套的精品资源点击获取