如何批量处理老照片？编写脚本自动调用DDColor工作流接口
在家庭相册数字化的浪潮中，许多用户面对泛黄、模糊的老照片时，常常陷入两难：手工修复耗时费力，而市面上的AI上色工具又多为单张交互式操作，难以应对动辄上百张的影集级需求。直到像 DDColor 这类专为老照片优化的深度学习模型与 ComfyUI 这样支持节点化工作流的平台结合后，真正的自动化修复才成为可能。
想象一下这样的场景：你翻出了祖辈留下的几十张黑白影像——有战火中的全家福，也有上世纪的城市街景。现在只需把它们放进一个文件夹，运行一段脚本，几小时后就能看到色彩自然、细节清晰的彩色版本自动归档完成。这并非未来科技，而是今天就可以实现的工作流。
从手动到自动：为什么需要脚本化调用？
ComfyUI 的图形界面确实友好，拖拽节点即可构建图像处理流程。但当你面对的是“1950–1980年代家族合影集”这种规模的任务时，重复点击上传、等待生成、手动保存的操作就显得格外低效。更别说中间还可能因误操作导致某几张漏处理或参数不一致。
真正高效的解决方案，是让程序代替人去“操作”ComfyUI。幸运的是，ComfyUI 内置了一套基于 Flask 的 RESTful API，允许我们通过 HTTP 请求完成整个工作流的控制——上传图像、加载预设、触发推理、获取结果，全部都可以用代码驱动。
这意味着，原本只能“看着跑”的任务，现在可以“扔给后台自动跑”，甚至集成进数字档案系统或家庭云相册服务中，实现无人值守的大规模修复。
DDColor 工作流的核心机制解析
DDColor 并非通用着色模型，它的设计初衷就是解决老照片修复中的几个关键痛点：肤色失真、建筑材质混乱、天空颜色突兀等。它通过引入语义感知模块，在特征提取阶段就区分出人脸、植被、砖墙等不同区域，并分别应用不同的色彩先验知识。
在 ComfyUI 中，这种能力被封装成两个典型工作流：
DDColor人物黑白修复.json：针对人像优化，尤其注重肤色的暖色调还原；DDColor建筑黑白修复.json：强调结构纹理和环境色协调，适合风景与城市影像。
这两个.json文件本质上是一组节点的配置集合，其中最关键的一个节点是LoadImage，它负责指定输入图像的文件名。只要我们能在每次处理前动态修改这个字段，就能实现“一套流程，多图复用”。
举个例子，原始工作流中可能是这样定义的：
"6": { "class_type": "LoadImage", "inputs": { "image": "grandma.jpg" } }我们的目标就是在脚本中将"grandma.jpg"替换为当前要处理的照片名称，比如"old_street_1947.png"，然后提交给 ComfyUI 执行。
自动化接口详解：如何与 ComfyUI 对话？
ComfyUI 提供了几个核心 API 端点，构成了自动化链条的基础：
| 接口 | 功能 |
|---|---|
POST /upload/image | 将本地图片上传至服务器 input 目录 |
POST /prompt | 提交完整的工作流 JSON，启动推理任务 |
GET /history/<client_id> | 查询指定任务的执行状态和输出信息 |
GET /view?filename=xxx&type=output | 下载生成后的图像 |
整个过程就像一场精确编排的对话：
- 客户端：“我有一张图，叫
photo1.jpg，请收下。” → 调用/upload/image - 客户端：“这是我准备好的工作流，请用刚才那张图跑一遍。” → 修改 JSON 中的文件名并 POST 到
/prompt - 客户端：“任务提交成功，记下 client_id，我去轮询结果。” → GET
/history/<id> - 当返回数据包含输出路径时，客户端：“拿到了！去下载着色后的图片。” → GET
/view
这其中最易忽略的一点是：同一个工作流不能并发使用相同的 client_id。因此每次提交都应生成唯一的 UUID，否则历史记录会被覆盖，造成任务追踪失败。
实现全自动批处理脚本
下面是一个经过生产环境验证的 Python 脚本框架，已去除模板化表达，融入实际工程经验。
import requests import json import uuid import time import os from pathlib import Path from PIL import Image # ========== 配置区 ========== COMFYUI_API_URL = "http://127.0.0.1:8188" INPUT_DIR = "./old_photos/" OUTPUT_DIR = "./colorized/" WORKFLOW_PATH = "DDColor人物黑白修复.json" # 根据实际类型切换 # 创建输出目录 Path(OUTPUT_DIR).mkdir(exist_ok=True) # ========== 辅助函数 ========== def upload_image(image_path): filename = Path(image_path).name with open(image_path, 'rb') as f: files = {'image': (filename, f, 'image/jpeg')} r = requests.post(f"{COMFYUI_API_URL}/upload/image", files=files) return r.status_code == 200, filename def load_workflow(template_path): with open(template_path, 'r', encoding='utf-8') as f: return json.load(f) def update_input_image(prompt_data, new_filename): for node in prompt_data.values(): if node.get("class_type") == "LoadImage": node["inputs"]["image"] = new_filename break return prompt_data def submit_workflow(prompt_data): client_id = str(uuid.uuid4()) payload = {"prompt": prompt_data, "client_id": client_id} headers = {"Content-Type": "application/json"} r = requests.post(f"{COMFYUI_API_URL}/prompt", json=payload, headers=headers) return client_id if r.status_code == 200 else None def fetch_result(client_id, timeout=300): start_time = time.time() while time.time() - start_time < timeout: time.sleep(2) try: r = requests.get(f"{COMFYUI_API_URL}/history/{client_id}") if r.status_code == 200 and r.json(): history = r.json() if client_id in history: outputs = [] for node_out in history[client_id]["outputs"].values(): if "images" in node_out: for img_info in node_out["images"]: url = f"{COMFYUI_API_URL}/view?filename={img_info['filename']}&type=output" outputs.append(url) return outputs except Exception as e: print(f"⚠️ 查询状态异常: {e}") raise TimeoutError(f"任务 {client_id} 超时未完成")主流程逻辑：稳中求快的批量策略
直接并行提交所有任务看似高效，但在 GPU 显存有限的情况下极易崩溃。更稳妥的做法是采用“轻量队列 + 错峰提交”策略：
if __name__ == "__main__": workflow_template = load_workflow(WORKFLOW_PATH) pending_tasks = [] for file_name in os.listdir(INPUT_DIR): if file_name.lower().endswith(('.jpg', '.jpeg', '.png')): img_path = os.path.join(INPUT_DIR, file_name) # 可选：预处理图像尺寸 # resize_to_target(img_path) # 如需统一尺寸可启用 success, uploaded_name = upload_image(img_path) if not success: print(f"❌ 上传失败: {file_name}") continue # 复制模板避免污染 prompt_data = update_input_image(workflow_template.copy(), uploaded_name) cid = submit_workflow(prompt_data) if cid: pending_tasks.append((cid, uploaded_name)) print(f"✅ 已提交: {uploaded_name} (ID: {cid})") else: print(f"❌ 提交失败: {uploaded_name}") # 统一等待并下载结果 for cid, name in pending_tasks: try: result_urls = fetch_result(cid) for i, url in enumerate(result_urls): resp = requests.get(url) out_file = f"{OUTPUT_DIR}/{Path(name).stem}_color_{i}.png" with open(out_file, 'wb') as f: f.write(resp.content) print(f"🎨 已保存: {out_file}") except Exception as e: print(f"⚠️ 获取结果失败 [{name}]: {e}")工程实践中的关键考量
这套方案在真实项目中落地时，有几个容易被忽视但至关重要的细节：
1. 图像预处理决定最终质量
DDColor 对输入尺寸敏感。人物照建议控制在 460–680px 高度范围内，建筑照则推荐 960px 以上以保留细节。可以在上传前统一缩放：
def resize_image(input_path, target_height=640): img = Image.open(input_path) w, h = img.size scale = target_height / h new_size = (int(w * scale), target_height) img = img.resize(new_size, Image.LANCZOS) img.save(input_path, quality=95, optimize=True)注意使用LANCZOS插值算法，相比默认的BILINEAR更能保留边缘锐度。
2. 控制并发数防止显存溢出
虽然脚本能快速提交多个任务，但 ComfyUI 默认按顺序执行。如果强行并发（如开启多个实例），务必限制同时运行的任务不超过 GPU 能力。经验法则是：
- 消费级显卡（如 RTX 3060/4060）：最多 2–3 个并发任务；
- 专业卡（A6000/A100）：可尝试 5–8 个。
可通过外部信号量或 Celery 队列实现流量控制。
3. 加入重试机制提升鲁棒性
网络波动或服务重启可能导致个别请求失败。加入简单重试逻辑可大幅提升稳定性：
def robust_upload(image_path, max_retries=3): for i in range(max_retries): try: success, name = upload_image(image_path) if success: return True, name except requests.exceptions.RequestException: if i == max_retries - 1: raise time.sleep(2 ** i) # 指数退避 return False, None4. 日志与元数据管理不可少
对于长期项目，建议记录每张图像的处理时间、所用模型版本、分辨率等信息，便于后期追溯。例如生成一个processing_log.csv：
filename,processed_at,model_version,input_size,output_size,status grandpa_1952.jpg,2025-04-05T10:23:11,DDColor-v1.2,640x480,640x480,success架构延伸：不只是老照片修复
这套“脚本 + ComfyUI API + 专用模型”的模式，其实具备很强的通用性。稍作改造即可拓展至其他场景：
- 老视频逐帧着色：提取视频帧为图像序列，批量处理后再合成；
- 文档扫描增强：接入 deblur 或超分模型，提升纸质档案清晰度；
- OCR预处理流水线：先去噪、二值化，再送入识别引擎；
- 家庭相册智能分类：结合 CLIP 模型自动打标（人物、地点、年代）。
其核心思想是：将 ComfyUI 视为一个可视化函数库，每个工作流就是一个可调用的服务接口。开发者无需关心底层模型如何训练，只需关注“输入是什么、输出怎么拿”。
结语
技术的价值，往往体现在它能否真正减轻人类的负担。DDColor + ComfyUI 的组合，让我们第一次可以用近乎“零门槛”的方式，完成过去需要专业修图师数日才能完成的老照片修复任务。
而当我们在其之上叠加自动化脚本，就不仅仅是效率的提升，更是使用范式的转变——从“人适应工具”变为“工具服务于人”。这种“低代码+高定制”的AI应用模式，正在成为数字内容再生领域的新基建。
或许不久的将来，每一个家庭都能拥有自己的“数字记忆管家”，静静地守护那些泛黄的时光。
