PhotoCraft v0.7: Slik tester du PSD-kompatibilitet og bygger en rask editor

En PSD-fil kan åpnes i et redigeringsprogram og likevel se annerledes ut: forskjellen kan gjelde en maske, tekst, en lageffekt eller lagrekkefølgen. Én måte å teste resultatet på er å sammenligne den gjenskapte komposisjonen med det sammenslåtte bildet som er innebygd i selve PSD-filen. PhotoCraft v0.7.0, utgitt 11. oktober 2026, gir anledning til å se nærmere på denne tekniske tilnærmingen med utgangspunkt i et åpent grafikkprogram skrevet i Rust.

Utgivelsen lister opp endringer i pensler, markeringer, masker, import av OpenRaster og andre deler av programmet. For utviklere er prosjektets publiserte dokumentasjon særlig interessant: Den beskriver tester av PSD-import, sammenligning av kompositorer og et filutvalg som brukes til reproducerbare kontroller.

PSD-filen inneholder en referanse for sammenligning

En PSD-fil med flere lag inneholder lagstrukturen og et sammenslått bilde av dokumentet. PhotoCraft gjengir lagene og sammenligner deretter resultatet med den innebygde komposisjonen. En slik test undersøker hvor nøyaktig programmet gjenskaper dokumentets utseende når det håndterer tekst, justeringer, effekter og andre funksjoner i formatet.

I beskrivelsen av PhotoCraft-arkitekturen omtales denne tilnærmingen som en «kompositor-orakel». Testdokumentasjonen lister opp tre PSD-samlinger: 256 filer laget av teamet i Photoshop, 170 filer fra samlingene psd-tools og ag-psd, samt en egen psd-tools-samling med 309 filer. Samlingene lastes ned fra fastlåste versjoner og kontrolleres med kontrollsummer.

For formatutviklere er det nyttig å skille mellom tester ut fra hva de skal svare på. Strukturanalyse viser om dokumentet kunne leses; tester av åpning og lagring viser om dataene ble bevart; sammenligning av komposisjoner viser hvor nøyaktig det visuelle resultatet ble gjenskapt. PhotoCraft-dokumentasjonen beskriver både tester av byte-stabilitet for uendrede filer og sammenligninger med den innebygde PSD-komposisjonen.

CPU-kompositoren fungerer som referanseimplementasjon

Prosjektet beskriver CPU-kompositoren som referansebanen for eksport og tester; GPU-kompositoren, som bruker wgpu, utfører den samme operasjonsplanen for lerretet. Arkitekturdokumentasjonen oppgir at resultatene sammenlignes med en toleranse på opptil 1/255 for 8-bits utdata, og at CPU/GPU-kontrollen kjøres i CI, blant annet på en programvarebasert grafikkadapter.

GPU-en trengs for et interaktivt lerret, men om maskinvarebanen er tilgjengelig, avhenger av dokumentet og miljøet. Veiledningen sier at dokumenter med flere kanaler og områder som overskrider teksturgrensen, behandles av CPU-kompositoren; lerretet går også over til CPU hvis GPU-enheten går tapt. Dette er konkrete vilkår for å bytte mellom banene, ikke en påstand om lik hastighet på alle enheter.

Det samme prinsippet kan brukes i andre beregningssystemer: Behold en kontrollerbar referanseimplementasjon ved siden av den optimaliserte banen, og kjør begge på identiske inndata. For en database kan det være en enkel tolk ved siden av en optimalisert motor; for mediebehandling kan det være en programvarebane ved siden av maskinvareakselerasjon. Sammenligningen avdekker avvik i resultatene; den blir reproducerbar når inndataene og kriteriet for akseptable forskjeller er fastlagt.

Slik gjør du metoden om til praktiske tester

1. Sett sammen en liten og variert samling. Ta med filer med masker, tekst, grupper, gjennomsiktighet, effekter og fargemoduser. Dokumenter hvor filene kommer fra og hvilke versjoner samlingen består av, slik at senere kjøringer bruker de samme inndataene.
2. Velg referanse og toleranse. For PSD kan resultatet sammenlignes med det innebygde, sammenslåtte bildet. Definer tillatt feilmargin, og test størrelse, fargeprofil og alfakanal separat hvis dette er viktig for programmet ditt.
3. Skill mellom import, lagring og gjengivelse. Separate tester kan kontrollere laganalyse, gjenåpning etter lagring og samsvar mellom bildet og referansen. Da blir det enklere å finne ut hvilket trinn som forårsaket feilen.
4. Kjør de samme tilfellene gjennom ulike bakender. Sammenlign CPU- og GPU-resultater for de samme dokumentene, inkludert tester ved flisegrenser og med effekter. Ta vare på inndataene og den visuelle forskjellen, slik at en regresjon kan gjenskapes.
5. Dokumenter vilkårene for ytelsesmålingene. Oppgi dokumentstørrelse, antall lag, maskinvare og hurtigbuffertilstand. PhotoCraft-dokumentasjonen inneholder kommandoer for enkelttester og sammenligning av kompositorer; målingene som presenteres der, gjelder bestemte konfigurasjoner og scenarioer.

Utviklerveiledningen for PhotoCraft beskriver kommandoer for å teste PSD-samlinger, visuelle avvik og hvordan ulike komposisjonsbaner oppfører seg. Den er et konkret utgangspunkt for å utforske programmets testinfrastruktur; ytelsestallene i dokumentasjonen bør leses sammen med inndataene og maskinvarekonfigurasjonen som er oppgitt der.

Hva PhotoCraft-eksemplet viser

PhotoCraft v0.7.0 samler endringer i selve programmet, mens prosjektdokumentasjonen viser en egen teknisk praksis: referansefiler i PSD-format for å teste komposisjon, og en CPU-implementasjon som GPU-banen sammenlignes med. For utviklere av redigeringsprogrammer, konverterere og andre verktøy for komplekse filer er lærdommen enkel: Test lesing, lagring og visuelt resultat hver for seg, og sammenlign optimaliserte implementasjoner med en referanseversjon ved hjelp av fastlagte inndata. Slik blir kompatibilitet og ytelse egenskaper som kan testes.