不用 Electron 的 PSD 渲染：只差 2 个文件就对齐 307/309

半糖去冰 技术创作者 2026-11-01 14 阅读

10 月 27 日，PhotoCraft 发布 v0.17.0，修复了 DNG 原始文件读取、DDS 导出 alpha 通道、多个 PSD/TIFF 兼容问题。截至 10 月 31 日抓取时，这个纯 Rust 写的开源照片编辑器在 GitHub 上有 75.5k stars、13.4k forks、8,143 次提交。为什么现在值得看：它在短时间内密集发布 PSD 兼容补丁，同时保留一个少见的架构承诺——clean-room 重实现、纯 Rust、GPU 合成，没有 Electron。对关注开源图像工具和 Rust 桌面应用的人，这是一个观察点。

为什么 v0.17.0 值得看：PSD 兼容补丁密集出现

v0.17.0 的发布说明里，大部分条目都在处理文件格式兼容：识别 Photoshop 的 MTrn 合并透明标记、修正 PSD 专色通道极性、保留 PSD 字节序、写 Photoshop 全局图层蒙版块、重建直方图面板、修复 .cube LUT 加载。这些都不是新功能开发，而是把“打开别人的 PSD 再保存”这件事做得更稳。

按官方 README 的说法，PhotoCraft 的目标是“打开、编辑和保存分层 Photoshop 文档”，并明确给出一个数字：重保存后保持 307 个 psd-tools 测试文件中的 307 个渲染一致（原文是 “Re-saving keeps the render of 307 of the 309 psd-tools test files”）。官方还在特性列表里列了 16 个调整图层，包括 Curves、Levels、Black & White、Channel Mixer、Gradient Map 等。v0.17.0 的多项 PSD 修复意味着，官方在持续缩小这 2 个文件的差距。这是文档和 changelog 对比后能看出的一个动态：官方没有在 README 里写“还剩 2 个不兼容”，但 release notes 暴露了它还在追。

不是又一个 Electron 壳：架构上的三个硬选择

PhotoCraft 的 README 开头写着 “clean-room reimplementation of Adobe Photoshop, rebuilt in pure Rust”。这不是换个皮，而是三个层面的选择：

  1. 纯 Rust，24 个 crate 分层：在 v0.12.0 README 的 “Under the hood” 一节，官方说“Layering is enforced at build time across 24 crates”，引擎先于 UI，UI 只是薄薄一层 egui。这意味着核心逻辑不绑定任何 GUI 框架。
  2. GPU compositor，无 Electron：主仓库明确说 “A GPU compositor on wgpu (Metal, Vulkan, DX12, WebGPU)”，而且 “No Electron, no web view, no waiting”。对比的是常见用 Electron 包装 Web 界面的编辑器。
  3. 双 compositor 互为 oracle：CPU compositor 作为参考实现，wgpu compositor 负责实际渲染，两者互相测试。这种设计在开源图像编辑器里少见。

这三条的共同目标是性能和大画布。官方给出的瓦片尺寸是 256² 稀疏瓦片（copy-on-write tiles），让撤销便宜、大画布轻量。另外，整个引擎和 UI 可以编译到 WebAssembly，在浏览器里运行。注意这些是 v0.12.0 README 的内容，版本较旧，但主仓库首页描述一致。

设计选择 PhotoCraft 的做法 常见桌面编辑器做法
渲染后端 wgpu GPU compositor（Metal/Vulkan/DX12/WebGPU） 常常是 CPU 合成或捆绑单一图形 API
架构 纯 Rust，引擎与 UI 分层，24 个 crate C/C++ 或混合语言，UI 与核心耦合
无 Electron 明确 “No Electron, no web view” 部分编辑器用 Electron 包装 Web 引擎
测试策略 CPU 与 GPU compositor 互为 oracle，超过 1,700 个测试（v0.12.0） 通常以手工测试或单元测试为主

