Een PSD kan in een editor worden geopend en er toch anders uitzien: verschillen kunnen betrekking hebben op een masker, tekst, laageffect of stapelvolgorde. Een manier om het resultaat te controleren is de opnieuw samengestelde afbeelding te vergelijken met de samengevoegde afbeelding die in de PSD zelf is ingebed. De op 11 oktober 2026 verschenen PhotoCraft v0.7.0 biedt aanleiding om deze technische aanpak te bekijken aan de hand van een open grafische editor, geschreven in Rust.

De release vermeldt wijzigingen aan penselen, selecties, maskers, OpenRaster-import en andere onderdelen van de editor. Voor ontwikkelaars is de gepubliceerde projectdocumentatie bijzonder interessant: daarin staan tests voor PSD-import, vergelijkingen van compositors en een bestandsverzameling voor reproduceerbare controles.
PSD bevat een referentie om mee te vergelijken
Een PSD met lagen bevat een lagenstructuur en een samengevoegde afbeelding van het document. PhotoCraft rendert de lagen en vergelijkt het resultaat vervolgens met deze ingebouwde compositie. Zo'n test controleert hoe nauwkeurig het programma de weergave van het document reproduceert bij de verwerking van tekst, aanpassingen, effecten en andere functies van het formaat.
In de architectuurbeschrijving van PhotoCraft wordt deze aanpak een ‘compositor-orakel’ genoemd. De testdocumentatie vermeldt drie PSD-verzamelingen: 256 bestanden die het team in Photoshop heeft gemaakt, 170 bestanden uit de collecties van psd-tools en ag-psd, en een afzonderlijke collectie van psd-tools met 309 bestanden. De verzamelingen worden opgehaald met vastgezette versies en gecontroleerd aan de hand van checksums.
Voor ontwikkelaars van bestandsformaten is het nuttig tests te onderscheiden op basis van de vraag die ze beantwoorden. Een test van de structuur laat zien of het document kon worden gelezen; een test van openen en opslaan of de gegevens behouden zijn gebleven; een vergelijking van de compositie hoe getrouw het visuele resultaat is gereproduceerd. De PhotoCraft-documentatie vermeldt zowel controles op byteconsistentie voor ongewijzigde bestanden als vergelijkingen met de ingebouwde PSD-compositie.
De CPU-compositor is de referentie-implementatie
Het project beschrijft de CPU-compositor als de referentieroute voor export en tests; de GPU-compositor op wgpu voert hetzelfde bewerkingsplan uit voor het canvas. In de architectuurdocumentatie staat dat resultaten worden vergeleken met een tolerantie tot 1/255 voor 8-bits uitvoer, en dat CPU/GPU-controles in CI plaatsvinden, onder meer met een softwarematige grafische adapter.
De GPU is nodig voor een interactief canvas, maar de beschikbaarheid van de hardwarematige route hangt af van het document en de omgeving. Volgens de handleiding worden documenten met meerdere kanalen en gebieden die de textuurlimiet overschrijden door de CPU-compositor verwerkt; als het GPU-apparaat uitvalt, schakelt het canvas eveneens over op de CPU. Dit zijn concrete voorwaarden voor het wisselen tussen routes, geen bewering over één vaste snelheid op elk apparaat.
Dit algemene patroon is ook toepasbaar op andere computersystemen: houd een controleerbare referentie-implementatie naast de geoptimaliseerde route en voer beide uit met dezelfde invoer. Voor een database kan dat een eenvoudige interpreter naast een geoptimaliseerde engine zijn, en voor mediaverwerking een softwarematige route naast hardwareversnelling. Vergelijking brengt verschillen in de resultaten aan het licht; ze is reproduceerbaar wanneer invoer en criterium voor het toegestane verschil zijn vastgelegd.
Zo zet je de aanpak om in werkende tests
- Stel een kleine, gevarieerde verzameling samen. Neem bestanden op met maskers, tekst, groepen, transparantie, effecten en kleurmodi. Leg de herkomst van de bestanden en de versies van de verzameling vast, zodat latere runs dezelfde invoer gebruiken.
- Kies een referentie en een tolerantie. Voor PSD kun je het resultaat vergelijken met de ingebouwde samengevoegde compositie. Bepaal de toegestane afwijking en controleer afzonderlijk afmetingen, kleurprofiel en alfakanaal als die belangrijk zijn voor je toepassing.
- Scheid importeren, opslaan en renderen. Afzonderlijke tests kunnen controleren of lagen correct worden ingelezen, of ze na opslaan opnieuw kunnen worden geopend en of de afbeelding overeenkomt met de referentie. Zo is makkelijker vast te stellen in welke stap een fout is ontstaan.
- Voer dezelfde gevallen uit op verschillende backends. Vergelijk CPU- en GPU-resultaten voor dezelfde documenten, met inbegrip van tests aan tegelgrenzen en met effecten. Bewaar de invoer en het visuele verschil, zodat een regressie reproduceerbaar is.
- Leg de omstandigheden van prestatietests vast. Vermeld de documentgrootte, het aantal lagen, de hardware en de toestand van de cache. De PhotoCraft-documentatie bevat opdrachten voor afzonderlijke tests en vergelijkingen van compositors; de metingen daarin gelden voor specifieke configuraties en scenario's.
De ontwikkelaarshandleiding van PhotoCraft beschrijft opdrachten voor het controleren van PSD-verzamelingen, visuele verschillen en het gedrag van verschillende compositieroutes. Je kunt die gebruiken als concreet vertrekpunt om de testinfrastructuur van een editor te onderzoeken; prestatiecijfers uit de documentatie moeten worden gelezen in samenhang met de daar vermelde invoer en hardwareconfiguratie.
Wat het voorbeeld van PhotoCraft laat zien
De release PhotoCraft v0.7.0 brengt wijzigingen aan de editor zelf samen, terwijl de projectdocumentatie een afzonderlijke technische praktijk belicht: referentie-PSD-bestanden voor het controleren van composities en een CPU-implementatie waarmee de GPU-route wordt vergeleken. Voor ontwikkelaars van editors, converters en andere tools voor complexe bestanden is de nuttige les eenvoudig: test het lezen, opslaan en visuele resultaat afzonderlijk, en vergelijk versnelde implementaties met een referentieversie aan de hand van vastgelegde invoer. Zo worden compatibiliteit en prestaties eigenschappen van het programma die daadwerkelijk te controleren zijn.