PhotoCraft v0.7: jak sprawdzać zgodność PSD i tworzyć szybki edytor

Plik PSD może otworzyć się w edytorze, a mimo to wyglądać inaczej: różnica może dotyczyć maski, tekstu, efektu warstwy lub kolejności nakładania. Jednym ze sposobów sprawdzenia wyniku jest porównanie ponownie złożonej kompozycji z obrazem scalonym osadzonym w samym pliku PSD. Wydany 11 października 2026 roku PhotoCraft v0.7.0 to okazja, by przyjrzeć się temu podejściu inżynieryjnemu na przykładzie otwartego edytora grafiki napisanego w Rust.

W wydaniu wymieniono zmiany dotyczące pędzli, zaznaczania, masek, importu OpenRaster i innych elementów edytora. Dla programistów szczególnie interesująca jest opublikowana dokumentacja projektu: opisuje testy importu PSD, porównywanie kompozytorów oraz zestaw plików wykorzystywany do powtarzalnych kontroli.

PSD zawiera wzorzec do porównania

Wielowarstwowy plik PSD zawiera strukturę warstw i scalony obraz dokumentu. PhotoCraft renderuje warstwy, a następnie porównuje wynik z osadzoną kompozycją. Taki test sprawdza, jak wiernie program odtwarza wygląd dokumentu podczas obsługi tekstu, korekt, efektów i innych funkcji formatu.

W opisie architektury PhotoCraft to podejście nazwano „wyrocznią kompozytora”. Dokumentacja testów wymienia trzy zestawy plików PSD: 256 plików utworzonych przez zespół w Photoshopie, 170 plików z zestawów psd-tools i ag-psd oraz osobny zestaw psd-tools zawierający 309 plików. Zestawy są pobierane w przypiętych wersjach i weryfikowane za pomocą sum kontrolnych.

Twórcom oprogramowania obsługującego formaty plików pomaga rozdzielenie testów według pytań, na które odpowiadają. Analiza struktury pokazuje, czy udało się odczytać dokument; test cyklu otwierania i zapisywania — czy dane zostały zachowane; porównanie kompozycji — jak wiernie odtworzono obraz. Dokumentacja PhotoCraft opisuje zarówno testy stabilności bajtów dla niezmienionych plików, jak i porównania z osadzoną kompozycją PSD.

Kompozytor CPU pełni rolę implementacji referencyjnej

Projekt opisuje kompozytor CPU jako referencyjną ścieżkę eksportu i testów; kompozytor GPU oparty na wgpu wykonuje ten sam plan operacji dla obszaru roboczego. W dokumentacji architektury podano, że wyniki są porównywane z tolerancją do 1/255 dla wyjścia 8-bitowego, a kontrola CPU/GPU jest przeprowadzana w CI, również na programowym adapterze graficznym.

GPU jest potrzebne do interaktywnego obszaru roboczego, ale dostępność ścieżki sprzętowej zależy od dokumentu i środowiska. Podręcznik wskazuje, że dokumenty wielokanałowe oraz obszary przekraczające limit tekstury są obsługiwane przez kompozytor CPU; po utracie urządzenia GPU obszar roboczy również przełącza się na CPU. Są to konkretne warunki przejścia między ścieżkami, a nie twierdzenie o jednakowej szybkości na każdym urządzeniu.

Ogólny wzorzec można zastosować także w innych systemach obliczeniowych: warto utrzymywać sprawdzalną implementację referencyjną obok zoptymalizowanej ścieżki i uruchamiać je na identycznych danych wejściowych. W przypadku bazy danych może to być prosty interpreter obok zoptymalizowanego silnika, a w przetwarzaniu multimediów — ścieżka programowa obok akceleracji sprzętowej. Porównanie ujawnia rozbieżności w wynikach; staje się powtarzalne, gdy ustalone są dane wejściowe i kryterium dopuszczalnej różnicy.

Jak przełożyć ten schemat na działające testy

1. Zbuduj niewielki, zróżnicowany zestaw plików. Uwzględnij pliki z maskami, tekstem, grupami, przezroczystością, efektami i różnymi trybami kolorów. Zapisz pochodzenie plików i wersje zestawu, aby kolejne uruchomienia korzystały z tych samych danych wejściowych.
2. Wybierz wzorzec i tolerancję. W przypadku PSD można porównać wynik z osadzoną, scaloną kompozycją. Określ dopuszczalny błąd i osobno sprawdzaj wymiary, profil kolorów oraz kanał alfa, jeśli są ważne dla aplikacji.
3. Rozdziel import, zapis i renderowanie. Osobne testy mogą sprawdzać analizę warstw, ponowne otwarcie po zapisie oraz zgodność obrazu ze wzorcem. Ułatwia to ustalenie, na którym etapie pojawił się błąd.
4. Uruchamiaj te same przypadki na różnych backendach. Porównaj wyniki CPU i GPU dla tych samych dokumentów, uwzględniając testy na granicach kafelków i z efektami. Zachowuj dane wejściowe i obraz różnicy, aby można było odtworzyć regresję.
5. Zapisuj warunki pomiaru wydajności. Podawaj rozmiar dokumentu, liczbę warstw, sprzęt i stan pamięci podręcznej. Dokumentacja PhotoCraft zawiera polecenia do uruchamiania poszczególnych testów i porównywania kompozytorów; przedstawione tam pomiary dotyczą konkretnych konfiguracji i scenariuszy.

Podręcznik programistyczny PhotoCraft opisuje polecenia służące do sprawdzania zestawów PSD, różnic wizualnych i zachowania różnych ścieżek kompozycji. Może posłużyć za konkretny punkt wyjścia do poznania infrastruktury testowej edytora; wartości wydajności podane w dokumentacji należy interpretować w kontekście wskazanych tam danych wejściowych i konfiguracji sprzętowej.

Co pokazuje przykład PhotoCraft

Wydanie PhotoCraft v0.7.0 łączy zmiany w samym edytorze, a dokumentacja projektu ujawnia osobną praktykę inżynieryjną: kontrolne pliki PSD do sprawdzania kompozycji oraz implementację CPU, z którą porównywana jest ścieżka GPU. Dla twórców edytorów, konwerterów i innych narzędzi obsługujących złożone pliki wniosek jest prosty: testuj osobno odczyt, zapis i wynik wizualny, a przyspieszone implementacje porównuj z wersją referencyjną na ustalonych danych wejściowych. Dzięki temu zgodność i wydajność stają się sprawdzalnymi właściwościami programu.