Two Rust photo apps in the browser

Same language, different answers

Both apps are Rust from top to bottom. Both draw their interface with egui on a canvas, and each web version is its desktop app compiled to WebAssembly. So the language does not decide much. The apps still differ on storage, threads, graphics and toolchain, and LightPhotos used LightCraft's layout until late September (see challenges with WebAssembly).

Import is the biggest difference

The row in the table that you feel first is the one about your photos. The two apps answer "where are my photos?" in opposite ways.

LightPhotos does not import. Open Folder calls the browser's showDirectoryPicker, you grant access to one folder, and the app reads the files where they are. Nothing is copied. Ratings, edits and thumbnails go into a hidden .lightphotos folder inside the folder you picked (see where your data lives), so you can see them in Finder or Explorer and they move with the folder.

The cost is that this API exists only in Chrome and Edge, and after a reload the browser asks you to grant access again, unless you chose to allow it on every visit.

LightCraft imports. You pick files with the standard file dialog, or drop them on the window. It reads the bytes of each file and writes them into the browser's own file system, the Origin Private File System (OPFS), under a hash of their content. The catalog, presets and settings go there too, or into IndexedDB where OPFS cannot be written. This works in every modern browser, with no permission prompt. A reload opens the same library, and a photo imported twice is stored once.

The cost is a second copy of every photo. The twenty Sony RAW files in this test are 498 MB, so importing this set into an empty library stores a second 498 MB in browser storage. That storage has a quota, it is invisible in Finder or Explorer, and the browser can evict it under storage pressure, so LightCraft asks for persistent storage and warns you when it does not get it. If you clear the site's data, the library goes with it. Your original files are safe, but to get edited photos out, you export them.

LightPhotos reads the folder you choose and saves ratings and edits alongside the originals. It avoids duplicating the photos, but requires Chrome or Edge. LightCraft keeps a separate library in browser storage, which supports file import across more browsers and retains the library after a reload. Clearing site data removes that library and edits you have not exported; the originals on disk remain.

How I measured

I built each app from its current code and served it from a local address. Playwright drove Chrome 154 on an M4 Pro Mac with 48 GB of memory. The window filled a 4K display at its native size, so the page was 3840 by 2072 pixels. The photos were twenty RAW files from a Sony A7 II, 24 megapixels and about 25 MB each. Each run used a new browser profile, so neither app had seen the photos before.

The script takes a screenshot about every 70 ms and keeps each frame that changes. For each key press, I record two times. The first is when the photo area stops changing. The second is when the whole screen stops changing, side panels included. Each number is the median of five runs. For an open from the grid, the script waits until the screen is still for 4 s, because the sharp photo can come late. The method is coarse: 0.07 s is the first frame after the key. So compare the apps with each other, not with a stopwatch.

An earlier version of this post timed only the whole screen, in a 1600 by 1000 window. It gave 0.97 s for the next photo in LightCraft. The frames show that the photo was sharp in the first frame. The time came from the histogram.

The numbers

LightCraft includes a full editing pipeline and its own RAW decoder, but its download is only 0.2 MB larger. Its release builds also include a Japanese font, which I removed for this test. The memory number is for the page's own process. That process holds the main thread, the workers and the LightPhotos decode threads. When the LightCraft grid stops changing, it shows only a few of the RAW thumbnails, because it scrolls to follow the import. LightPhotos shows all 20.

Why the numbers differ

The camera's embedded JPEG is 1616 px wide. Full screen, the photo is about 2700 px wide in both apps, so the JPEG is too small for a sharp photo. Thus both apps develop the sensor data at fit. The colours at fit then come from the same place as the colours at 100%.

Both apps prepare the photos on either side while you look at the current one. LightPhotos develops them on its decode threads. LightCraft decodes them in its Web Workers. So for the next photo, the work is done before you press the key, and both apps show the sharp photo in about 0.1 s. LightCraft shows a preview for about 0.07 s first. Then its histogram changes until about 1.7 s after the key. The photo does not change in that time.

A photo that you open from the grid is not prepared. LightPhotos shows the camera's JPEG at 0.15 s. Then it develops the sensor data and shows the sharp photo at 1.37 s. LightCraft shows a preview at 0.06 s and the sharp photo at 3.6 s. In two of five runs, LightCraft was faster, at 1.25 s. I did not find the cause.

The grid is closer. The LightPhotos decode threads take thumbnails from one shared queue, and the photo on screen gets priority. LightCraft copies all 498 MB into browser storage while it imports. That copy is part of its 2.3 s. It also keeps the library after a reload.

Why LightCraft uses more memory

Each LightCraft worker is a separate copy of the program with its own memory, and WebAssembly memory never shrinks after it grows. The main thread also keeps recently used originals, the 498 MB of RAW files. Four workers plus that come to 2.8 GB. With a photo zoomed to 1:1, it reached 3.4 GB.

Shared memory has a cost too. Each LightPhotos decode thread needs about 300 MB of scratch space for a RAW file, all from one heap with a limit of 4 GB. With ten threads, memory peaked at 3.4 GB. So I limited the browser build to six threads, which keeps the page at 2.0 GB.

Wrapping up

LightPhotos relies on your own folders and shared memory, so it feels quick when you go through a shoot. LightCraft takes on the whole RAW pipeline and a full Lightroom-style feature set, keeps its library in the browser and needs no special server configuration. I look forward to seeing where it goes. Both also run on Mac, Windows and Linux, and that comparison is next.