PhotoCraft v0.7: så testas PSD-kompatibilitet och en snabb redigerare byggs

En PSD-fil kan öppnas i en redigerare och ändå se annorlunda ut: skillnaden kan gälla en mask, text, en lagereffekt eller lagerordningen. Ett sätt att kontrollera resultatet är att jämföra den återskapade kompositionen med den sammanslagna bilden som är inbäddad i själva PSD-filen. PhotoCraft v0.7.0, som släpptes den 11 oktober 2026, ger anledning att titta närmare på den här tekniska metoden med ett exempel från en öppen grafikredigerare skriven i Rust.

Versionsinformationen räknar upp ändringar i penslar, markering, masker, import av OpenRaster och andra delar av redigeraren. För utvecklare är projektets publicerade dokumentation särskilt intressant: den beskriver tester för PSD-import, jämförelser mellan kompositerare och en samling filer som används för reproducerbara kontroller.

PSD-filen innehåller en referens för jämförelse

En PSD-fil med flera lager innehåller både lagerstrukturen och en sammanslagen bild av dokumentet. PhotoCraft renderar lagren och jämför sedan resultatet med den inbäddade kompositionen. Testet visar hur nära programmet kan återge dokumentets utseende när det hanterar text, justeringslager, effekter och andra formatfunktioner.

I PhotoCrafts arkitekturbeskrivning kallas metoden en ”kompositionsorakel”. Testdokumentationen listar tre PSD-samlingar: 256 filer skapade av teamet i Photoshop, 170 filer från samlingar i psd-tools och ag-psd samt en separat psd-tools-samling med 309 filer. Samlingarna hämtas från låsta versioner och verifieras med kontrollsummor.

För den som utvecklar stöd för ett filformat är det bra att skilja mellan tester utifrån vilken fråga de besvarar. En strukturanalys visar om dokumentet gick att läsa; ett test av öppning och sparande visar om data bevarades; en jämförelse av kompositionen visar hur korrekt det visuella resultatet återgavs. PhotoCrafts dokumentation beskriver både kontroller av byte-stabilitet för oförändrade filer och jämförelser med PSD-filens inbäddade komposition.

CPU-kompositeraren fungerar som referensimplementation

Projektet beskriver CPU-kompositeraren som referensväg för export och tester; GPU-kompositeraren, som bygger på wgpu, utför samma operationsplan för arbetsytan. I arkitekturdokumentationen anges att resultaten jämförs med en tolerans på upp till 1/255 för 8-bitars utdata och att CPU/GPU-kontrollen körs i CI, bland annat på en mjukvarubaserad grafikadapter.

GPU:n behövs för en interaktiv arbetsyta, men tillgången till hårdvaruvägen beror på dokumentet och miljön. Handboken anger att dokument med flera kanaler och områden som överskrider texturgränsen hanteras av CPU-kompositeraren; om GPU-enheten försvinner växlar arbetsytan också till CPU. Det här är konkreta villkor för att byta mellan vägarna, inte ett påstående om enhetlig hastighet på alla enheter.

Samma mönster kan användas i andra beräkningssystem: ha en verifierbar referensimplementation vid sidan av den optimerade vägen och kör båda med samma indata. För en databas kan det vara en enkel tolk bredvid en optimerad motor, och för mediebearbetning en mjukvaruväg bredvid hårdvaruacceleration. Jämförelsen visar avvikelser i resultaten; den blir reproducerbar när indata och kriteriet för godtagbar skillnad är fastställda.

Så omsätter du metoden i fungerande tester

1. Bygg en liten och varierad samling. Ta med filer med masker, text, grupper, transparens, effekter och färglägen. Dokumentera filernas ursprung och samlingens versioner så att senare körningar använder samma indata.
2. Välj referens och tolerans. För PSD-filer kan du jämföra resultatet med den inbäddade sammanslagna kompositionen. Bestäm den godtagbara avvikelsen och kontrollera separat dimensioner, färgprofil och alfakanal om de är viktiga för ditt program.
3. Skilj på import, sparande och rendering. Separata tester kan kontrollera lageranalys, om dokumentet går att öppna igen efter att det sparats och om bilden stämmer med referensen. Då blir det lättare att hitta i vilket steg felet uppstod.
4. Kör samma testfall genom olika backendlösningar. Jämför CPU- och GPU-resultat för samma dokument, även med tester vid kakelgränser och med effekter. Spara indata och den visuella skillnaden så att en regression kan återskapas.
5. Dokumentera förutsättningarna för prestandamätningar. Ange dokumentstorlek, antal lager, maskinvara och cachens tillstånd. PhotoCrafts dokumentation innehåller kommandon för enskilda tester och jämförelser mellan kompositerare; mätvärdena gäller specifika konfigurationer och scenarier.

PhotoCrafts utvecklarhandbok beskriver kommandon för att testa PSD-samlingar, visuella avvikelser och hur olika kompositionsvägar fungerar. Den kan användas som en konkret startpunkt för att utforska redigerarens testinfrastruktur; prestandasiffrorna i dokumentationen bör läsas tillsammans med de indata och den maskinvarukonfiguration som anges där.

Vad PhotoCraft-exemplet visar

PhotoCraft v0.7.0 samlar ändringar i själva redigeraren, medan projektets dokumentation belyser en separat teknisk metod: referens-PSD-filer för att kontrollera kompositioner och en CPU-implementation som GPU-vägen jämförs med. För utvecklare av redigerare, konverterare och andra verktyg för komplexa filer är lärdomen enkel: testa läsning, sparande och visuellt resultat var för sig, och jämför optimerade implementationer med en referensversion med låsta indata. På så sätt blir kompatibilitet och prestanda egenskaper hos programmet som går att verifiera.