表格里第二列是本文作者基于常见开源图像编辑器的概括，不是官方对比；第一列每一项都能在官方 README 或 v0.12.0 README 里找到原文。

PSD 兼容性：307/309 意味着什么？

官方明确说 “Re-saving keeps the render of 307 of the 309 psd-tools test files”。我们可以复算：307 ÷ 309 ≈ 0.9935，即约 99.35%。这是我的推算，不是官方口径。注意官方没有给百分比，只给了分子分母，所以结论是“在 309 个测试文件中，重保存后有 2 个的渲染不一致”。

这个数字有两个边界要看清。第一，它衡量的是 psd-tools 测试集，不是所有 PSD 文件；测试集之外的复杂 PSD 可能表现不同。第二，“keeps the render” 指的是重保存后的渲染保持一致，不等于完全无损支持所有 Photoshop 特性。v0.17.0 修复了 MTrn 标记、专色通道极性、全局图层蒙版块，说明这几个特性之前都有坑。这两点边界是我的分析，不是官方说法。

从发布节奏看，PSD 兼容是项目最活跃的前线之一。但官方没有承诺 100% 兼容 Adobe Photoshop，而是用 clean-room 方式从公开规范和观察行为实现，这天然限制了某些视觉特性的复刻精度。

桌面编辑器和无头 CLI 是同一套引擎

PhotoCraft 的一个特点是每个动作都是命令。主仓库说：“Every action is a command, so you can drive the same engine from the UI, the CLI, a JSON control channel or an MCP server.” 这意味着你可以在 GUI 里点按钮，也可以通过命令行做批量处理，甚至用 MCP 服务器驱动。

v0.12.0 README 提到桌面应用提供 “authenticated, loopback-only control channel (photocraft –control)”，可以检查 UI 状态、驱动工具、截取离屏截图；README 里所有截图都是通过这个控制通道渲染的。

对用户来说，这意味着同一个 PSD 处理逻辑可以在交互编辑和自动化流水线之间复用，不用维护两套代码。代码块来自官方 v0.12.0 README 的 Get started 部分：

git clone https://github.com/storytold/photocraft
cd photocraft
cargo run --release -p photocraft -- image.psd   # 桌面应用

这个命令启动的是桌面应用；要使用无头功能，需要单独安装或编译 photocraft-cli。开源社区里，这种“引擎命令化”的设计并不新鲜，但把它作为一等公民并暴露 MCP 接口，更符合当下 Agent 工具链的用法。

Clean-room 承诺的另一面：贡献压力与 2.4k issues

photoCraft 的 clean-room 声明很硬：只从公开规范和观察行为实现，没有专有代码、着色器或资产。这降低了版权风险，但也意味着很多 Photoshop 特有的算法不能直接参考 Adobe 的实现，只能靠社区逆向工程和测试。这些后续判断是我的推导，不是官方说法。

仓库的 GitHub 页面上，截至 2026-10-31，有 2.4k issues 和 1.2k pull requests。这两个数字要一起看 —— 单看 issue 数会觉得项目乱，但配上 PR 数更接近真实情况：大量 issue 其实是被 PR 消化掉的。这对一个工具类项目是好事，说明需求进得来、也出得去。这两个数字意味着活跃，也意味着维护压力。v0.17.0 的修复列表里能看到多位外部贡献者的名字（@SBaksa、@artman67、@FinnNk、@jasallen 等），其中 @jasallen 一个人就出现在多条条目上，说明项目依赖外部贡献，但贡献并不均匀分布。这种模式下，代码审查和合并速度可能成为瓶颈。

另一个推导边界是：327 个 watching 用户相对于 75.5k stars 的比例很低，说明大部分 star 用户只是关注，没有深度参与。这是我的经验判断，不是官方说法。对于想在生产环境使用 PhotoCraft 的用户，应该关注 issues 中是否还有未解决的 PSD 兼容问题，以及发布节奏是否稳定。

参考来源

# AI# 知识

评论区

0 条评论

登录后可评论。

半糖去冰 14 阅读