构建自动化图片处理流水线DeOldify与Git版本控制结合实践1. 引言你有没有遇到过这样的场景手头有一批珍贵的老照片都是黑白的想给它们上色让记忆重新鲜活起来。一张张手动处理太费时费力了。用现成的在线工具又担心隐私和批量处理的麻烦。更头疼的是这些照片可能还在不断收集和整理中。今天处理了10张明天又找到了5张怎么管理不同版本的上色结果怎么确保每次处理的过程都能被记录和复现如果对某张照片的上色效果不满意想回退到之前的版本或者尝试不同的上色风格该怎么办这不仅仅是图片处理的问题更是一个项目管理和工作流自动化的问题。今天我就来分享一个我们团队在实际项目中摸索出来的解决方案将专业的图片上色工具DeOldify与强大的版本控制系统Git结合起来打造一套全自动的图片处理流水线。简单来说我们的做法是把原始黑白照片库当作代码一样用Git仓库来管理。每次有新的照片提交或者对已有照片的标注比如想指定上色风格进行修改时一套自动化的工具链就会被触发。它会自动调用DeOldify模型为这些照片上色然后把生成好的彩色照片连同处理日志一起保存到一个新的、专门的分支里。这样做的好处显而易见整个过程完全自动化无需人工干预每一次处理都有完整的记录可以随时查看、对比甚至回滚处理环境和参数是固定的确保了结果的可复现性。无论是个人整理家族相册还是团队处理历史影像资料这套方法都能大幅提升效率和管理水平。下面我就带你一步步拆解这个方案的实现过程。2. 为什么需要结合Git与自动化处理在深入技术细节之前我们先聊聊为什么要把看似不相关的“版本控制”和“图片上色”绑在一起。理解了背后的痛点你才能更好地应用这个方案。2.1 传统图片处理工作流的短板通常我们处理一批图片的流程可能是这样的收集所有黑白照片到一个文件夹。打开DeOldify的Web界面或运行脚本一张张或批量处理。将上色后的图片手动保存到另一个文件夹比如colored。如果对某张效果不满意重新处理然后用新文件覆盖旧文件或者手动重命名photo_v1.jpg,photo_v2.jpg。这个流程存在几个明显问题版本混乱覆盖旧文件历史版本就丢了。手动命名版本很快就会变得难以管理。过程不可追溯这张照片是用哪个版本的DeOldify处理的当时用了什么参数这些信息都没有记录。无法自动化每次新增照片都需要人工重复操作无法与照片收集过程联动。协作困难如果是团队项目很难同步谁处理了哪些照片效果如何。2.2 Git带来的核心优势Git不仅仅是管理代码的工具它本质上是一个内容寻址的文件系统擅长管理任何文本或二进制文件的变更历史。把它用于图片管理可以带来降维打击的优势完整的版本历史每一次提交都是一次快照。你可以随时看到任何一张照片在任意时间点的状态原始黑白版、第一次上色版、第二次调整版并且可以轻松切换。清晰的处理记录每次提交都必须附带说明commit message。比如“为2024-01批次照片上色使用artistic渲染模式”这条记录就和图片变更绑定在一起过程一目了然。分支的魔力我们可以创建独立的分支来存放自动化处理的结果例如colored/auto。这样原始照片库main分支永远保持干净而上色结果在另一个分支上井然有序互不干扰。触发自动化的钩子Git的提交push动作可以完美地作为触发自动化任务的“开关”。2.3 自动化流水线的价值将DeOldify处理步骤自动化并与Git提交绑定意味着提交即处理你只需要关心把原始照片整理好并提交到Git仓库。剩下的上色、保存、归档工作全部由后台流水线完成。结果可预期流水线每次运行的环境和参数是一致的避免了人工操作可能带来的误差确保了处理结果的质量稳定。解放人力从重复劳动中解放出来专注于更有价值的工作比如筛选照片、调整上色效果的艺术方向等。总结来说Git解决了“管理”和“追溯”的问题而自动化流水线解决了“执行”和“效率”的问题。两者的结合为批量图片处理项目提供了一个专业、可靠且高效的工程化解决方案。3. 核心工具与架构设计工欲善其事必先利其器。在开始搭建之前我们先快速认识一下这个方案里的两位“主角”并看看它们是如何协同工作的。3.1 工具简介DeOldify 与 GitDeOldify是一个基于深度学习的老照片上色项目。它训练好的模型能够非常自然、富有艺术感地为黑白照片添加色彩效果在开源项目中备受好评。对我们来说它就是一个功能强大的“处理函数”我们输入黑白图片它输出彩色图片。Git是我们熟悉的分布式版本控制系统。在这个项目里我们把它用作原始素材库存储未经处理的黑白照片。任务触发器向仓库推送代码照片的行为将作为启动自动化流程的信号。成果档案馆存储经过处理后的彩色照片并保留完整的历史版本。3.2 系统架构与工作流程整个系统的运行流程可以用下面这个简单的图示来理解[开发者本地] | | 1. 添加/更新黑白照片 | 2. 提交(commit)并推送(push)到Git远程仓库 v [Git远程仓库 (如 GitHub, GitLab)] | | 3. 推送事件触发Webhook v [CI/CD 服务器 (如 GitHub Actions, GitLab CI)] | | 4. 启动流水线任务 | 5. 拉取最新代码识别新增/变更的图片 | 6. 调用DeOldify API或容器处理图片 | | 7. 将上色后的图片保存到新位置 | 8. 创建新分支或提交到特定分支 | 9. 将结果推送回Git仓库 v [Git远程仓库] |—— main分支: 纯净的黑白照片库 |—— colored/auto分支: 自动生成的彩色照片库流程核心步骤解读本地操作你在本地电脑上把新的老照片放进项目文件夹用git commit记录这次添加然后用git push推到网上的远程仓库比如GitHub。事件触发远程仓库收到你的推送后会根据设置自动通知一个叫CI/CD服务如GitHub Actions的东西“嘿有人推了新代码”自动处理CI/CD服务收到通知立刻启动一个预设好的任务。这个任务会做以下几件大事拉取你刚刚提交的照片。找到所有需要处理的图片比如/source_images目录下的所有.jpg文件。在一个配置好的环境里已经装好了DeOldify批量处理这些图片。把上好色的图片保存到另一个目录比如/colored_output。结果归档任务完成后CI/CD服务会创建一个新的分支例如叫colored/auto或者向这个分支提交代码把处理好的彩色图片和可能生成的日志文件一起再推回到Git远程仓库。至此一个完整的自动化闭环就完成了。你只需要推送原始照片稍等片刻就能在仓库的colored/auto分支上看到自动上色好的结果。4. 实战搭建一步步实现自动化流水线理论讲完了我们动手搭一个。这里我以GitHub GitHub Actions为例因为这对个人开发者和团队都免费且易于上手。如果你用的是GitLab其概念和步骤使用GitLab CI也几乎完全相同。4.1 第一步准备Git仓库与目录结构首先我们在GitHub上创建一个新的仓库名字可以叫old-photo-coloration-pipeline。在本地克隆这个仓库并建立清晰的目录结构old-photo-coloration-pipeline/ ├── .github/ │ └── workflows/ # GitHub Actions 工作流文件存放处 ├── source_images/ # 存放原始黑白照片 │ ├── photo1.jpg │ └── photo2.png ├── colored_output/ # 自动化生成存放上色后的照片 ├── scripts/ # 可选存放自定义处理脚本 │ └── colorize.py └── README.mdsource_images目录是你唯一需要手动管理的地方所有黑白照片都放在这里。colored_output目录初始为空它将会被自动化流水线填充。4.2 第二步编写图片处理核心脚本我们需要一个脚本来调用DeOldify。这里提供一个基于DeOldify Docker镜像的Python脚本示例它简单而实用。创建scripts/colorize.py#!/usr/bin/env python3 自动化图片上色脚本。 使用DeOldify Docker容器处理指定输入目录中的所有图片并输出到指定目录。 import os import sys import subprocess from pathlib import Path def colorize_images(input_dir: Path, output_dir: Path): 使用DeOldify容器处理图片。 Args: input_dir: 包含黑白图片的输入目录路径。 output_dir: 彩色图片的输出目录路径。 # 确保输出目录存在 output_dir.mkdir(parentsTrue, exist_okTrue) # 支持的图片格式 image_extensions (.jpg, .jpeg, .png, .bmp, .tiff) # 查找所有图片文件 image_files [f for f in input_dir.iterdir() if f.suffix.lower() in image_extensions] if not image_files: print(f在目录 {input_dir} 中未找到图片文件。) return print(f找到 {len(image_files)} 张待处理图片。) for img_path in image_files: output_path output_dir / f{img_path.stem}_colored{img_path.suffix} print(f正在处理: {img_path.name} - {output_path.name}) # 构建Docker命令 # 这里使用DeOldify官方提供的测试用镜像生产环境建议构建自己的镜像 docker_cmd [ docker, run, --rm, -v, f{input_dir}:/data/input, # 挂载输入目录 -v, f{output_dir}:/data/output, # 挂载输出目录 deoldify/test_image_colorizer:latest, process, str(img_path.name) ] try: # 执行命令 result subprocess.run(docker_cmd, capture_outputTrue, textTrue, checkTrue) print(f 成功: {img_path.name}) except subprocess.CalledProcessError as e: print(f 失败: {img_path.name}。错误: {e.stderr}) except Exception as e: print(f 处理 {img_path.name} 时发生未知错误: {e}) print(所有图片处理完成) if __name__ __main__: # 设置路径在GitHub Actions中这些路径基于工作区 base_dir Path(os.getenv(GITHUB_WORKSPACE, .)) input_directory base_dir / source_images output_directory base_dir / colored_output if not input_directory.exists(): print(f错误输入目录不存在 {input_directory}) sys.exit(1) colorize_images(input_directory, output_directory)脚本说明这个脚本使用Docker来运行DeOldify避免了在CI环境中复杂的环境配置。它遍历source_images目录下的图片对每张图片调用一次DeOldify容器。处理后的图片会保存到colored_output目录并在文件名后添加_colored后缀以示区分。4.3 第三步配置GitHub Actions自动化工作流这是自动化的“大脑”。我们在.github/workflows/目录下创建一个YAML文件比如colorize-on-push.yml。name: Auto Colorize Old Photos on: push: branches: - main # 仅当推送到main分支时触发 paths: - source_images/** # 仅当source_images目录下的文件有变化时触发 jobs: colorize: runs-on: ubuntu-latest # 使用最新的Ubuntu系统作为运行环境 steps: # 1. 检出代码获取你刚刚推送的照片 - name: Checkout repository uses: actions/checkoutv4 with: fetch-depth: 0 # 获取所有历史这对Git操作有时是必要的 # 2. 设置Docker因为我们的脚本需要Docker环境 - name: Set up Docker uses: docker/setup-buildx-actionv3 # 3. 运行上色脚本 - name: Run DeOldify colorization run: | python3 scripts/colorize.py env: # 确保脚本能找到正确的路径 GITHUB_WORKSPACE: ${{ github.workspace }} # 4. 准备将结果提交到新分支 - name: Configure Git for automated commits run: | git config --global user.name GitHub Actions Bot git config --global user.email actionsgithub.com # 5. 创建或切换到存放结果的分支并提交上色后的图片 - name: Commit and push colored images run: | # 检查是否有新文件生成 if [ -n $(ls -A colored_output/ 2/dev/null) ]; then # 尝试切换到 colored/auto 分支如果不存在则创建 git checkout -b colored/auto 2/dev/null || git checkout colored/auto # 将上色结果移动到仓库根目录或特定位置并强制覆盖旧文件 # 这里我们选择将colored_output整个目录的内容复制过来 cp -r colored_output/* ./ # 添加所有变更包括新图片和可能被覆盖的旧图片 git add -A # 提交变更提交信息包含触发此次运行的提交ID git commit -m Auto-colorized images via CI [Triggered by ${{ github.sha }}] # 推送到远程的 colored/auto 分支 git push origin colored/auto --force else echo 没有生成新的彩色图片跳过提交。 fi工作流解读触发条件(on)只有当main分支的source_images目录下有文件变动时这个工作流才会运行。这避免了不必要的触发。运行步骤(steps)检出代码获取最新的黑白照片。准备Docker环境为运行DeOldify容器做准备。执行上色运行我们刚才写的Python脚本。配置Git设置一个机器人身份用于后续的自动提交。提交结果这是最关键的一步。它尝试切换到colored/auto分支将处理好的图片复制过来然后提交并推送到远程仓库的这个分支。--force参数是为了确保能更新该分支因为每次运行的结果都是全新的。4.4 第四步测试与运行现在整套系统已经就绪。将本地仓库推送到GitHubgit add . git commit -m “初始化仓库添加首批黑白照片和CI配置” git push origin main观察自动化过程打开你的GitHub仓库页面点击顶部的“Actions”标签页。你应该会看到一个名为“Auto Colorize Old Photos”的工作流正在运行黄色图标稍后会变成绿色成功或红色失败。点击进入可以查看详细日志包括Docker拉取镜像、处理每张图片的输出等。查看结果工作流运行成功后刷新仓库页面。在分支下拉菜单中你应该能看到一个新的分支colored/auto。切换到该分支你就会在仓库根目录下看到所有自动上色后的图片例如photo1_colored.jpg。恭喜你的第一个自动化图片处理流水线已经搭建完成。从此以后你只需要往source_images里丢照片、提交、推送剩下的就交给机器了。5. 进阶优化与实践建议基础流水线跑通后我们可以让它变得更强大、更智能。这里分享几个进阶思路。5.1 处理策略优化增量处理上面的脚本每次都会处理source_images目录下的所有图片。如果图片很多效率会低。可以优化为只处理本次提交中新增或修改的图片。可以通过Git命令比较本次提交与上一次提交的差异来实现。并行处理如果服务器资源允许可以同时启动多个Docker容器并行处理多张图片大幅缩短总处理时间。结果去重在提交到colored/auto分支前可以先对比已有文件只提交真正新生成的或内容有变化的图片避免产生大量无意义的提交历史。5.2 分支与版本管理策略按批次或日期分支除了一个总的colored/auto分支你也可以让流水线根据当前日期或提交ID创建分支如colored/2024-05-27或colored/commit-abc123。这样历史结果的组织更清晰。使用Git Tags标记里程碑当积累到一定数量或完成一个重要批次时可以在colored/auto分支上打一个标签Tag例如v1.0-batch-1方便快速定位重要的版本集合。5.3 扩展与集成可能性集成多种AI模型流水线不限于DeOldify。你可以很容易地扩展脚本让它根据图片类型或你的标注选择不同的模型进行处理比如用另一个模型进行人脸增强再用一个模型进行超分辨率放大。结果通知在GitHub Actions工作流中可以添加步骤在处理完成后通过邮件、Slack或钉钉等工具发送通知告知你处理已完成并附上结果分支的链接。生成处理报告让脚本在处理完成后生成一个简单的HTML或Markdown报告汇总本次处理的图片列表、每张图片的处理状态成功/失败、缩略图对比等并一并提交到结果分支。6. 总结回过头来看我们通过将DeOldify与Git和CI/CD工具链结合成功地把一个手动、琐碎的图片上色任务转化为了一个标准化、自动化、可追溯的工程流程。这套方案的核心价值不在于使用了多么高深的技术而在于用软件工程的成熟思想来重新组织创意或媒体资产的处理过程。它带来的最大改变是思维模式的提升将“素材”视为“代码”将“处理步骤”视为“构建流水线”将“成果”视为“发布版本”。对于开发者而言这套模式可以无缝迁移到其他类似的场景比如用AI模型批量生成文章配图、自动为视频生成字幕、对数据集进行预处理等。任何需要将原始素材通过固定流程转化为新资产的任务都可以尝试套用这个“Git托管 CI/CD触发 自动化处理”的范式。当然初次搭建可能会遇到一些环境或权限上的小挑战但一旦跑通它所带来的长期收益是巨大的。你不必再担心文件版本混乱不必再手动重复操作可以清晰地看到项目进化的每一步。如果你正在管理任何形式的数字资产项目不妨尝试引入这样的自动化流水线它会让你的工作更加从容和高效。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
构建自动化图片处理流水线：DeOldify与Git版本控制结合实践
构建自动化图片处理流水线DeOldify与Git版本控制结合实践1. 引言你有没有遇到过这样的场景手头有一批珍贵的老照片都是黑白的想给它们上色让记忆重新鲜活起来。一张张手动处理太费时费力了。用现成的在线工具又担心隐私和批量处理的麻烦。更头疼的是这些照片可能还在不断收集和整理中。今天处理了10张明天又找到了5张怎么管理不同版本的上色结果怎么确保每次处理的过程都能被记录和复现如果对某张照片的上色效果不满意想回退到之前的版本或者尝试不同的上色风格该怎么办这不仅仅是图片处理的问题更是一个项目管理和工作流自动化的问题。今天我就来分享一个我们团队在实际项目中摸索出来的解决方案将专业的图片上色工具DeOldify与强大的版本控制系统Git结合起来打造一套全自动的图片处理流水线。简单来说我们的做法是把原始黑白照片库当作代码一样用Git仓库来管理。每次有新的照片提交或者对已有照片的标注比如想指定上色风格进行修改时一套自动化的工具链就会被触发。它会自动调用DeOldify模型为这些照片上色然后把生成好的彩色照片连同处理日志一起保存到一个新的、专门的分支里。这样做的好处显而易见整个过程完全自动化无需人工干预每一次处理都有完整的记录可以随时查看、对比甚至回滚处理环境和参数是固定的确保了结果的可复现性。无论是个人整理家族相册还是团队处理历史影像资料这套方法都能大幅提升效率和管理水平。下面我就带你一步步拆解这个方案的实现过程。2. 为什么需要结合Git与自动化处理在深入技术细节之前我们先聊聊为什么要把看似不相关的“版本控制”和“图片上色”绑在一起。理解了背后的痛点你才能更好地应用这个方案。2.1 传统图片处理工作流的短板通常我们处理一批图片的流程可能是这样的收集所有黑白照片到一个文件夹。打开DeOldify的Web界面或运行脚本一张张或批量处理。将上色后的图片手动保存到另一个文件夹比如colored。如果对某张效果不满意重新处理然后用新文件覆盖旧文件或者手动重命名photo_v1.jpg,photo_v2.jpg。这个流程存在几个明显问题版本混乱覆盖旧文件历史版本就丢了。手动命名版本很快就会变得难以管理。过程不可追溯这张照片是用哪个版本的DeOldify处理的当时用了什么参数这些信息都没有记录。无法自动化每次新增照片都需要人工重复操作无法与照片收集过程联动。协作困难如果是团队项目很难同步谁处理了哪些照片效果如何。2.2 Git带来的核心优势Git不仅仅是管理代码的工具它本质上是一个内容寻址的文件系统擅长管理任何文本或二进制文件的变更历史。把它用于图片管理可以带来降维打击的优势完整的版本历史每一次提交都是一次快照。你可以随时看到任何一张照片在任意时间点的状态原始黑白版、第一次上色版、第二次调整版并且可以轻松切换。清晰的处理记录每次提交都必须附带说明commit message。比如“为2024-01批次照片上色使用artistic渲染模式”这条记录就和图片变更绑定在一起过程一目了然。分支的魔力我们可以创建独立的分支来存放自动化处理的结果例如colored/auto。这样原始照片库main分支永远保持干净而上色结果在另一个分支上井然有序互不干扰。触发自动化的钩子Git的提交push动作可以完美地作为触发自动化任务的“开关”。2.3 自动化流水线的价值将DeOldify处理步骤自动化并与Git提交绑定意味着提交即处理你只需要关心把原始照片整理好并提交到Git仓库。剩下的上色、保存、归档工作全部由后台流水线完成。结果可预期流水线每次运行的环境和参数是一致的避免了人工操作可能带来的误差确保了处理结果的质量稳定。解放人力从重复劳动中解放出来专注于更有价值的工作比如筛选照片、调整上色效果的艺术方向等。总结来说Git解决了“管理”和“追溯”的问题而自动化流水线解决了“执行”和“效率”的问题。两者的结合为批量图片处理项目提供了一个专业、可靠且高效的工程化解决方案。3. 核心工具与架构设计工欲善其事必先利其器。在开始搭建之前我们先快速认识一下这个方案里的两位“主角”并看看它们是如何协同工作的。3.1 工具简介DeOldify 与 GitDeOldify是一个基于深度学习的老照片上色项目。它训练好的模型能够非常自然、富有艺术感地为黑白照片添加色彩效果在开源项目中备受好评。对我们来说它就是一个功能强大的“处理函数”我们输入黑白图片它输出彩色图片。Git是我们熟悉的分布式版本控制系统。在这个项目里我们把它用作原始素材库存储未经处理的黑白照片。任务触发器向仓库推送代码照片的行为将作为启动自动化流程的信号。成果档案馆存储经过处理后的彩色照片并保留完整的历史版本。3.2 系统架构与工作流程整个系统的运行流程可以用下面这个简单的图示来理解[开发者本地] | | 1. 添加/更新黑白照片 | 2. 提交(commit)并推送(push)到Git远程仓库 v [Git远程仓库 (如 GitHub, GitLab)] | | 3. 推送事件触发Webhook v [CI/CD 服务器 (如 GitHub Actions, GitLab CI)] | | 4. 启动流水线任务 | 5. 拉取最新代码识别新增/变更的图片 | 6. 调用DeOldify API或容器处理图片 | | 7. 将上色后的图片保存到新位置 | 8. 创建新分支或提交到特定分支 | 9. 将结果推送回Git仓库 v [Git远程仓库] |—— main分支: 纯净的黑白照片库 |—— colored/auto分支: 自动生成的彩色照片库流程核心步骤解读本地操作你在本地电脑上把新的老照片放进项目文件夹用git commit记录这次添加然后用git push推到网上的远程仓库比如GitHub。事件触发远程仓库收到你的推送后会根据设置自动通知一个叫CI/CD服务如GitHub Actions的东西“嘿有人推了新代码”自动处理CI/CD服务收到通知立刻启动一个预设好的任务。这个任务会做以下几件大事拉取你刚刚提交的照片。找到所有需要处理的图片比如/source_images目录下的所有.jpg文件。在一个配置好的环境里已经装好了DeOldify批量处理这些图片。把上好色的图片保存到另一个目录比如/colored_output。结果归档任务完成后CI/CD服务会创建一个新的分支例如叫colored/auto或者向这个分支提交代码把处理好的彩色图片和可能生成的日志文件一起再推回到Git远程仓库。至此一个完整的自动化闭环就完成了。你只需要推送原始照片稍等片刻就能在仓库的colored/auto分支上看到自动上色好的结果。4. 实战搭建一步步实现自动化流水线理论讲完了我们动手搭一个。这里我以GitHub GitHub Actions为例因为这对个人开发者和团队都免费且易于上手。如果你用的是GitLab其概念和步骤使用GitLab CI也几乎完全相同。4.1 第一步准备Git仓库与目录结构首先我们在GitHub上创建一个新的仓库名字可以叫old-photo-coloration-pipeline。在本地克隆这个仓库并建立清晰的目录结构old-photo-coloration-pipeline/ ├── .github/ │ └── workflows/ # GitHub Actions 工作流文件存放处 ├── source_images/ # 存放原始黑白照片 │ ├── photo1.jpg │ └── photo2.png ├── colored_output/ # 自动化生成存放上色后的照片 ├── scripts/ # 可选存放自定义处理脚本 │ └── colorize.py └── README.mdsource_images目录是你唯一需要手动管理的地方所有黑白照片都放在这里。colored_output目录初始为空它将会被自动化流水线填充。4.2 第二步编写图片处理核心脚本我们需要一个脚本来调用DeOldify。这里提供一个基于DeOldify Docker镜像的Python脚本示例它简单而实用。创建scripts/colorize.py#!/usr/bin/env python3 自动化图片上色脚本。 使用DeOldify Docker容器处理指定输入目录中的所有图片并输出到指定目录。 import os import sys import subprocess from pathlib import Path def colorize_images(input_dir: Path, output_dir: Path): 使用DeOldify容器处理图片。 Args: input_dir: 包含黑白图片的输入目录路径。 output_dir: 彩色图片的输出目录路径。 # 确保输出目录存在 output_dir.mkdir(parentsTrue, exist_okTrue) # 支持的图片格式 image_extensions (.jpg, .jpeg, .png, .bmp, .tiff) # 查找所有图片文件 image_files [f for f in input_dir.iterdir() if f.suffix.lower() in image_extensions] if not image_files: print(f在目录 {input_dir} 中未找到图片文件。) return print(f找到 {len(image_files)} 张待处理图片。) for img_path in image_files: output_path output_dir / f{img_path.stem}_colored{img_path.suffix} print(f正在处理: {img_path.name} - {output_path.name}) # 构建Docker命令 # 这里使用DeOldify官方提供的测试用镜像生产环境建议构建自己的镜像 docker_cmd [ docker, run, --rm, -v, f{input_dir}:/data/input, # 挂载输入目录 -v, f{output_dir}:/data/output, # 挂载输出目录 deoldify/test_image_colorizer:latest, process, str(img_path.name) ] try: # 执行命令 result subprocess.run(docker_cmd, capture_outputTrue, textTrue, checkTrue) print(f 成功: {img_path.name}) except subprocess.CalledProcessError as e: print(f 失败: {img_path.name}。错误: {e.stderr}) except Exception as e: print(f 处理 {img_path.name} 时发生未知错误: {e}) print(所有图片处理完成) if __name__ __main__: # 设置路径在GitHub Actions中这些路径基于工作区 base_dir Path(os.getenv(GITHUB_WORKSPACE, .)) input_directory base_dir / source_images output_directory base_dir / colored_output if not input_directory.exists(): print(f错误输入目录不存在 {input_directory}) sys.exit(1) colorize_images(input_directory, output_directory)脚本说明这个脚本使用Docker来运行DeOldify避免了在CI环境中复杂的环境配置。它遍历source_images目录下的图片对每张图片调用一次DeOldify容器。处理后的图片会保存到colored_output目录并在文件名后添加_colored后缀以示区分。4.3 第三步配置GitHub Actions自动化工作流这是自动化的“大脑”。我们在.github/workflows/目录下创建一个YAML文件比如colorize-on-push.yml。name: Auto Colorize Old Photos on: push: branches: - main # 仅当推送到main分支时触发 paths: - source_images/** # 仅当source_images目录下的文件有变化时触发 jobs: colorize: runs-on: ubuntu-latest # 使用最新的Ubuntu系统作为运行环境 steps: # 1. 检出代码获取你刚刚推送的照片 - name: Checkout repository uses: actions/checkoutv4 with: fetch-depth: 0 # 获取所有历史这对Git操作有时是必要的 # 2. 设置Docker因为我们的脚本需要Docker环境 - name: Set up Docker uses: docker/setup-buildx-actionv3 # 3. 运行上色脚本 - name: Run DeOldify colorization run: | python3 scripts/colorize.py env: # 确保脚本能找到正确的路径 GITHUB_WORKSPACE: ${{ github.workspace }} # 4. 准备将结果提交到新分支 - name: Configure Git for automated commits run: | git config --global user.name GitHub Actions Bot git config --global user.email actionsgithub.com # 5. 创建或切换到存放结果的分支并提交上色后的图片 - name: Commit and push colored images run: | # 检查是否有新文件生成 if [ -n $(ls -A colored_output/ 2/dev/null) ]; then # 尝试切换到 colored/auto 分支如果不存在则创建 git checkout -b colored/auto 2/dev/null || git checkout colored/auto # 将上色结果移动到仓库根目录或特定位置并强制覆盖旧文件 # 这里我们选择将colored_output整个目录的内容复制过来 cp -r colored_output/* ./ # 添加所有变更包括新图片和可能被覆盖的旧图片 git add -A # 提交变更提交信息包含触发此次运行的提交ID git commit -m Auto-colorized images via CI [Triggered by ${{ github.sha }}] # 推送到远程的 colored/auto 分支 git push origin colored/auto --force else echo 没有生成新的彩色图片跳过提交。 fi工作流解读触发条件(on)只有当main分支的source_images目录下有文件变动时这个工作流才会运行。这避免了不必要的触发。运行步骤(steps)检出代码获取最新的黑白照片。准备Docker环境为运行DeOldify容器做准备。执行上色运行我们刚才写的Python脚本。配置Git设置一个机器人身份用于后续的自动提交。提交结果这是最关键的一步。它尝试切换到colored/auto分支将处理好的图片复制过来然后提交并推送到远程仓库的这个分支。--force参数是为了确保能更新该分支因为每次运行的结果都是全新的。4.4 第四步测试与运行现在整套系统已经就绪。将本地仓库推送到GitHubgit add . git commit -m “初始化仓库添加首批黑白照片和CI配置” git push origin main观察自动化过程打开你的GitHub仓库页面点击顶部的“Actions”标签页。你应该会看到一个名为“Auto Colorize Old Photos”的工作流正在运行黄色图标稍后会变成绿色成功或红色失败。点击进入可以查看详细日志包括Docker拉取镜像、处理每张图片的输出等。查看结果工作流运行成功后刷新仓库页面。在分支下拉菜单中你应该能看到一个新的分支colored/auto。切换到该分支你就会在仓库根目录下看到所有自动上色后的图片例如photo1_colored.jpg。恭喜你的第一个自动化图片处理流水线已经搭建完成。从此以后你只需要往source_images里丢照片、提交、推送剩下的就交给机器了。5. 进阶优化与实践建议基础流水线跑通后我们可以让它变得更强大、更智能。这里分享几个进阶思路。5.1 处理策略优化增量处理上面的脚本每次都会处理source_images目录下的所有图片。如果图片很多效率会低。可以优化为只处理本次提交中新增或修改的图片。可以通过Git命令比较本次提交与上一次提交的差异来实现。并行处理如果服务器资源允许可以同时启动多个Docker容器并行处理多张图片大幅缩短总处理时间。结果去重在提交到colored/auto分支前可以先对比已有文件只提交真正新生成的或内容有变化的图片避免产生大量无意义的提交历史。5.2 分支与版本管理策略按批次或日期分支除了一个总的colored/auto分支你也可以让流水线根据当前日期或提交ID创建分支如colored/2024-05-27或colored/commit-abc123。这样历史结果的组织更清晰。使用Git Tags标记里程碑当积累到一定数量或完成一个重要批次时可以在colored/auto分支上打一个标签Tag例如v1.0-batch-1方便快速定位重要的版本集合。5.3 扩展与集成可能性集成多种AI模型流水线不限于DeOldify。你可以很容易地扩展脚本让它根据图片类型或你的标注选择不同的模型进行处理比如用另一个模型进行人脸增强再用一个模型进行超分辨率放大。结果通知在GitHub Actions工作流中可以添加步骤在处理完成后通过邮件、Slack或钉钉等工具发送通知告知你处理已完成并附上结果分支的链接。生成处理报告让脚本在处理完成后生成一个简单的HTML或Markdown报告汇总本次处理的图片列表、每张图片的处理状态成功/失败、缩略图对比等并一并提交到结果分支。6. 总结回过头来看我们通过将DeOldify与Git和CI/CD工具链结合成功地把一个手动、琐碎的图片上色任务转化为了一个标准化、自动化、可追溯的工程流程。这套方案的核心价值不在于使用了多么高深的技术而在于用软件工程的成熟思想来重新组织创意或媒体资产的处理过程。它带来的最大改变是思维模式的提升将“素材”视为“代码”将“处理步骤”视为“构建流水线”将“成果”视为“发布版本”。对于开发者而言这套模式可以无缝迁移到其他类似的场景比如用AI模型批量生成文章配图、自动为视频生成字幕、对数据集进行预处理等。任何需要将原始素材通过固定流程转化为新资产的任务都可以尝试套用这个“Git托管 CI/CD触发 自动化处理”的范式。当然初次搭建可能会遇到一些环境或权限上的小挑战但一旦跑通它所带来的长期收益是巨大的。你不必再担心文件版本混乱不必再手动重复操作可以清晰地看到项目进化的每一步。如果你正在管理任何形式的数字资产项目不妨尝试引入这样的自动化流水线它会让你的工作更加从容和高效。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
