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-шлях. Для розробників редакторів, конвертерів та інших інструментів для складних файлів висновок простий: тестуйте читання, збереження й візуальний результат окремо, а прискорені реалізації порівнюйте з контрольною версією на зафіксованих вхідних даних. Так сумісність і продуктивність стають властивостями програми, які можна перевірити.