PhotoCraft v0.7: как проверять совместимость PSD и строить быстрый редактор

PSD может открыться в редакторе и всё же выглядеть иначе: разница может затронуть маску, текст, эффект слоя или порядок наложения. Один способ проверять результат — сравнить повторно собранную композицию со сведённым изображением, встроенным в сам PSD. Вышедший 11 октября 2026 года PhotoCraft v0.7.0 даёт повод рассмотреть эту инженерную схему на примере открытого графического редактора, написанного на Rust.

В релизе перечислены изменения кистей, выделения, масок, импорта OpenRaster и других частей редактора. Для разработчиков особенно интересна опубликованная документация проекта: в ней описаны тесты импорта PSD, сравнение композиторов и корпус файлов, используемый для воспроизводимых проверок.

PSD хранит эталон для сравнения

Многослойный PSD содержит структуру слоёв и сведённое изображение документа. PhotoCraft рендерит слои, затем сопоставляет результат с этим встроенным композитом. Такой тест проверяет, насколько близко программа воспроизводит вид документа при обработке текста, коррекций, эффектов и других функций формата.

В описании архитектуры PhotoCraft этот подход назван «оракулом композитора». Документация по тестированию перечисляет три корпуса PSD: 256 файлов, созданных командой в Photoshop, 170 файлов из наборов psd-tools и ag-psd, а также отдельный набор psd-tools из 309 файлов. Корпуса загружаются по зафиксированным версиям и проверяются по контрольным суммам.

Для разработчика формата полезно разделять проверки по тому, на какой вопрос они отвечают. Разбор структуры показывает, удалось ли прочитать документ; тест цикла открытия и сохранения — сохранились ли данные; сравнение композита — насколько верно воспроизведён визуальный результат. В документации PhotoCraft перечислены и проверки стабильности байтов для неизменённых файлов, и сравнения со встроенной композицией PSD.

CPU-композитор служит контрольной реализацией

Проект описывает CPU-композитор как эталонный путь для экспорта и тестов; GPU-композитор на wgpu выполняет тот же план операций для холста. В архитектурной документации заявлено, что результаты сопоставляются с допуском до 1/255 для 8-битного вывода, а проверка CPU/GPU выполняется в CI, в том числе на программном графическом адаптере.

GPU нужен для интерактивного холста, но доступность аппаратного пути зависит от документа и среды. Руководство указывает, что многоканальные документы и области, превышающие лимит текстуры, обрабатываются CPU-композитором; при потере GPU-устройства холст также переключается на CPU. Это конкретные условия перехода между путями, а не утверждение о единой скорости на любом устройстве.

Общий шаблон применим и к другим вычислительным системам: держать проверяемую контрольную реализацию рядом с оптимизированным путём и прогонять их на одинаковых входах. Для базы данных это может быть простой интерпретатор рядом с оптимизированным движком, для медиаобработки — программный путь рядом с аппаратным ускорением. Сравнение показывает расхождения результатов; оно становится воспроизводимым, когда зафиксированы входы и критерий допустимой разницы.

Как превратить схему в рабочие тесты

1. Соберите небольшой, разнообразный корпус. Включите файлы с масками, текстом, группами, прозрачностью, эффектами и цветовыми режимами. Зафиксируйте происхождение файлов и версии корпуса, чтобы последующие прогоны использовали одинаковые входы.
2. Выберите эталон и допуск. Для PSD можно сравнивать результат с встроенным сведённым композитом. Определите допустимую погрешность и отдельно проверяйте размеры, цветовой профиль и альфа-канал, если они важны для вашего приложения.
3. Разделите импорт, сохранение и рендеринг. Отдельные тесты могут проверять разбор слоёв, повторное открытие после сохранения и совпадение изображения с эталоном. Так легче установить, на каком этапе возникла ошибка.
4. Прогоняйте одинаковые случаи через разные бэкенды. Сравните CPU- и GPU-результаты на одних документах, включая тесты на границах плиток и с эффектами. Сохраняйте вход и визуальную разницу, чтобы регрессию можно было воспроизвести.
5. Записывайте условия измерения производительности. Указывайте размер документа, число слоёв, оборудование и состояние кэша. В документации PhotoCraft есть команды для отдельных тестов и сравнения композиторов; приведённые там замеры относятся к конкретным конфигурациям и сценариям.

Руководство по разработке PhotoCraft описывает команды для проверки PSD-корпусов, визуальных расхождений и поведения разных путей композиции. Его можно использовать как конкретную отправную точку для изучения тестовой инфраструктуры редактора; числа производительности из документации следует читать вместе с указанными там входами и аппаратной конфигурацией.

Что показывает пример PhotoCraft

Релиз PhotoCraft v0.7.0 объединяет изменения самого редактора, а документация проекта раскрывает отдельную инженерную практику: контрольные PSD для проверки композиции и CPU-реализацию, с которой сравнивают GPU-путь. Для разработчиков редакторов, конвертеров и других инструментов для сложных файлов полезный вывод прост: тестируйте чтение, сохранение и визуальный результат по отдельности, а ускоренные реализации сравнивайте с контрольной версией на зафиксированных входах. Так совместимость и производительность превращаются в проверяемые свойства программы.