Pimp My IDE / Garage logBack to dispatches
Proof and review04 Oct 20268 min read
Garage log 196 / creative tool parity

Alpha parity dyno

ArtCraft's new creative apps are real code with real releases. They are also early alpha. That combination deserves a test plan, not a victory lap or a dismissal.

The practical call: pin one release, one document, one edit, and one reference application. Then measure what survives the round trip.
Artifact load cellEarly alpha
ExistsOpensEditsRound trips
PhotoCraft v0.1.1 has a published Linux AppImage and checksum file. That proves a retrievable release. It does not prove Photoshop parity.
What landed

The artifact is real. The claim is larger.

PhotoCraft is the strongest public part of a proposed seven-app creative suite. Its repository labels the software early alpha and publishes builds for Linux, macOS, Windows, and the web.

The ArtCraft apps page lists seven Rust projects for image editing, vector illustration, video, raw photography, PDF work, motion graphics, and page layout. The same page marks PhotoCraft as early alpha and the other six apps as in development. That status split matters. A suite-shaped website is not one suite-shaped release.

PhotoCraft has a concrete handle. Release v0.1.1 includes platform packages, an x86-64 Linux AppImage, and a SHA-256 checksum file. We downloaded that AppImage and verified its checksum. The AppImage runtime answered its own version probe. The application then reached its window initialization and stopped because this server has no Wayland or X display. That is a narrow artifact smoke check, not a functional test.

Alpha is useful when the missing proof stays visible.

Compatibility has separate jobs

The project says its PSD parser round-trips 134 of 135 corpus files byte for byte. It also describes pixel comparisons against Photoshop's merged image and a command registry used by the user interface, command-line tool, control channel, and Model Context Protocol server. Those are project-published test claims. They are useful leads for an independent test, not a substitute for one.

Adobe's own Photoshop API documents separate operations for documents, layers, transforms, and saves. That is a reminder that file compatibility is larger than opening a container. A useful test has to preserve the document tree, the editable state, the rendered pixels, and the expected workflow behavior.

Use the alpha label as a routing signal

In the Hacker News thread, a project representative said the apps are "not anywhere close to ready" and called them "super early alpha." The comment also states an ambition to reach full parity. Read those sentences together. The release is ready for testing and contribution. It is not ready for a blanket replacement verdict.

A fair evaluation picks the job first. If you need a Linux image editor for a disposable copy of one layered file, test that job. If you need a studio migration, test the fonts, color profiles, blend modes, smart objects, automation, plug-ins, exports, and handoff to collaborators that your studio uses. "Photoshop compatible" is the start of that matrix.

01 / ARTIFACT

Can you retrieve it?

Pin the release asset, checksum, operating system, architecture, and license before judging behavior.

02 / DOCUMENT

What opens?

Use a named fixture with layers, profiles, fonts, masks, effects, and unsupported parts recorded.

03 / EDIT

What changes?

Apply one exact edit. Compare the live document structure and rendered result against the reference application.

04 / ROUND TRIP

What comes back?

Save, reopen in both applications, compare structure and pixels, then record every lost or changed property.

Interactive makeover / parity load bank

Build one fair test

A feature checklist rewards breadth. This load bank asks which claim you need to test, then keeps artifact, fixture, oracle, and replay requirements separate.

Choose the claim under test
Select requirements for the test plan

This page builds a test template. It does not open a PSD, run Photoshop, or prove parity. Never use the only copy of a production document as an alpha fixture.

Physical state / four independent loads

Do not average away a gap

Each selected load adds a requirement. A complete structure still needs real files, outputs, and review.

1 of 4 requirements selectedTest structure started
Artifact
Fixture
Oracle
Replay
1 requirement selected.The test structure still needs the fixture, reference oracle, and replay record.
Shop notes

Make the fixture expensive enough

A flat poster can hide every gap that matters to a layered production file. Pick a fixture that contains the parts your real handoff depends on.

Record the source hash before opening the file. Inventory layers, masks, profiles, fonts, effects, linked objects, guides, metadata, and expected dimensions. Make one edit that touches the behavior under review. Save to a new file.

Reopen the result in the candidate app and the reference app. Compare the document tree and rendered pixels separately. A byte change can be harmless. A byte-identical round trip can also preserve an unsupported block without proving that the editor understood it. Keep both results.

The migration decision belongs to the workload owner. A passing fixture approves that fixture and test path. It does not turn an early alpha into a finished replacement for every creative workflow.

Sources read

Open the receipts

The project sources establish what exists and what the maintainers claim. Adobe's documentation helps define the reference operations. The discussion records the project's own readiness boundary.

Garage boundary: we downloaded photocraft-0.1.1-linux-x86_64.AppImage, verified it against the publisher's SHA256SUMS.txt, and ran its AppImage runtime probe. The application reached window initialization but could not open because the test host has no graphical display. We did not inspect the graphical interface, open a PSD, run the claimed corpus, compare Photoshop output, or test the other six apps. The project publishes its own parity numbers. We did not independently reproduce them.