PhotoCraft v0.7: Testing PSD Compatibility and Building a Fast Editor

A PSD can open in an editor and still look different: the discrepancy may affect a mask, text, a layer effect, or the stacking order. One way to check the result is to compare the reconstructed composite with the flattened image embedded in the PSD itself. Released on October 11, 2026, PhotoCraft v0.7.0 offers an opportunity to examine this engineering approach through an open-source graphics editor written in Rust.

The release lists changes to brushes, selections, masks, OpenRaster import, and other parts of the editor. For developers, the project’s published documentation is especially interesting: it describes PSD import tests, compositor comparisons, and a file corpus used for reproducible checks.

PSD files contain a reference for comparison

A layered PSD contains a layer structure and a flattened image of the document. PhotoCraft renders the layers, then compares the result with this embedded composite. This test checks how closely the program reproduces the document’s appearance when handling text, adjustments, effects, and other format features.

The PhotoCraft architecture documentation calls this approach a “compositor oracle.” The testing documentation lists three PSD corpora: 256 files created by the team in Photoshop, 170 files from the psd-tools and ag-psd test sets, and a separate psd-tools set of 309 files. The corpora are downloaded at pinned versions and verified with checksums.

Format developers benefit from separating tests according to the question they answer. A structural parse shows whether the document could be read; an open-and-save round-trip test checks whether data was preserved; a composite comparison measures how accurately the visual result was reproduced. PhotoCraft’s documentation lists both byte-stability checks for unchanged files and comparisons against the PSD’s embedded composite.

The CPU compositor serves as a reference implementation

The project describes the CPU compositor as the reference path for exports and tests; the wgpu-based GPU compositor executes the same operation plan for the canvas. The architecture documentation states that results are compared with a tolerance of up to 1/255 for 8-bit output, and that CPU/GPU checks run in CI, including on a software graphics adapter.

The GPU is needed for an interactive canvas, but the availability of the hardware path depends on the document and environment. The guide notes that multichannel documents and areas exceeding the texture limit are processed by the CPU compositor; if the GPU device is lost, the canvas also switches to the CPU. These are specific conditions for switching between paths, not a claim of uniform performance on every device.

The general pattern also applies to other computing systems: keep a testable reference implementation alongside the optimized path and run them on identical inputs. For a database, this could mean a simple interpreter alongside an optimized engine; for media processing, a software path alongside hardware acceleration. Comparison reveals discrepancies, and results become reproducible when inputs and acceptable-difference criteria are fixed.

How to turn the approach into working tests

1. Build a small, varied corpus. Include files with masks, text, groups, transparency, effects, and color modes. Record file origins and corpus versions so subsequent runs use the same inputs.
2. Choose a reference and tolerance. For PSDs, you can compare the result with the embedded flattened composite. Define an acceptable error margin, and check dimensions, color profile, and alpha channel separately if they matter to your application.
3. Separate importing, saving, and rendering. Individual tests can check layer parsing, reopening after saving, and image similarity to the reference. This makes it easier to determine at which stage an error occurred.
4. Run the same cases through different backends. Compare CPU and GPU results on the same documents, including tests at tile boundaries and with effects. Save the input and visual difference so a regression can be reproduced.
5. Record performance measurement conditions. Specify the document size, number of layers, hardware, and cache state. PhotoCraft’s documentation includes commands for individual tests and compositor comparisons; its measurements apply to specific configurations and scenarios.

The PhotoCraft development guide describes commands for checking PSD corpora, visual discrepancies, and the behavior of different compositing paths. It provides a concrete starting point for exploring an editor’s test infrastructure; performance figures in the documentation should be read alongside the inputs and hardware configuration specified there.

What the PhotoCraft example shows

The PhotoCraft v0.7.0 release brings together changes to the editor itself, while the project documentation reveals a separate engineering practice: using reference PSDs to check compositing and a CPU implementation to compare against the GPU path. For developers of editors, converters, and other tools for complex files, the useful takeaway is straightforward: test reading, saving, and visual output separately, and compare accelerated implementations with a reference version using pinned inputs. This turns compatibility and performance into verifiable properties of the program.