3dtours
e1707bd9b9
Four asks, one screen: a folder can be given the tiles it is short of, by hand or on the way in; the rescan row says RESCAN...; and the wall of thumbnails scores a frame without the trip to the stage. - Library.tsx + i18n: "RESCAN FROM THE TOP" is "RESCAN..." in both languages. The reading is unchanged — a row's roll is still read from the top, its subfolders included. - engine/library.ts + Library.tsx: the tile of one frame is one function now (`makeThumb`: the store, the backup behind it, then the file's own preview for a RAW or a HEIC and a decode for anything else). The wall's lazy path calls it instead of keeping its own copy of the same branches. - engine/library.ts: `missingThumbs` asks which of a folder's rows no tile was ever drawn for, in one transaction, and `makeThumbs` makes those — a few frames at a time, and giving up when the caller has moved on. - Library.tsx: the folder menu carries MAKE THUMBS, which reads the row's folder and what lies under it; and opening a folder asks for its own frames' tiles by itself, silently, in the background — the branch too when the screen is drawing the branch. A frame that lands after the ask is asked for again, which is why the frame count is a dependency of the effect. - Library.tsx: a wall card carries the same five stars the stage does, under the picture, and rates the frame on the click. The click stops at the star, so scoring a frame is not picking it. Verified in Chrome at 1440x900 against OPFS standing in for the disk, three frames with one of them in a subfolder: opening the folder leaves two tiles (the node's own frames) and MAKE THUMBS takes the roll to three, the frame in the subfolder included; clearing the store and reloading brings the two back on the open; the menu reads RESCAN... and MAKE THUMBS; and the wall's fourth star lights four, writes star 4 to the catalogue row, and takes it back on the second click. The same checks pass on the built bundle at :8090.
RecipesCam
RecipesCam is a camera and photo-editing app built around recipes — reusable
looks that carry a film simulation plus a full set of adjustments. You shoot or
open a photo, dial in a look, and keep it as a recipe you can apply again, share
as a .recipe file, or save to your account.
It ships twice from one repository: a React Native (Expo) app for iOS and
Android, and a self-contained web build under docker/ that runs the same
render pipeline in the browser.
What it does
- Shoot with a recipe applied. Live viewfinder, GPS-tagged captures, and the recipe baked into the saved file.
- Film simulations. Built-in looks — PROVIPES, VELVIPES, CLASSIC CHRIPES, CLASSIC NEGIPES, ASTIPES, ETERNIPES, ACRIPES, B&W HIGH CONTRAST and the LC STREETLIFE pair — each with its own grain and tone curve.
- The full adjustment set. Exposure, contrast, highlights and shadows, saturation, colour temperature, clarity, grain, and an HSL mixer with a colour picker that samples straight off the photo.
- Geometry. Crop to a fixed ratio or free-form, quarter turns, and a straighten ruler, plus printed frames (classic border, retro instant, wall frame portrait/landscape).
- Finishing. Watermark and GPS stamp, EXIF carried through the export, JPEG written with a proper 300 DPI JFIF header.
- On-device upscaling. A Real-ESRGAN pass runs locally when an export asks for more pixels than the source has — no server sees the photo.
- Recipes. Save, favourite, export and import
.recipefiles; the web build keeps them in your account, the phone build also keeps them on device.
The two builds
| Build | Where | Stack |
|---|---|---|
| iOS / Android | repo root | Expo + React Native, @shopify/react-native-skia for the render pipeline, NativeWind for styling |
| Web | docker/ |
Vite + React, CanvasKit (canvaskit-wasm) for the same pipeline, Fastify + SQLite API for accounts and recipes |
The render engine is shared by design: the web build compiles the app's own
src/utils/* and type definitions unchanged, with @shopify/react-native-skia
aliased to a CanvasKit shim (docker/frontend/src/engine/skiaShim.ts). A look
looks the same on both because it is the same code.
Running the web build
cd docker
cp .env.example .env
docker compose up -d --build
# → http://localhost:8090
Photos never leave the browser: grading, framing, watermarking and JPEG
encoding all run in the visitor's tab; the API only stores accounts and recipe
JSON. See docker/README.md for the layout and the proxy setup.
Running the app
npm install
npx expo start # Expo Go / dev client
npx expo run:android # or run:ios for a native build
Repository layout
App.tsx, src/ the Expo app: screens, tool rail, viewfinder, shaders
docker/ the web build (frontend + API + compose file)
frontend/shared/ vendored copies of the app's types and utils
frontend/src/engine/ CanvasKit shim, export engine, super-resolution
docs/ privacy policy
THIRD_PARTY_NOTICES.md licences of the bundled fonts, models and libraries
Licence
See LICENSE and THIRD_PARTY_NOTICES.md.