112 Commits

Author	SHA1	Message	Date
3dtours	88cff5ca87	web: draw the dust brush into strokes, size it by the wheel, uncap the list ... A speck of dust is small and there is never only one, so the brush had three things wrong with it: the list stopped at sixteen and the seventeenth repair pushed the first one out of the shader, the size was a choice of three buttons, and one gesture laid exactly one spot — a scratch across a hundred pixels was a dozen clicks. The cap is gone rather than raised. SkSL indexes a uniform array by a constant only (the trick the tone curve's mixer already uses), so HEAL_SKSL carried sixteen unrolled blocks and the list was trimmed to fit them. The shader is now built for the count it is handed — healSkSL(n), with healUniforms returning (n * 2 + 1) * 4 floats, the same declaration order for any n — and the renderer caches one compiled effect per count (exportEngine's healEffectFor). readHeal no longer slices and the app appends whatever a gesture reported. No repair is dropped to make room for a later one: the speck healed first is the speck that stays healed. The wheel is the size now. wheelHealR multiplies the radius by exp(-deltaY * 0.0015), so a trackpad's small deltas and a mouse's 100px notch are the same gesture at two speeds, bounded at 0.3% and 25% of the photo's width — below the first a spot is finer than the pixels it is drawn on, past the second it would borrow its patch from off the frame. S, M and L are gone, and because there is nothing left to point at, the HEAL chip's own readout is the size: the number the brush is set to is the number on the chip. The pointer paints. Down starts a stroke, move adds a point every HEAL_SPACING (0.6) radii of travel, and up turns the whole run into spots in one report — so a stroke is one undo step however long it was, and the trail drawn while the pointer is down is a preview of that run, in the accent, cleared the moment the spots land. The part of a stroke that leaves the photo lays nothing down, and the pointer is captured so a stroke that runs past the edge ends where the pointer does rather than leaving a spot hanging at the frame. The wheel had to be stopped, not merely claimed. The heal layer is a child of the stage, and the stage has its own wheel listener that zooms the photo, so a wheel over the brush grew the brush AND zoomed the view: the probe caught it as a cursor circle 15% wider than the readout it was drawing. The layer's listener (native, because React's own onWheel is passive) now stops propagation — while the brush is up, the wheel sizes the brush and nothing else. One number moved that none of the three asks mentioned, and it is what the probe's remaining failure was about. The feather band was 45% of the radius, and that band is the only place the pixels being repaired are mixed back into the patch, so with the default 6px brush it left a ring of the speck's own edge one pixel inside the circle (115 in a field of 150) — which the preview's own JPEG then rang around, reading 177 a pixel off the centre of a repair that should be flat. Narrowing the band to the outer 15% copies the patch over everything inside 0.85r: sub-pixel at the default brush, still a soft edge at a big one, and that pixel now reads 151. Verified: heal-skia-lab.cjs (scratchpad, Node + the full CanvasKit build) — 27 PASS, 0 FAIL: the shader for a count compiles through RuntimeEffect.Make and its uniform block is (n * 2 + 1) * 4 floats (n=1 -> 12, n=40 -> 324); a single spot copies the donor exactly and leaves the rest of the frame untouched, pixel for pixel; forty spots are carried whole with the first and the last both drawn; three spots in one run each borrow their own patch; readHeal clamps and drops zero-radius spots and no longer trims the list; wheelHealR grows, shrinks and clamps at both ends (0.3% and 25%); the search finds a patch and still refuses a brush that covers the frame. heal-probe.cjs (scratchpad, the rebuilt app at http://localhost:8090) — 48 PASS, 0 FAIL, no page errors: the circle under the cursor is exactly the size the chip reads, before and after a wheel, and the wheel grows, shrinks, stops at 25% and at 0.3% and returns to where it started; there are no size chips left; one click is one spot, the speck reads 151 at its centre and its four neighbours are field too; a drag shows at least three trail circles, lays exactly that many spots, clears the trail on release, and UNDO takes the whole stroke back at once while leaving the repair made before it alone; REDO repaints it; a bigger brush takes a ten-pixel blob; twenty-five spots are carried with the first healed speck still first and still healed; every speck is gone after a reload; CLEAR brings them all back and lays no spot of its own; the chip goes amber only while spots are on the photo. Regressions against the rebuilt app, 0 fail: landing-test.cjs 172, pro-gate-test.cjs 27, award-column-probe.cjs 18, otp-code-probe.cjs 10, tone-curve-probe.cjs 42; backend npm test 180 passed, 0 failed. web tsc --noEmit clean. ponytail: a stroke's repairs land when the pointer comes up, not under it as they are painted — a live repair would mean recompiling the pass and re-cutting the preview per point mid-gesture; the trail is what the pointer has drawn, and it is drawn in the accent so the difference reads. The list is uncapped, so a runaway stroke pays one shader compile per distinct count it reaches, cached for the rest of the session: a ceiling would have to come back with the trim. The search still has no colour-matching term, so the donor is chosen by resemblance alone, and the spots still live in the rendered photo's coordinates, so re-cropping or re-rotating after healing slides them.	2026-09-23 21:08:09 +07:00
3dtours	3ee0137d0d	web: repair dust with a brush that borrows a patch of the same photo ... A sensor speck is not a filter: it is a small lie in one place, and every slider in the panel is global, so there was no way to say "here, and only here". The FX row now has a HEAL chip. Arming it turns the pointer into a circle you can size S, M or L, and every click on a speck covers it with a patch of skin borrowed from a few radii away — the repaired sites persist in the recipe like any other edit, and UNDO takes them back one click at a time. The spot is stored in the rendered photo's fractions, not in the preview's pixels: x, y and a radius that is a fraction of the photo's WIDTH, so the circle stays round on a tall or a square frame and the same recipe heals at preview resolution and at export resolution without a second code path. `readHeal` is the only door in, and it validates, clamps and drops the spots with no radius before anything downstream sees them. The source patch is searched for, not asked for. `findHealSource` walks eight directions at three distances — 2.6r, 4.2r, 6.5r — and each candidate's mirror through the spot as well, scores every one with a nine-tap comparison of the neighbourhood, and hands back the first that actually resembles the ring around the speck. When nothing fits — a brush wide enough to swallow the whole frame — it returns null and the click is refused rather than smearing a wrong colour over it. There is no colour-matching model here and no second draggable source circle: Lightroom lets you place the donor, this finds one. The pass runs last on the photo's own pixels. It is inserted after the grade, the curve and the grain and before the frame, so the patch it pastes is copied from pixels that have already been graded and grained — it matches by construction, with no second copy of the pipeline to keep in step — and the frame, the card and the watermarks are drawn over the result, so healing can never erase the furniture of the render. The brush is a feathered circle at 0.55r, which is what keeps a repair from reading as a sticker. SkSL indexes a uniform array by a constant only, so the shader is the block unrolled HEAL_MAX = 16 times, the same trick the tone curve's mixer already uses. Sixteen is the ceiling and the oldest spot falls out when the seventeenth arrives. CLEAR drops the whole field — turning the chip off keeps the repairs, which is the distinction between disarming the brush and undoing the work. Verified: heal-skia-lab.cjs (scratchpad, Node + the full CanvasKit build) — 15 PASS, 0 FAIL: HEAL_SKSL compiles through RuntimeEffect.Make and makeShaderWithChildren; the uniform block is 132 floats in declaration order (16 spots + 16 sources + size, w/h/feather); a dust speck pinned on the canvas comes back as the borrowed patch while the rest of the frame is untouched, pixel for pixel; readHeal clamps, drops zero-radius spots and caps the list at 16; the search finds a valid donor and returns null for a brush that covers everything. heal-probe.cjs (scratchpad, the rebuilt app at http://localhost:8090) — 29 PASS, 0 FAIL, no page errors: the cursor circle is 2 x 0.012 x width and centred on the pointer, L is visibly bigger, S and L are exclusive; one click is one spot; a speck at 151 reads 154 at its centre after the heal and the photo's other specks and empty skin are unchanged; the spot and its borrowed source are both drawn; the chip goes amber; CLEAR appears and restores everything; UNDO (the TopBar button) brings the dust back and REDO heals it again; three specks and one L-sized blob all go; the repairs survive a reload. Regressions against the rebuilt app, 0 fail: landing-test.cjs 172, pro-gate-test.cjs 27, award-column-probe.cjs 18, otp-code-probe.cjs 10, tone-curve-probe.cjs 42; backend npm test 180 passed, 0 failed. web tsc --noEmit clean. ponytail: spots live in the rendered photo's coordinates, so re-cropping or re-rotating after healing slides them — re-heal or CLEAR when that matters; a coordinate space pinned to the sensor would need the crop and rotation to carry the spots through. No live brush-size gesture and no colour-matching term: the donor is chosen by resemblance alone, add a colour term if skin tones ever mismatch. The list is capped at 16 with oldest-out rather than refusing the seventeenth click.	2026-09-23 20:51:41 +07:00
3dtours	b24bd78ddd	web: draw the picture's own distribution behind the tone curve, and let the card be dragged ... Setting a point on the curve was guesswork: the graph showed the mapping but nothing about the picture it was mapping, so you placed a point where the tones "probably" were. The graph now draws the picture's own histogram behind the grid, and the panel can be dragged off the photo it is editing — the two halves of the same complaint, that the card was describing a picture you could not look at while you used it. The histogram is not a second measurement. `ToneCurvePanel` takes the same `previewUrl` the stage already renders and reads it through `readHistogram`, the function the HISTOGRAM overlay beside it uses: one 320px sample, luminance bins on the RGB tab and the channel's own bins on an R, G or B tab, so the shape follows the tab the way the line does. The bins become one filled path in the graph's own square, scaled to its own tallest bucket and closed along the floor, and it is the SVG's first child — grid and curve draw over it, so the graph reads as curve on distribution rather than two lines crossing. Nothing new is rendered, sampled or cached: the panel reads the frame that is already there. It is read from the render, which is post-curve, so the band shifts as the curve moves. That is Lightroom's behaviour, not an accident, and it is the honest one: the point of the picture is what you are looking at. A percentile or log scale would show a shadow-heavy frame better than a linear max does, and the overlay beside it does not have one either, so the two agree. The drag is the panel's own head. `pos` is the card's position in the layer's coordinates (null until first moved), and the first position is materialised from `offsetLeft/offsetTop`, which is exactly the CSS bottom-left the card sits at before anyone touches it — so the default layout costs no code and the card carries no second positioning system. It is bounded by the STAGE, not the photo: the card may sit off the photo, that is the point of moving it, but never off the canvas the stage clips at 8px. Window `resize` and a `ResizeObserver` on the stage re-clamp an existing position, because the stage can shrink under a parked card and `overflow: hidden` would hide it with no way to reach it. One real bug, found by the probe rather than by reading: with the head as the handle, `setPointerCapture` retargets the click that follows, so the close button in that same head never fired — pressing it started a drag and swallowed the click. `panStart` now returns early when the pointer went down on a button. The pre-existing `Histogram` overlay carries the same latent pattern; it has no interactive children in its chrome, so it was left alone. Verified: tone-curve-probe.cjs (extended, scratchpad) — the rebuilt app at http://localhost:8090, 42 PASS, 0 FAIL, no page errors. New checks: the graph draws the picture's own distribution and it is the graph's first child (`curve-hist`); the drawn band matches a histogram binned independently in the page (256 buckets, worst deviation 0.00px); the distribution piles where the curve put the tones (peak 128/255 after the black lift, against 9-246 before it); the card is dragged by its head (729,280 -> 689,190, the exact delta); the drag bends no curve and drops no point; the card cannot be dragged out of the stage (clamped to stage bounds); it is pulled back in when the viewport shrinks to 900x640 (card 636,239 240x291 inside stage 269,109 615x429); the close button still takes the graph off the photo. tone-curve-math.cjs — unchanged, 11/11. Regressions against the rebuilt app, 0 fail: landing-test.cjs 172, pro-gate-test.cjs 27, award-column-probe.cjs 18, otp-code-probe.cjs 10; backend npm test 180 passed, 0 failed. web tsc --noEmit clean. ponytail: the histogram is read from the render, so it is post-curve and the band moves with the curve; read it pre-curve by exposing pass 3e's input if the feedback ever misleads. The card's position is component state, so it resets to bottom-left when the panel closes — persisting it across a close is a key on the recipe, add it when someone asks for the card to stay put. Percentile and log scaling are not implemented: linear max, the same as the overlay beside it.	2026-09-23 20:18:46 +07:00
3dtours	e021f7d1ff	web: prove an address with the six digits the letter carries ... Signing up mailed a link and nothing else, so a visitor who signed up on one device and read the mail on another had to leave the page the studio was open on, or give up and stay a guest. The letter now carries six digits as well, and the verify dialog — the face a fresh signup already lands on — takes them. Backend, one row is both proofs. `createEmailVerification` mints the token as it did and a `randomInt(0, 1_000_000)` code padded to six, and returns `{ token, code }`; `sendVerification` passes both to the mailer, which puts the code first and the link second. The code's clock is `created_at + CODE_TTL_S` (15 minutes) and the link keeps the row's own 24-hour `expires_at`: two clocks over one row, so the code needs no expiry column of its own. That row's `code` is NULL for anything minted before this commit, a value no typed guess can match, so an in-flight link from the old mail still works and its owner simply has no code to type. `db.ts` adds both columns with `PRAGMA table_info` + `ALTER TABLE` rather than a rebuild, and sets `attempts` to 0. `verifyEmailCode(userId, code)` answers 'ok' | 'bad' | 'stale' | 'locked', and the shape of the answer is the point. 'stale' is both "no live code" and "too old", so the caller learns nothing about which; 'locked' is the spent-attempts state, which only a fresh letter leaves. The attempt is counted BEFORE the comparison is trusted, so an interrupted request cannot hand back a guess nobody paid for; five (MAX_CODE_ATTEMPTS) is the cap, which is what keeps a six-digit secret from being walked through at a hundred requests a second. The comparison itself is `timingSafeEqual` behind a length check, the same pair the password path uses. On success the row is deleted and `email_verified` set, so the same row spends the link with the code — one proof, one use. The route is `POST /api/auth/verify-code`, a POST and not a GET like the link because a code in a query string lands in every proxy log on the way. It reads `auth`, not `requirePro`: the whole point of it is the account that has not passed the gate yet. Input must be exactly six digits before anything else happens, so the counter only ever counts real guesses; a wrong or stale code is 400, a locked one 429 with `retry-after: 900`, and an already-verified caller gets 200 without touching the row. No limiter of its own: the cap lives with the secret on the row, and a fresh code costs one of the three resends an hour, so five guesses per code is the budget either way. On the web side `api.verifyCode` posts the code, and the dialog's verify face swaps its resend button for a code box plus a smaller resend beside it: the box is `inputMode="numeric"`, `autoComplete="one-time-code"`, `maxLength 6`, and strips non-digits as they are typed, so the number pad comes up on a phone and nothing can paste a password into it. The submit button is disabled until six digits are there. The two answers a visitor can actually act on get sentences of their own (`auth.codeBad`, `auth.codeLocked`); everything else is shown as it comes. The link path is untouched and still works, and the dialog keeps its "Tôi đã xác thực xong" escape in no place at all — it verified nothing, so closing the dialog and asking again covers the same ground. The comment in `docker/.env.example` now says the letter carries both, since a deployment without a relay writes both to the api log. Verified: backend `npm test` — 180 passed, 0 failed. The new section in security.mjs drives the route end to end against the source: signup leaves a six-digit code beside the link, a wrong code verifies nothing and leaves the account unproven, a five-digit body is refused, a signed-out caller cannot type one, the mailed code verifies, spending it spends the link, five wrong guesses lock the code out and the right code then does not help, a resent letter hands out a fresh code that is not locked out by the old guesses, and a code aged past its quarter hour is refused. otp-code-probe.cjs (scratchpad) — 10 PASS, 0 FAIL on http://localhost:8090 against the rebuilt app and api, no page errors: a fresh signup lands on the verify face with the box ready, a wrong code says so and the account stays a guest, the mailed code unlocks PRO, and a proven address is not asked again on the next login. Regressions, 0 fail: landing-test.cjs 172, pro-gate-test.cjs 27, award-column-probe.cjs 18, tone-curve-probe.cjs 33. web tsc --noEmit clean. ponytail: the code rides `created_at` rather than an `expires_at` of its own, so the link's 24 hours and the code's 15 minutes are one column read twice; the day the two need to drift apart independently, the column is the thing to split. The route carries no per-IP limiter, only the per-row cap — a stranger can burn one account's five guesses, which costs that owner a resend, and a limiter keyed on the address would be the next thing to add if that turns out to be cheap for an attacker. The code is not usable from another browser: it verifies the session that asked for it, which is the behaviour the request asked for and not a gap.	2026-09-23 20:08:08 +07:00
3dtours	56d4b9df67	web: give LIGHT a tone curve, edited on the graph drawn over the photo ... The LIGHT rail was sliders only, so the one control that describes a tone mapping rather than a scalar had nowhere to live. It now has a TONE CURVE chip; pressing it puts a curve graph on the photo itself — four channels, RGB plus R, G and B, exactly the shape Lightroom's point curve has — and dragging a point bends the picture under it while you drag. A recipe carries the curve as `adjustments.toneCurve`, an optional map from channel to point list, `Partial<Record<'rgb'|'r'|'g'|'b', [number, number][]>>`. The field is optional and the API stores the recipe JSON opaquely, so every recipe and session written before this commit loads unchanged and simply has no curve; nothing on the API or in the database moved. The renderer never sees the points. `shared/utils/toneCurve.ts` turns them into a 256-entry table per channel and the shader looks the table up in a 256x1 texture: SkSL indexes uniform arrays by constant only, so a per-pixel lookup has to come from a texture, and a table is the cheaper shape anyway — one `lut.eval(vec2(v * 255 + 0.5, 0.5))` per channel. The interpolation between points is a monotone cubic (Fritsch–Carlson) rather than a natural spline, because a spline overshoots between two close points and that overshoot is the classic tone-curve tell, a bright halo beside a lifted shadow; a monotone cubic through the points bends through them and never turns back on itself. The table is built per channel and then composited through the master, the order the graph draws it in, so an R point in the shadows survives an RGB contrast S and both land where the lines say. Render passes: the curve rides the existing `renderPhoto`, as pass 3e, last — after the stock, the matrix, the mixer and the seasonal grade, so a point placed on the graph is the last word on that pixel. Preview and export both call `renderPhoto`, so the two agree by construction rather than by two matching implementations. The pass wraps whatever shader the pipeline had built (`paintShader ?? imageShaderOf()`) as a child of the curve shader, and counts towards `graded` for the same reason the tone shader does: the curve reads the matrix's output, so when there is a matrix it has to be in the pixels the curve samples. Turning the curve on costs one extra render pass and nothing else; off, `curveIsActive` is false and the pass is not built at all. That pass is also where this spent its time being invisible. The curve data reached the recipe and the pixels did not move: `Skia.Image.MakeImage` does not exist in the shim, so the call threw a TypeError inside the render, the preview effect's catch swallowed it into `setError('err.generic')`, and the chip, the graph and the recipe all looked healthy while the canvas kept the old frame. The fix is in `skiaShim.ts`: CanvasKit keeps that factory top-level (`Skia.MakeImage`) and only puts the encoded and lazy ones under `Image.`, and its ImageInfo insists on an explicit `colorSpace` where RN Skia's does not — everything this pipeline builds is sRGB, so the shim fills it in and the call site keeps RN Skia's shape. Reproduced in Node first (`curve-skia-lab.cjs`, scratchpad): the shim's call throws, the translated one returns a 256x1 image. `ToneCurvePanel.tsx` is the graph: a 224px SVG over the photo's layout box, no zoom transform, grid plus a dashed diagonal, the composite drawn as a ghost behind a channel line so a channel edit is still visible against the other three. Ends are pinned to x 0 and 1, a point cannot be dragged past its neighbours (2% of the axis is the closest they may sit) and cannot be dragged out of the square, so the graph can never describe a curve the renderer cannot apply. One pointerdown grabs the nearest point inside 11px or adds one on the line under the cursor and keeps dragging, so a click is a point and a drag is a bend. Deleting a point is the graph's own double-click, not the circle's, and it has to be: grabbing a point takes pointer capture, so the click that follows is delivered to the SVG rather than the circle under the cursor. RESET clears the whole graph, all four channels, and hands back an empty object that `App.tsx` maps to `undefined` so the recipe drops the field rather than keeping a `toneCurve: {}` — the field's presence is what "this picture has a curve" means, and an empty map that means the same as no map is a state two pieces of code would eventually disagree about. One undo step per visit to the graph, the rule the ruler and the watermark box already ride: a drag is one edit, not one per pointer move. No new i18n keys: the chip and the panel labels are literal uppercase, the same as EXPOSURE and STRAIGHTEN beside them. Not PRO-gated — the curve is a LIGHT control like the rest of the tab. Verified: tone-curve-probe.cjs (new, scratchpad) — a 256x256 greyscale ramp uploaded to http://localhost:8090, pixels read back off the built app. 33 PASS, 0 FAIL, no page errors. The ramp is a ramp before (9..246), a flat curve is two points and no pass, the graph is drawn on the photo (graph 729,280 240x291 against photo 719,325 256x256), every stop of the ramp lands on the drawn curve (worst deviation 1), black lifts to 132 while white holds 246 -> 252, a point dragged up bends the line itself (M0.00 112.00 L3.50 110.2...), the R tab takes the graph over while the composite stays visible behind it and R drives red at black to 255 with G and B still on the composite (133,132 against 132), the recipe carries toneCurve, it survives a reload (254 -> 254, chip still amber), a click adds a point and a double-click removes it again, RESET returns the ramp to its start (worst 0) and drops the field, and close takes the graph off the photo. tone-curve-math.cjs (new, scratchpad) — the panel's and the table's own arithmetic, 11/11: the ends pin and sort, a dragged point lifts where the graph says, a steeper segment never turns back on itself, a channel curve runs before the composite, a click lands on the line, two points cannot share a spot, an end cannot leave the axis, and the two ends survive a delete where a middle point does not. Regressions against the rebuilt app, 0 fail: landing-test.cjs 172, pro-gate-test.cjs 27, award-column-probe.cjs 18, otp-code-probe.cjs 10. web tsc --noEmit clean. ponytail: the graph is anchored over the photo, not draggable — it sits at the photo's own layout box the way the crop frame and the straighten ruler do, and the one time it would want to move it is when the photo under it is small, at which point a token drag offset is cheaper than the second positioning system. Parametric curves (Lightroom's shadows/highlights/darks/lights) are not here: the point curve is the one the request asked for, and a parametric curve is a second graph, not a second line on this one — add it as another channel row when someone asks. The LUT is a texture rather than Skia's table colour filter because CanvasKit 0.42 has no ColorFilter.MakeTable. The panel's graph size and hit radius are literals, since exactly one graph exists.	2026-09-23 20:07:51 +07:00
3dtours	cd9dd28adc	web: widen the award column and bring it in beside the copy ... The award card was a 340px column with a 46px gap to the copy, which left the photograph the whole point of the card small and the two halves of the hero visibly apart rather than one composition. The column is now 440px and the gap 24px, so the card is a third again as wide and sits closer to the headline. Measured on the built app at 1280px: .lp-award 440px wide (was 340), and the photo box inside it 410px (was 310) — 440 less the 1px border and 14px padding on each side. At 4:5 the image goes 387.5px tall to 512.5px. The copy's right edge is now 824 against the card's left edge 848, where before it was 902 against 948: the same 24px of air between them, but the copy's right edge moved 78px left and the card 100px left, so the hero reaches further across and the extra width is photograph rather than margin. The stacking breakpoint below 980px carried the same 340px cap, which would have made the card narrower than the column it replaces; raised to 440px to match. Measured at 900px: the card stacks under the copy at 440px wide. Verified: award-column-probe.cjs (scratchpad) — 18/18 on http://localhost:8090, with the width check now 440 and the geometry line reading copy.r=824 card.l=848. landing-test.cjs clean, lp-arrows-test.cjs 33/33, landing-rating-test.cjs 21/21, landing-photo-guard-test.cjs 21/21 — 0 fail against the rebuilt app. web tsc --noEmit clean. Dark and light themes both eyeballed on the built app (award-hero-dark.png, award-hero-light.png). ponytail: the width is a literal in two places — the grid column and the 980px cap — rather than a custom property, because the two are the same value today and a token would need the media query to read it too; when a third width shows up, lift both to --lp-award-w. The light-theme box-shadow is still the dark card's rgba(0,0,0,0.35); widening the card makes it no more or less wrong, so it is left as it was.	2026-09-23 18:27:05 +07:00
3dtours	3f5d2cd017	web: give the landing hero a column of the day's best-rated recipes ... The hero was a single block of copy with nothing beside it, so a visitor landing on the page saw no photograph at all until they scrolled. It now splits into copy + an award card: the highest-rated photos of the current window, one frame per photo, each labelled for the window it came from. The frame set is the day's top-rated first, then the week's, both deduped by photo id, so a photo that is both this day's and this week's best is drawn once and keeps the day's label — that is the tighter of the two windows and the more specific claim. Measured on the live data (2026-09-23 UTC, week = ISO Monday 2026-09-21): GET /api/highlights came back with day [] and week a full five frames (ids 12,13,51,50,3, every one avg 5, n 1). The day window is empty simply because no rating had landed since 00:00 UTC, and an empty day window must not empty the column — hence the union rather than a fallback: whatever each window has, merged, deduped. Frames change the way the film strip already does, so the card reuses that machinery rather than inventing a second one: the same .lp-arrow dots and the same FrameArrows component, which already renders nothing under two frames. Under two frames the card also keeps still — no arrows and no timer, because a single frame has nothing to advance to and a timer that swaps a frame for itself is just a repaint. Five seconds a frame, one second of crossfade: all frames are stacked in the same box and the active one is the only one at opacity 1, each transitioning its own opacity over 1s, so the outgoing frame fades out over the same second the incoming one fades in and the box never flashes empty. Measured in the built app: mid-step opacities 0.32, 0.68, 0.00, 0.00, 0.00 at the halfway point of a step, and transitionDuration exactly 1s on every slide. Stepping by hand restarts that clock instead of letting the old 5s fire on top of the new frame — an arrow step to 2 then waited 4.2s still sat on that frame, where without the restart it would have moved on at 5s from the previous frame's start. The rating is shown on the frame because it is the whole reason the frame is there: avg to one decimal, plus the vote count as "1 vote"/"N votes" — one decent vote and one outstanding vote are not the same window, and the reader can tell them apart at a glance. Score is mono, bottom-left, over a text shadow. Backend side this is one query and one route. topRatedPhotos(since, limit) joins ratings to photos on CAST(substr(ratings.key, 7) AS INTEGER), since ratings keys are the strings "photo:<id>"; it filters ratings.key LIKE 'photo:%' so a look: vote can never award a frame — there is no look to show — and photos.consent = 1, so a photo pulled from public display is pulled from the awards with it. Ordering is avg DESC, n DESC, at DESC, id DESC: best average, then the better-supported average when averages tie, then the freshest, then id only to make the order total and the frame set stable between requests. avg comes back rounded to 2dp. GET /api/highlights computes the two windows in UTC — midnight, and ISO Monday midnight via midnight - ((getUTCDay()+6)%7)*86400000 — and returns { highlights: { day, week } }. HIGHLIGHT_LIMIT is 5. The column is 340px on the right of the copy, stacking under it below 980px. Measured on the built app at 1280px: copy ends at 902, card starts at 948, same hero row, card exactly 340px wide, five slides for five frames, label "Recipe of the week", score "5.0★1 vote", the two arrows the only .lp-arrow inside .lp-award, meta #CLASSIC_VIVIDIPES. At 900px the card sits under the copy. With the window forced to one frame the card draws 0 arrows and 1 slide; with both windows empty there is no .lp-award and the hero is not split at all, so an unrated install looks exactly as it did before. Verified: award-column-probe.cjs (new, scratchpad) — geometry, arrows, crossfade opacities, the 5s auto step, the manual step's clock restart, the one-frame and no-frame windows. 18/18 on http://localhost:8090. backend npm test — 166 passed, 0 failed, with four new checks in the ratings section: a vote lands in today's and this week's window, a look: subject is never an award, and a photo drops off the awards once deleted. The ratings and photos suites cover the joins the new query leans on. landing-test.cjs, lp-arrows-test.cjs 33/33, landing-rating-test.cjs 21/21, landing-photo-guard-test.cjs 21/21 — 0 fail against the built app. web tsc --noEmit clean. Dark and light themes both eyeballed on the built app (award-hero-dark.png, award-hero-light.png). ponytail: the card re-fetches on the page's own reload() rather than polling, so a rating cast while the tab sits open will not surface until the next reload; the awards are a landing-page flourish, not a live feed — when they need to be live, poll the same route on the timer the frames already run. The card's box-shadow is the dark card's, one rgba(0,0,0,0.35), and reads heavy on the light theme next to .lp-recipe-card's light-specific shadow; left alone rather than adding a token for one property.	2026-09-23 18:17:50 +07:00
3dtours	81ed53cf78	web: anchor the watermark box to the photo's layout box, not its rect ... Two zoom-only defects in the FRAME watermark boxes, both of them units mistakes between what the stage measures and what the engine draws. measure() read the box off img.getBoundingClientRect(). Zoom is a TRANSFORM on the photo, and every layer above it (wm, crop, pick, compare, straighten) carries that same transform itself, so a rect read off the transformed element comes back already scaled and is then scaled again by the layer. It only shows once measure() runs while the stage is zoomed, which is exactly what the zoom itself causes: onStageZoom re-cuts the preview copy, the new src fires onLoad, and measure() re-runs on the transformed photo. Measured on the built app (a 2560x1706 upload, a 955px stage, four wheel notches -> 1.749x): the layer came out at -651,-796 2921x1947 against the photo's own 43,-241 1670x1113 — the zoom printed twice — with the box at 809,951 while the mark sits at 878,757 and the baked text at 882,765. The user's report exactly: the textbox not anchored where the mark was placed, and its frame not drawn where the text is. The box is now the photo's LAYOUT box (offsetLeft/offsetTop/offsetWidth/ offsetHeight, whose offsetParent is the relative-positioned .canvas-wrap), which no transform can touch. Same run after: layer 43,-242 1670x1114 against the photo 43,-241 1670x1113, box x 878 against the mark's own 0.5 x 1670 = 835 + the handle, and the box at 878,757 against the text at 882,765. The corner handle mixed the other way round. It read the pointer's travel as (e.clientX - d.left) / d.width — a SCREEN distance over an UNSCALED width, and with d.left the mark's own anchor rather than where the handle was grabbed. At scale 1 the handle sits exactly one box width from that anchor, so f came out 1 and the drag read true; zoomed, the same pull arrives s times larger and the box it grows was itself s times too wide. Measured: an 80px pull at 1.749x reported size 1.503 and left the box 163 -> 420px where 163 -> 241px was asked for. The handlers now take the photo's unscaled width and height plus the scale it is drawn at (rect.width / offsetWidth) and divide the pointer's screen delta by both, so a pull reads the same at any zoom, and the face size and the y compensation it feeds are computed from the photo's own width — that is the width the engine draws the fraction against. Same pull after: 163 -> 241px, the top-left corner left where it was. Verified: wm-zoom-probe.cjs (new, scratchpad) — 2560x1706 upload, four notches of wheel held on the handle's own corner: layer vs photo box, box vs the baked white text, the box's growth against the zoom, then an 80px handle pull. 9/9 on http://localhost:8090 (built asset index-BOwzIcQD.js). On the previous build the same probe is 5/9 — the layer, anchoring and size checks above. wm-test.cjs 23, wm-font-test.cjs 38, wm-font-registry-test.cjs 26, wm-gps-test.cjs 27, wm-gps-date-test.cjs 18, crop-frame-test.cjs, compare-test.cjs 25, compare-crop-test.cjs, zoom-test.cjs 25 — 0 fail at scale 1, where the old arithmetic happened to be right. web tsc --noEmit clean. ponytail: offsetWidth/offsetHeight round to whole CSS pixels, so the box can sit half a pixel off the photo's own box — under a box whose tolerance is the dashed hairline, not worth un-applying the transform by hand; the day something reads those pixels, compute the fit instead, as baseRect already does.	2026-09-23 17:12:31 +07:00
3dtours	d37671c359	web: print the grain zone by mixing two lattices, not by warping one cell ... The coating's patches were drawn by varying the clump CELL with position: cell = u * (1 + (grainZone(p * ZONE_FREQ) - 0.5) * ZONE_SWING), the same slow value noise that picks the patch. A lattice whose cell varies with position smears instead of resizing: its phase accumulates as d(phase)/ds = 1/cell - s*cell'/cell^2, and c' is read along the radius from the picture's own origin, so the second term grows with the distance s from it and the clumps are drawn out wherever the patch's own cell runs. Measured on one classic-neg paint (1024px, cell 1.09, the app's own Overlay at alpha 0.5, 64 tiles): with the swing on, the tiles' lag-1 correlation of the raw frame spans -0.065..0.747 — clumps stretched into smooth blotches beside grain. The design's +-20% swing cannot do that: the SAME field with the swing forced to 0 spans -0.057..0.045 across its tiles, and the two-lattice field spans -0.055..0.052 (leica: -0.049..0.523 with the swing on, -0.068..0.024 at swing 0). The zone now MIXES two FIXED lattices, 0.8x and 1.2x the stock's own cell, weighted by that same patch noise. A fixed lattice's phase is linear in the picture, so a patch can only choose how much of each is printed, never how either is shaped — and the two lattices' beat falls at 1/(1/fine - 1/coarse) = 2.4 cells, 2.6px at the 35mm cell: the pixel scale, not a line the eye reads. The mix is renormalised by sqrt(w^2 + (1-w)^2), the share of one field's spread a two-field blend carries, so neither the mean nor the spread follows the patch: the same classic-neg field reads sd 24.85 against 24.91 and leica 23.74 against 23.74, tile by tile. The zone still reads what it is for. At preview scale (1600px, cell 1.70, 8x8 tiles of 200px) the mixed field's tiles span rho1 0.082..0.265, ratio 3.233, against 0.169..0.193, ratio 1.141, with the swing forced to 0 — classic-neg; leica 0.026..0.188, ratio 7.361, against 0.085..0.105, ratio 1.237. A coarser patch still prints coarser clumps; it just never prints a stretched one. Both copies carry it: docker/frontend/shared/utils/grainShader.ts and src/utils/grainShader.ts (the phone's, which the root web harness imports too). The field is evaluated once per lattice now, so the grain pass costs 1.94x what one lattice did — the ratio, not the absolute. Measured: _grain-zone2.cjs — the 64-tile lag-1 correlation spread above, three modules on one paint and one seed: swing 0.4 vs swing 0 vs the mix. _grain-zone-ck.cjs — the zone's own contribution at preview scale, zone on against the same module with the swing forced to 0, nothing else differing: classic-neg tile sd 24.21..24.86 (ratio 1.027), hf 0.769..0.937 (1.219), rho1 0.082..0.265 (3.233) against sd 29.04..32.95 (1.135), hf 0.834..0.858 (1.028), rho1 0.169..0.193 (1.141); leica rho1 0.026..0.188 (7.361) against 0.085..0.105 (1.237). The swing-off row's higher sd is the renormalisation of a blend with itself (a and b are one field at swing 0), not a contrast change in the shipped field. _grain-fft.cjs — same paint, same seeds, three rolls, 1024px: the mix's top spectral peak sits at 2.6px (classic-neg, cell 1.09) and 2.8..2.9px (leica, cell 1.00) against the warped field's 3.0/4.3/6.2px and 2.7/3.8/4.5px — both within a pixel of the clump cell, neither a coarse lattice. _grain-bench.cjs — 12.68s per 700px field (one lattice) against 24.60s (two), 1.94x on software CanvasKit. grain-size-test.cjs 17/0 — the SIZE rule and the readout on the module, both lattices floored at the target's own pixel, file rho1 0.673, preview rho1 0.003. grain-stock-test.cjs 53/0 on the deployed build — the stock table, the halation chain and its ordering, no page errors. grain-controls-test.cjs 20/0 on the deployed build — the patch claim still holds there: tile sd 56.58..65.48 (mean 61.9, max/min 1.157), tile mean spread 0.65, so a coarser patch is still not a brighter one. _grain-spectrum.cjs (app, deployed, 1600px) — residual autocorrelation peak 0.020..0.021, top peaks at 2.0px@20/110 and 2.5px@51. tsc: web `--noEmit` clean (the docker build runs it); the phone's scoped config reports its pre-change baseline, nothing in grainShader.ts. One honest number: the app-level spectral peak/median rises 4.6..6.1 to 10.2 (classic-neg, sim-classic-neg-g6/g10) because two fixed lattices beat where one warped lattice spread. It is 20x below the value-noise field this work replaced (29..35, tiling) and 5x below a lattice (50+), and it sits at 2px, the cell itself. ponytail: the field is evaluated once per lattice, so the grain pass costs 1.94x. One evaluation cannot hold two cell sizes; revisit only if a preview budget asks for the pass back. The 0.8/1.2 rungs (ZONE_SWING/2 either side) are one working set, not a search. Verified: `grain-stock-test.cjs` 53/0, `grain-controls-test.cjs` 20/0 and `_grain-spectrum.cjs` against the deployed build at localhost:8090; `grain-size-test.cjs` 17/0; `_grain-zone2.cjs`, `_grain-zone-ck.cjs`, `_grain-fft.cjs`, `_grain-bench.cjs` against the module built from HEAD, `inversesqrt` still the one call the shader needed to renormalise; web `tsc --noEmit` clean, phone scoped tsc down to its pre-existing errors.	2026-09-23 16:47:19 +07:00
3dtours	0e9f78bd5e	web: give the grain a size of its own, and read the count off the print ... MONOCHROME GRAIN was one integer knob 0..10 with one meaning, how much. It is now a strip of three: AMOUNT — the same knob, in half steps — SIZE, a percentage of the stock's own grain cell (50..200%, so the same number means the same texture relative to the picture on both platforms), and an inert readout of N/INCH, the clump count the two knobs and the stock add up to in the print's own terms (300 dpi = 300px of the 1080-wide reference the knob was tuned at). Emulsion is not one grain size across the frame: the coating settles unevenly. The field now prints that — the same hash read slowly (ZONE_FREQ = 1/96 cells, turned off the axes, smoothed so a border between two patches is a slope and not a seam) swings each patch's own cell by half of ZONE_SWING either way, ±20%. Nothing in it moves the field's mean: a coarser patch prints bigger clumps, not a brighter one, which is why the strip can read out one number while the frame carries a range. A patch may not swing a cell under the pixel the target can print, or the clumps are sub-pixel and print as static — aliasing, not a finer emulsion. The shader takes that floor as a `mincell` uniform beside the cell (u, mincell, seed.xy, in declaration order): an export passes one output pixel, a preview one device pixel (1 / PixelRatio), which is the floor the phone's preview already needed. SIZE is stored as an integer percent so no float noise reaches the recipe JSON, and it is read by the same two engines that read grain: the web's grainCell(width, stock, sizePct) and the phone's grainCell(width, minCell, sizePct). The chip above the strip carries the amount in half steps the way TEMP carries the kelvin, and the readout moves with SIZE, not with AMOUNT. Measured: grain-controls-test.cjs 20/0 — the strip carries grp-grain, grain:amount, grain:size and grain-inch; the AMOUNT ruler is 0..10 step 0.5, and 3 -> 3.5 moves the frame (sigma 18.53 -> 21.91, new hash) without moving the readout; 10 -> sigma 60.43, 0 -> sigma 0; SIZE 200% -> 130/INCH (sigma 40.06), 50% -> 522/INCH (66.56: under the preview's pixel floor what is printed is static, not finer grain); the region claim on an 8x8 grid of the flat frame gives tile sd 51.0..66.1, max/min 1.295, and a tile mean spread of 1.14 — a coarser patch is not a brighter one. grain-size-test.cjs 17/0 (was 12/0) — the SIZE rule and the readout on the module itself: 200% doubles the cell, 50% halves it, the output pixel still floors the smaller one. 4000px file cell 3.704 against 1.083 device px on a 3x preview, the old one-dp floor 2.77x coarser, rho1 0.627 against 0.074. The harness built its own 3-uniform array; it now passes [u, mincell, seed.xy] like every other caller. _grain-zone-ck.cjs — the zone's own contribution, at preview scale (cell 1.70, 1600px, 8x8 tiles of 200px): zone on, tile sd 23.22..24.82 (ratio 1.069); zone off, 24.42..24.79 (ratio 1.015). Nothing else differs. _grain-ck.cjs — the clump field is otherwise what it was: rho1 0.62 classic-neg / 0.12 velvia, residual autocorr 0.035 against 0.036 with the swing forced to 0, peak/median 32.3 against 27.6. _grain-spectrum.cjs (app, 1600px render) — residual autocorr 0.017..0.018, spectral peak/median 4.6..6.1: the slow lattice adds no peak of its own. grain-stock-test 53/0, sims-test 31/0, fx-mono-test 15/0, wb-preset-test 33/0, temp-swatch-test 33/0, wm-font-test 38/0, grain-analog-test 7/0 (its grain selectors moved to the strip). tsc: web clean; the phone's scoped config reports exactly the pre-change baseline (Viewfinder.tsx's own errors, none new). ponytail: the amount is fractional now, so the two recipe-create forms read grain through their own half() instead of the int() that would truncate the half the ruler just spent — every other knob there is still whole. The SIZE knob is one number for the whole strip: no way to dial a single patch, and no seed control. The readout is the DESIGN count the field is built on, never a per-patch measurement.	2026-09-23 15:26:23 +07:00
3dtours	64f1598076	web: print the grain as jittered clumps, not as value noise on a grid ... The field was 20-degree-rotated value noise on a square lattice, three dyadic octaves at 1 / 0.5 / 0.25 and a sin hash behind it. Value noise prints the density of the cell's four corners, so every clump sat on a knot of one grid, and the grid's own repeat — 13 cells, 44px at the 35mm cell — is what the eye read as diagonal lines. Measured on the old field through the app (`grain-analog-test.cjs`, `_grain-spectrum.cjs`): off-origin autocorrelation peak 0.32-0.40, spectral peak/median 29-35, top peaks at 5.4-7.8px. The field is jittered clumps now, in both copies (docker/frontend/shared/utils/grainShader.ts and src/utils/grainShader.ts). A clump lands at a random spot inside its cell — Worley F1 over the 3x3 neighbourhood, `grainClump` — so no two clumps share a grid, and what is printed is the distance to the nearest: a smooth mound, not one pixel of static. The hash behind the jitter is sin-free (Hoskins' `p3 = fract(vec3 * 0.1031); p3 += dot(p3, p3.yzx + 33.33)`), because a float sinus whose argument grows with the picture folds back on itself and is a lattice of its own. The three octaves are turned to their own angles — 20, 47, 73 degrees — and sit on 0.53 and 0.29 off the dyadic 1 / 0.5 / 0.25, where a coarse octave's cells land back on the fine one's and stack. Clumps sit higher and tighter than the value noise they replace — mean 0.569 against 0.500, sigma 0.123 against 0.081, measured — so the sum is put back on that mean and spread, `n = (n - 0.5685) * 0.52 + 0.5`, before the AMOUNT knob's own gain. The web keeps its uniforms (cell, seed, per-stock weights, spread); the phone keeps 0.55/0.30/0.15 and 2.95, which are the web's classic-chrome row, so the two print the same texture. Measured on the deployed build: `grain-stock-test.cjs` 53/0 — 35mm still coarser than 120, the halation chain intact per stock, the "halation follows the stock" ordering intact, the field still clumped (r1 0.336-0.506) and still surviving a 2x downscale. `_grain-spectrum.cjs` residual autocorrelation peak 0.02 (was 0.32-0.40), spectral peak/median 7.0-12.7 (was 29-35), top peaks only at 2-3px periods, the cell scale. `_grain-ck.cjs` at the preview cell (U=1.481/1.704): rho1 0.093/0.177 against the old 0.505/0.586, acPeak 0.02/0.028 against 0.38/0.467, peak/med 10.1/11.2 against 76/46.5, top peaks 2.0-2.9px against 5.4-7.8px. `grain-size-test.cjs` 12/0. `grain-analog-test.cjs` 7/0 — with the TEMP pair on AUTO, the field's channel split measures 0 at a cast of 0, so the grain is exactly monochrome and no neighbour lag carries structure (max |rho1..8| 0.118). One honest number: the preview's apparent strength at GRAIN 10 is ~25% higher than the old field's (sigma 61.3 against 47.9 in that harness), and that is the PREVIEW, not the field. Step 9 of src/engine/exportEngine.ts sharpens the preview at alpha 0.5, and the clumps now sit at the cell (~1.7px) instead of on the old ~5px lattice, so that sharpen bites harder. The field's own composite spread is 17% UNDER the old one at the same geometry — lab sdRaw 24.9 against 30.0, and geometry-flat where the old one was ~30 everywhere. The 0.52 normalisation was kept rather than re-tuned upward to the app-visible number: the export path does not carry that sharpen, and a grain tuned to it would print too strong. ponytail: the octave angles and the 0.53/0.29 rungs are one working set, not a search. Re-tune only if a stock's cell is changed again. Verified: 53/0 + 12/0 + 7/0 grain harnesses, `_grain-spectrum.cjs` and `_grain-ck.cjs` A/B against the field built from HEAD, `sims-test.cjs` 31/0, `fx-mono-test.cjs` 15/0, no page errors.	2026-09-23 13:00:14 +07:00
3dtours	c2a4740a3f	web: let the white balance carry its tint, and take its ratio in the light ... TEMP was a kelvin and nothing else, and the seven presets were seven numbers the two platforms disagreed about: AUTO 5500, DAYLIGHT 5600, DAYLIGHT -3R 5800, CLOUDY 6500, SHADE 7500 here and 8000 in both recipe-creation forms, TUNGSTEN 3200, FLUOR 4000. A chip tapped in the recipe panel and the same chip tapped on the photo printed different frames. The presets are now the phone's own WB_PAIRS — kelvin AND tint — in all three places, so every chip lands the same pair on either platform: AUTO 5500/0 DAYLIGHT 5500/0 DAYLIGHT -3R 5500/-3 CLOUDY 6500/1 SHADE 7500/2 TUNGSTEN 3200/0 FLUOR 4000/3 SHADE read 8000K in RecipeCreatePanel and RecipeCreateModal; it is the WB tab's 7500K/+2 now, so a recipe created in a form prints what the same chip prints on the photo. AUTO and DAYLIGHT stand for one pair, so the pair alone cannot say which of the two is lit. TEMP is therefore keyed by preset and not by value: `wbChoice` remembers the chip last tapped (the phone's own wbChoice), and `wbValue()` answers it only while the engine pair still matches, else the first preset that pair maps to, else the bare kelvin. `wbLabel()` names that pick on the chip, which now always carries one: TEMP AUTO at the neutral pair, TEMP SHADE on a preset, TEMP 6300K on the app's own default recipe where a hand-dragged ruler landed. Measured on the deployed build (`wb-preset-test.cjs`, 33/0): AUTO and DAYLIGHT print the same frame to the level, DAYLIGHT -3R moves the green away from DAYLIGHT at the same 5500K, the ruler warms monotonically across TUNGSTEN 0.525 / FLUOR 0.730 / AUTO 1.000 / CLOUDY 1.141 / SHADE 1.295, a hand-drag to 10000K names the chip `10000K` and warms the picture R x1.183 B x0.793, SHADE tapped after that drag restores the pair 7500/2 and prints the same frame the first tap did (R 156.8 vs 156.8), and a temperature drag leaves a preset's tint standing (FLUOR's +3). kelvinToRGB itself was the other half. It took the ratio of the sRGB-ENCODED blackbody colours and square-rooted it, which measured R x1.06 / B x0.89 from 5500K to 10000K — a shift a swatch shows and a sunset does not. White balance is a gain on LIGHT, so the ratio is taken in linear light now (`planckianLinear`) and tamed by a new `KELVIN_TAME = 0.5`: the same 10000K moves the frame R x1.16 / B x0.76, and 2500K its mirror, which is what a camera does with its WB set 4500K off the scene. One constant scales the whole ruler and both platforms carry the same one. Measured through the app (`_temp-probe.cjs`, gains against 5500K): 2500 R x0.569 B x1.640, 4000 R x0.866 B x1.197, 6500 R x1.057 B x0.940, 10000 R x1.140 B x0.759 — the readout is compressed against the raw gain because the cast lands on encoded, clipping pixels, which is the reason for the tame in the first place. ponytail: no scene meter, so AUTO stays the neutral 5500K/0 pair and is a name for it, not a measurement. Add one when the engine reads the frame. ponytail: KELVIN_TAME scales the whole ruler both ways. Split it into a warm and a cool constant only if the two ends are ever asked to move apart. Verified: `wb-preset-test.cjs` 33/0 and `_temp-probe.cjs`, `sims-test.cjs` 31/0, `fx-mono-test.cjs` 15/0, `wm-font-test.cjs` 38/0 against the deployed build; web `tsc --noEmit` clean, the phone's scoped check down to its two pre-existing `skiaImage.ts` nulls.	2026-09-23 13:00:14 +07:00
3dtours	4795a2a0ee	web: give each stock its own grain, and a halo where it belongs ... The landing card sells "35mm & 120 Film Grain — authentic grain structures plus halation bloom, tuned per stock rather than one global overlay", and the engine printed one field for everything: a width/1080 cell, one spread, no bleed. `shared/utils/grainShader.ts` (new, the web fork of the phone's src/utils/grainShader.ts) now carries the stock table — format, cell, spread, octave mix, halation, halo radius, halo tint — and `grainStockFor( recipe.baseFilter)` picks the one this recipe prints. FORMAT. 35mm cells are the 1.0 reference the knob was tuned at (classic-negative 1.15, B&W high contrast 1.25); the 120 emulsions sit at 0.55-0.72 and open their base octave (mix 0.55/0.30/0.15 -> 0.62/0.26/0.12), so the same knob prints a finer, smoother texture on the bigger negative. Measured on a flat 128 grey at a 3200px preview (cells 3.41px vs 1.63px), GRAIN 10, luma residual against a 17px box: 35mm CLASSIC NEGIPES r1 0.793 keeps 0.976 35mm CLASSIC CHRIPES r1 0.744 keeps 0.931 35mm B&W HIGH CONTRAST r1 0.812 keeps 1.002 120 PROVIPES r1 0.423 keeps 0.728 120 VELVIPES r1 0.313 keeps 0.672 120 ACRIPES r1 0.543 keeps 0.794 r1 is the lag-1 autocorrelation of the residual — how coarse the clumps are — and "keeps" is the residual sd after a 2x box downscale over the sd before, i.e. how much of its texture a print at half size holds on to. Every 35mm stock beats every 120 stock on both, and VELVIPES (0.55 cell) is finer than PROVIPES (0.62) inside 120, so the format is a look and not a label. Raw sd is NOT the measure: the knob drives one alpha for every stock, so a stock's amount follows its cell and mix rather than the order anyone assumed. HALATION. A new pass 6b thresholds the print (T0 0.62, T1 0.92), tints what is left the stock's halo colour — red, because red is the light the emulsion passes and the backing returns — blurs it at the stock's own radius and screens it back at `halation * grain/10 * 0.6`. Riding the GRAIN knob keeps today's contract: OFF is still a clean frame, the OFF/WEAK/STRONG chips still mean 0/3/6, and a sensor stock carries none at any amount. Measured R-B of the ring around a white block on black, GRAIN 6 minus GRAIN 0 (mean, and the ring's reddest pixel): CLASSIC NEGIPES 7.87 (peak 0 -> 14) VELVIPES 3.71 (0 -> 13) CLASSIC CHRIPES 2.91 (0 -> 10) PROVIPES 2.01 (0 -> 7) B&W HIGH CONTRAST 0.61 (0 -> 5) ACRIPES 0.24 (0 -> 3) LC STREETLIFE CLASSIC 0.09 (0 -> 0) which is the table's own halation column (0.45 > 0.30 > 0.25 > 0.18 > 0.15 > 0.12) in order: the colour negative halates hardest, the B&W emulsions barely, Acros — no colour layer to bleed — least of all, and the sensor not at all. The colour negative's own grade leaves its ring blue at GRAIN 0 (-5.96 there), so the statistic is the change and not the absolute channel; in a crop of the block the bloom itself is unmistakable at GRAIN 6 and 10 and absent at 0. GRAIN_SEED moves here from exportEngine.ts so the roll is still one per page load, and still shared by the preview, the compare copy and the file. Checked: tsc --noEmit clean; grain-stock-test 53 PASS / 0 FAIL; sims-test 31/0, fx-mono-test 15/0, grain-size-test 12/0, grain-analog-test 7/0, wm-font-test green. ponytail: halation rides the GRAIN knob instead of a control of its own, since the card promises no more than "tuned per stock". Add a HALATION chip when the phone grows one. ponytail: `grainCell`'s 1px floor is the aliasing guard, and it also hides the format ratio under a ~1600px preview. Nothing to add: the exported file is always wide enough, and the harness renders at 3200 to see it.	2026-09-23 11:46:45 +07:00
3dtours	7a8c0aa2b5	web: print what the temperature ruler does, not the colour of the light ... COLOR TEMP's swatch was Tanner Helland's blackbody fit, so it painted the colour of the LIGHT the number names: 2500K came out orange #ff9f46 while the engine cooled the frame on the same knob. Read off the render of a neutral 128-grey (mean of the painted preview, CCT via McCamy), the two ran opposite ways at every stop: K old swatch swatch CCT picture mean picture CCT 2500 #ff9f46 2384K 115,135,204 47691K (blue) 3200 #ffb87b 3096K 128,141,171 11246K 4000 #ffcea6 3931K 135,141,156 8203K 5500 #ffedde 5414K 144,139,143 6479K (unity) 6500 #fffefa 6322K 148,138,139 6029K 7500 #e6ebff 7730K 149,138,132 5555K 10000 #cadaff 10024K 153,138,128 5180K (warm) So the number is a Kelvin of the scene's light — which is exactly why the engine warms the picture as K rises — and the swatch was the one thing on the ruler that disagreed with the ruler. It is now painted from kelvinToRGB itself, the same gains the render puts on every pixel, on a mid grey, so the band under the knob can never drift from the frame above it. kelvinToHex goes away with it: one Kelvin->colour mapping in the app, not two. Measured after: the swatch's R-B tracks the render's own cast at every stop (-82 vs -89.8 at 2500K, +23 vs +24.0 at 10000K), 5500K is flat #808080 — the engine's unity point — and 3200K sits cool / 7500K warm either side of it. temp-swatch-test.cjs (scratchpad): 33 PASS / 0 FAIL.	2026-09-23 11:17:59 +07:00
3dtours	d55b7b49ca	web: give each watermark its own collapse, and a face to print in ... The panel shared one column between the two marks, so GPS's colour, its two switches and its hand-typed place stood open beside the custom mark's text, colour and size whether or not either mark was on. The two are now collapses, one per mark: the header chip is the section, and that mark's own controls sit under it. What opens a section is the mark itself — GPS WATERMARK ON opens GPS's controls, CUSTOM WATERMARK ON opens the custom mark's — so there is no new state and no way for a panel to disagree with the pixels. Both marks gain the FONT strip the phone has had (TEXT FONT for the custom mark, FONT for GPS, whose stamp the phone also lets you set a face on). A browser has no font service, so the list is exactly what the bundle carries: the site's two self-hosted families, Inter and Fraunces (SIL OFL), their latin, latin-ext and vietnamese woff2 subsets decompressed, pinned to weight 400 @ opsz 14 and merged into ONE TTF per family — drawText has no glyph fallback, so a family mapped to only the latin subset would print a Vietnamese place name as tofu. DEFAULT stays the bundled Cousine face, which is what every existing session and every mark without a family prints. Two engine bugs came out of it. CanvasKit 0.42's Font.getGlyphWidths passes its output pointer where the wasm export wants the bounds pointer, so every glyph in a run comes back holding one identical, rounded width — at 64px on the merged Inter face, 'H' and 'i' both answered 42, while hmtx says 0.743em and 0.242em, and a box measured off it was 27% too wide ("Hà Nội 09/23" 510px against a true 403px). The shim now rebinds it with the pointers in the order _getGlyphWidthBounds reads them, and the stage's boxes measure with linear metrics, which land on hmtx exactly (403.28px against 403.28; hinted is 407). And CanvasKit's TypefaceFontProvider.matchFamilyStyle answers null for every style shape this binding accepts, so a name registered with it never resolved — the shim keeps its own registry keyed by family name instead. Measured: tsc clean; the engine harness on the merged faces 26/26, including the registry's advances against hmtx (Inter 6.3013em, Fraunces 6.3475em); the deployed app under Playwright 38/38 over the two collapses and both FONT strips — each mark's controls appear only with its own mark on, the DEFAULT/INTER/ FRAUNCES box widths match hmtx, the baked ink fills the box, the top edge re-hangs off the new ascent (Inter 0.96875em against Cousine's 0.8325em, 3.4px at this size) with the left edge fixed, and UNDO round-trips. Opening a section narrows the stage by 168px with no window resize (955px -> 787px), so the stage now re-measures its drop boxes off a ResizeObserver on the frame and the picture rather than on the next render. Not ported: the phone's GPS watermark still prints in the bundled face only (no emulator here to verify a phone-side font strip), and the FONT options are not behind the PRO gate the way the phone gates non-default families.	2026-09-23 10:59:49 +07:00
3dtours	e8a0c0d076	web: print the grain as clumps, not as static ... GRAIN was one value hash per cell, sampled straight off the pixel grid: a square lattice at the picture's own axes, the same field in every session and in every photo, and — measured on a flat gray frame, where every deviation IS grain — a spread that was flat rather than emulsion-like (neighbour correlation rho(1) = 0.183, so half the noise was one pixel wide). The noise is now an emulsion. Three uncorrelated hashes are averaged into a density (a bell, the way an emulsion's density swings, instead of the flat spread of a single hash), that density is read as value noise with a smoothstep cell, and the result is three octaves of it — the cell, then 2x and 4x that cell — over a lattice turned 20 degrees off the picture's axes, so no grid shows through. Only coarser octaves: a finer one (tried 2.043x, 0.72px) goes sub-pixel and rho(1) falls to 0, i.e. back to static. The whole domain is offset by a seed rolled once per page load, so two visitors never print the same clumps while the preview, the compare copy and the file of one session still print the same roll. Same flat 3000x2000 frame, preview render 1600x1067, GRAIN 10: sigma 52.53 -> 50.15 (the 2.95 gain keeps the spread the AMOUNT knob was tuned against, since the repo notes the slider was calibrated on the old field), rho(1) 0.183 -> 0.275, and the three channels still move together — the 6.9 of sigma 50 that is left over is the Overlay blend meeting the frame's own tint, the plane itself is one gray value in all three. Re-rendering the same frame draws the same clumps byte for byte; a reload rolls a new seed and a new field at the same strength.	2026-09-23 10:01:49 +07:00
3dtours	cf0091b741	web: name a position that lands before the account is known ... A photo restored from the session reaches the stage while /me is still in flight, so the account reading that put it there saw `pro` as false, the place lookup was skipped, and reloading a photo left the stamp with bare coordinates. Naming now happens in one effect that watches the position itself: the first moment it is on the stage unnamed and the account is PRO, it gets a name, wherever it came from. A position typed in by hand earns its name too, and a guest's photo is named the moment they sign in. The two call sites that used to ask for the name — in locateMe and adoptPhoto — are gone, since the effect covers both.	2026-09-23 09:33:26 +07:00
3dtours	3bfa82e7f2	web: stamp the photo's own day on the GPS mark ... The GPS mark printed Date.now(), so a photo taken in 2019 carried the day it was opened. It now prints the frame's EXIF date — DateTimeOriginal, falling back on CreateDate then ModifyDate — wherever the position came from: - readCapturedAt() reads the date off the file, and readGps() uses it for a position found in the same EXIF. - adoptPhoto holds it in its own state, so a frame with a date but no position still stamps the date when the position is typed in by hand. - The device's own position stamps it too. That path runs inside adoptPhoto, where the render still holds the previous photo's date, so locateMe takes the date as an argument rather than reading state — the panel's own button, which has no such date to hand, passes none and reads the state as before. A file with no date at all still falls back on the visitor's clock: there is nothing else to believe.	2026-09-23 09:22:19 +07:00
3dtours	a0965101e1	web: hand the upscaler's activations to the chip that is running them ... The WebGPU execution provider has no PReLU kernel. The model is 34 convolutions with a PReLU after every one of them, so an export that took the GPU path was split 33 times: each activation came off the chip to be activated on the processor and went straight back, a 64-channel map in both directions, per tile. A machine with a good graphics chip was not exporting any faster for having it. PReLU(x) is exactly Relu(x) - slope * Relu(-x), and Relu, Neg, Mul and Sub the provider does implement, so scripts/realesr-gpu.py writes the 33 activations out as those four and drops the slopes nobody reads any more. The model file is the output of that script, not the file as published. One 256x256 tile through the model before and after, on a WebGPU session: the runtime no longer reports nodes left off the preferred provider (it did, once, before) and the processor path answers bit for bit what it answered before. The warning itself cannot be switched off from here - env.logLevel is read when the runtime module initialises, before any of this runs - so the graph was fixed rather than the lines hidden.	2026-09-23 09:02:53 +07:00
3dtours	a2c12a2638	web: ask the GPU for the fast one before an export runs ... onnxruntime hands a webgpu session whatever adapter the browser picks by default, which on a laptop with both is the one built into the processor: the export then waits on the slow half of the machine for no reason. The runtime reads `env.webgpu.powerPreference` when it builds the webgpu session, so set it to high-performance; a browser with nothing to honour the preference with still falls back to the threaded wasm path exactly as before.	2026-09-23 08:36:03 +07:00
3dtours	28a688fd82	web: hand the upscaler only the pixels the export is asking for ... The model's own factor is 4 and the export's target is some number of pixels, and the two were never reconciled: a 2400x1800 photo exporting at 4K was run through the model at 4x — 9600x7200 of invented detail — and then three quarters of it were thrown away by the draw that lands the file on 3840. The arithmetic was the whole wait. Measured on the wasm path, one export: 153.2s. The photo is now resampled once to `targetLongest / 4` before the model reads it, so the model still answers at its own 4x and the answer is the size the export asked for. Same 2400x1800 to 4K: 42.7s, 80 tiles of model for 20. Half the photo's pixels is the floor — below that the model is no longer enlarging the picture, it is drawing a new one from memory — and the ceiling is the photo's own size, so a gain past 4 behaves exactly as it did. Nothing in the finished file gives the smaller input away: the 6px stripes come back at full contrast (254.9 vs 254.8), the black-to-white step lands on the same pixel (x=625 in both) and rises in 1px instead of 3. The 32MB of runtime and model are also fetched, and one 16x16 tile pushed through the graph, when the export menu opens rather than after a size is picked: the visitor waits for the pixels, not for the download. crop 1:1 2400x1800 to 4K: 155.8s -> 52.6s, crop 3:4: 153.0s -> 54.1s.	2026-09-23 08:27:00 +07:00
3dtours	52566f6966	web: read the photo's own size off the row under it ... The row below the photo carried CLEAR, OPEN and SAVE ORIGINAL but never said how big the picture was, so the only way to learn the resolution was to open the export menu and read the hint there. The size now leads that row, before CLEAR: the file's own pixels turned by the quarter turn and cut by an applied crop, so it is the number an export at the photo's own size writes. A live crop does not move it (nothing is cut yet), STRAIGHTEN never does (the rotated rectangle is fitted back inside the same pixels), and the guest tier's 2048 cap is still only announced in the export menu where the file itself is capped. Verified end to end in photo-dims-probe.cjs: 2400x1800 opens as "2400 × 1800", a 90 deg turn reads 1800 × 2400, an applied 1:1 crop reads 1800 × 1800, and the export writes exactly that file.	2026-09-23 07:58:56 +07:00
3dtours	d9bababfd7	web: filter the framed print draws so a scaled photo stops staircasing ... The polaroid and the wall frame both draw the photo into a window that is not the size of the photo — the instant print shrinks it to 0.898x, the wall frame cover-scales it by max(winW/pw, winH/ph), which is 1.47x up for a 2400x1800 source. A plain drawImageRect is nearest on CanvasKit, so that resize dropped the edge back onto the output pixel grid: a 5 deg straighten inside a frame exported 59.8% of its rows with the crossing pinned to the same pixel as the row above (61.1% in the wall frame), while the same photo without a frame came out at 55.8%. Both draws now go through drawImageRectOptions with FilterMode.Linear, the same call shape the straighten draw already uses. Measured on a 2400x1800 hard-edge fixture at 5 deg, exported at the photo's own size: polaroid 59.8% -> 37.5% flat rows, fracStd 0.336 -> 0.184; wall frame 61.1% -> 25.7%, fracStd 0.467 -> 0.210 — and the residual matches the 0.202 of the unframed export, so the window costs nothing beyond the resample underneath it. A 45 deg edge printed through the instant frame at 0 deg is unchanged at 0.0% flat rows.	2026-09-23 07:46:19 +07:00
3dtours	3a09674831	web: filter the straighten draw so a rotated edge stops staircasing ... The FRAME tab's fine rotation drew the photo through canvas.rotate() + canvas.scale() with a plain drawImage, which CanvasKit samples with nearest: the edge landed on the same pixel in every row, so a rotated edge came out as 1px steps every 1/tan(angle) rows. Measured on the 30deg export of a hard black/white edge: 42.3% of rows repeated the previous row's edge position, the step across the edge was 252.9 of 255, and there were no intermediate pixels at all. Only the *Options/*Cubic call shapes take a sampling option, and drawImageRectOptions exists in RN Skia too, so the shared renderer can use it unchanged. The same export now moves the edge in every row (0.2% of rows repeat, 0.35 intermediate pixels per row) and its edge step drops to 222. Cost: the filtered draw takes 0.35s against 0.24s for the 1600px preview copy and 2.0s against 1.4s for a 12MP photo, once per render. Preview and export share the function, so both change together.	2026-09-23 07:33:44 +07:00
3dtours	500068e63e	web: mark SAVE PHOTO PRO and keep MY PHOTOS for the accounts that have one ... Saving into the account's own folder has always been the account's act — the button opened the way in and the API answers an unproven address with a 403 — but nothing on the button said so, so it read as a button that quietly did nothing. It now wears the same PRO marker the chips do, and only while the folder is not the visitor's. MY PHOTOS is that folder's listing, so the tab is only offered once an account can hold one. A guest loses the tab entirely rather than opening it on an empty folder that could never fill; an account that has signed up but not proven its address keeps the tab, and the tab keeps offering the way to prove it.	2026-09-22 21:46:05 +07:00
3dtours	b9ac7746aa	web: gate the newest film sims and the HSL mixer behind PRO ... The last three PHOTO STYLE looks (B&W HIGH CONTRAST, LC STREETLIFE CLASSIC and LC STREETLIFE VIVID) and the whole mixer now belong to the account, the way PRO frames and the geotag already do: the chip wears the PRO badge, a guest who picks it is shown the way in, and the look stays off. The HSL tab keeps its place in the rail but offers the one PRO chip while locked, so the tab itself is not a dead end; a look that arrives without the chips — an imported .recipe, or a photo saved before the gate — is still caught where the gate bites, at export. STRAIGHTEN's scale turns with the wheel, one degree a notch, because the ruler is where the angle is being judged and reaching for a slider elsewhere loses the thread. The listener is native and stops the notch before the stage sees it, so the photo does not zoom under the pointer. The scale gives up its opaque card, its blur and its shadow: the frame it is levelling has to stay readable through it, so legibility comes from a text shadow on the heading and a drop shadow on the graduations instead.	2026-09-22 21:33:11 +07:00
3dtours	f201deee46	web: export a big photo without inventing pixels it already has ... The export menu measured the photo off the 1600px preview copy, so a 2400px photo was believed to be 1600px across: the hint named the wrong size, the model was asked to upscale a photo that already had more pixels than the target, and a guest's 2048 ceiling was skipped because 1600 never crossed it. A committed crop made it worse — the crop's longest edge was taken from the wider side of the crop rect rather than the side the frame actually keeps, so a 2400x1800 photo with the default 0.8 frame was called 1280px and ran the model over 80 tiles (158.7s) to reach 2K. The photo's own dimensions are now read off the original bytes, and the crop's long edge is the same axis-aware fraction the stage already uses. The export asks the model only when the photo itself is short of the requested size, or when the crop would have to be stretched past 1.5x to get there; otherwise it resamples — down, or a hair up to make up for the crop — which is what a photo that already holds the pixels deserves. Measured, wasm path, 2400x1800: no crop at 2K went 2.7s/2400px (wrong size) to 3.4s/2048px, the default 0.8 crop went 158.7s/80 tiles to 3.5s/no model, and a 1:1 crop went 2.5s/1800px to 4.0s/2048px. A 1200x900 photo cropped to 1:1 and exported at 2K still runs the model (2048 from a 900px crop, 40.3s), and the superres suite is unchanged: 640x480 to 2K/4K/custom still comes out exact, with the model's 16.6 edge energy against bilinear's 4.8.	2026-09-22 20:43:46 +07:00
3dtours	1d4c6b1d66	web: upscale on a thread pool instead of one core ... The super-resolution export ran single-threaded because the site was not cross-origin isolated and the runtime had no SharedArrayBuffer to spread a tile over. nginx now sends COOP and COEP — on the document, and on the script responses a nested worker fetches, which Chromium checks the same way and blocks as `coep-frame-resource-needs-coep-header` without them — and the loader asks for `min(8, hardwareConcurrency)` threads whenever the page is isolated, falling back to one if the headers ever go missing. A worker script is also why the landing's QR image needed `crossOrigin`: COEP refuses a cross-origin image that did not opt in with CORS. The unpack was the other half. Each tile was clamped a channel at a time and painted whole, padded ring and all; it now writes straight into the Uint8ClampedArray, which clamps and rounds on assignment, and skips the ring rather than drawing it and clipping it away. 640x480 to 4096: 39.0s to 16.2s. 1000x750 to 4096: 89.6s to 30.9s. One 256px tile through the model: 6.8s to 1.8s. Measured on the wasm path — the test browser has no GPU adapter — so a WebGPU export, still per-tile inference, keeps its own times.	2026-09-22 20:30:02 +07:00
3dtours	c403dd04c8	web: add the B&W HIGH CONTRAST film sim to the PRESETS rail ... The chip lands after ACRIPES and is a mono stock of its own, so it gets its own baseFilter ('mono-high-contrast') rather than borrowing Acros': the PHOTO STYLE chips are keyed by baseFilter, and the two greys must sit side by side. The look is the B&W MIX plus a push at both ends. The mix rides the matrix — a non-BT.709 row set (0.38/0.56/0.06, identical rows, sum 1.00) so a red roof reads bright, a blue sky deep, and the separation is contrast before any curve. The push rides FILM_TONE (shadow -0.32, highlight +0.26) so the ends move without touching the midtones, and the midtone slope is SIM_CONTRAST_BIAS (4 contrast units) next to the sim's own exposure bias. The knobs stay at neutral: a sim is colour and tone only. Both B&W stocks being mono is now asked once, through isMonochromeBase, so the colour-only stages (saturation, white balance, R/B fine-tune, chrome, hue mixer) and the MONO strip label can never half-apply to one of them.	2026-09-22 17:56:00 +07:00
3dtours	80512d11b5	web: print the shared frame's own labels on the QR recipe card ... The card carried studio copy — SUNSET GLOW, a made-up warmth/grain/bloom line and a creator handle borrowed from a testimonial — no matter which still the arrows landed on. Stepping the frame changed the picture and the code but left the text behind, so the card described a photo it was not showing. The card now reads the frame's own labels: the tagline over the still and the title and ISO/grain line under it are the ones the uploader saved with the photo, the same three the film strip prints. The fabricated creator/imports line goes with them, since nothing behind it was real.	2026-09-22 17:22:54 +07:00
3dtours	2ee49cfd41	web: keep the film strip seamless on a wide window ... The marquee loops by translating the track by half its width, so the first half has to be at least as wide as the window. A short reel — seven stills, about 1780px — covered a 1440px window but not a 1920px or 2560px one: the strip ran out of frames before the loop restarted, and the band on the right stayed blank until the next pass drifted in. The track now measures one frame's pitch and repeats the reel until a half covers the window, re-measuring on resize. One still in the strip is repeated enough times to loop cleanly on its own; a reel already wide enough is left at a single copy, so nothing is duplicated without cause.	2026-09-22 17:11:12 +07:00
3dtours	e1f6943f8e	web: step the creator and QR previews through their tagged stills ... The landing's tester preview has had a ‹ › pair for a while; the custom recipe creator and the QR recipe card still showed one arbitrary frame from whatever the curator tagged for them. Both now cycle their own slot the same way, from a random start so the page does not look identical on every load, wrapping at both ends. The QR card's payload is not decoration: it is the link of the frame on screen, so the code under it is redrawn from the same frame the arrows land on. A slot holding fewer than two stills gets no arrows, since there is nowhere to step. The tester's arrows move to the shared FrameArrows component, which is what the two new pairs use — one implementation, three slots.	2026-09-22 17:03:46 +07:00
3dtours	bb51b83399	web: the hero stat labels wear the accent as gradient text ... COLOR RECIPES, DOWNLOADS and STORE RATING were flat grey under their numbers. They now sweep from the theme's own accent to the film red and are cut out of that gradient, the same treatment the headline above them gets. Because the sweep starts on var(--accent), the colour group in the Theme menu still retints it; the light theme starts from the darker ink accent so the labels keep their contrast on white.	2026-09-22 16:47:35 +07:00
3dtours	cfe8512636	web: the landing draws only the stills the studio uploaded ... Six bundled sample negatives stood behind eight built-in looks, and they were the only frames on the page nobody had uploaded. They are gone, along with the REEL table and the SAMPLE() helper that pointed at them. The film strip is now exactly the photos the curator put in the strip slot, repeated once for the marquee loop; a section whose slot holds nothing simply draws no frame instead of falling back to a stock photo. The reel's rating keys are all photo:<id> now, and the QR card's filter follows the sunset preset it claims rather than an index that moved.	2026-09-22 16:35:40 +07:00
3dtours	7f2a5b0b5a	web: drop the 300 ppi lines from the landing copy ... The claim was printed in four places — the RAW feature card, the quality FAQ, the custom-recipe readout and the Lite plan list. Each now reads as print-ready instead, and the readout keeps only RECIPE CUSTOM_01 · EXIF KEPT. The exporter's own JFIF density is untouched, web-smoke still checks it.	2026-09-22 16:04:51 +07:00
3dtours	339d36eb3e	web: the preset tester picks its recipe from a grouped dropdown ... The row of pills grew as the library did, so the landing's live tester now offers the stocks through one native select, grouped into Landscape, Portrait and Streetlife, five stocks each — fifteen in all. Choosing one still lands on the preview immediately: the frame, the HUD and the spec card all follow the selection. Stock names stay proper nouns, the group names are translated with the rest of the page.	2026-09-22 12:49:18 +07:00
3dtours	7dea0f1e7b	web: the mixer's card can be dragged off the colour it was read at ... The card hangs on the point the eyedropper read, which is exactly where the user wants to watch the band move — so it covers the patch it is editing. Its body now takes a drag: the offset is a fraction of the photo, which is the layer the card lives in, so a zoom keeps it where it was put and a fresh pick drops it back on its own point. The knobs and the close button keep the pointer to themselves, and the anchor cannot leave the photo, so the card is always half in reach of a drag back.	2026-09-22 11:13:21 +07:00
3dtours	88afdf6611	web: compare the same frame rendered twice, whatever its geometry ... The split used to paint the photo file beside the render, so it only lined up while nothing had moved: a turn, a straighten, a printed frame and the halves were two different pictures. The app now renders the same frame twice — once through the look, once through the neutral stock — and the left of the bar is that second copy. Rotation, straighten, crop and frame land on both halves by construction, so the CSS that tried to map the crop onto the file goes away. The toggle lives in the app now, which is what knows how to ask for the extra render; it is only asked for while the split is up. The layer waits for that copy rather than flashing the raw file, whose geometry is already wrong.	2026-09-22 10:59:37 +07:00
3dtours	1d96269139	web: keep compare on offer, and compare at the cropped size ... Choosing a crop ratio used to disable COMPARE outright, because the split painted the whole original into a box that was now the crop's shape. The original is now looked at through a window of the render's own shape: with a crop applied the photo is scaled and slid by the crop rect so the same rectangle lines up, and the split compares like with like. The window needs the image free to overflow it, so the inline style lifts the box clamp that .canvas-wrap img puts on every preview.	2026-09-22 10:45:07 +07:00
3dtours	b394bad09e	web: a wall frame keeps the crop that was applied ... CROP + APPLY then a wall frame handed back the whole photo: the crop block was skipped outright for both walls, so the artwork hung the original. The walls' own opening still ignores the aspect chip — that is what the exclusion was for — but the visitor's crop is theirs to keep. Measured with a source banded red on top and blue below, cut away by a 16:9 crop: through WALL FRAME and WALL FRAME LANDSCAPE the bands used to come back (569k and 350k red pixels); both now export clean.	2026-09-22 10:31:27 +07:00
3dtours	711e2fc5d6	web: the history arrows sit with the name they undo ... Undo and redo were on the far side of the spacer, past RESET, SAVE PHOTO and EXPORT. They belong next to what they step through: the header now reads mark, page name, preset name, the two arrows, then the actions.	2026-09-22 10:14:51 +07:00
3dtours	2f78216b6f	web: the upscale drops its tile seams ... A tile's destination rectangle was placed at x0 * scale, and that scale is rarely whole, so every 256px boundary landed on a fraction of a pixel. The edge was drawn half covered, stayed transparent, and the JPEG export flattened that transparency onto black: a dark line down each seam. Snap both destination edges to whole pixels instead, so neighbouring tiles share the exact same boundary, and make the destination context opaque so no partly covered pixel can survive as transparency again. Measured on a 640px source: the seam at 2K was 46 levels darker than its neighbours (96 at 4K); it is now within one level of them.	2026-09-22 09:56:12 +07:00
3dtours	c0c99a9672	web: EXPORT offers a size, and a bigger one is upscaled in the browser ... The server still never sees a photo, so the model has to run in the page. Real-ESRGAN x4v3 ships as a 4.9MB ONNX in public/models and is loaded lazily on the first export that actually needs it; the wasm runtime is copied next to CanvasKit at build time and stays lazily fetched, cached for 30 days. Vite is told onnxruntime-web is external-wasm so no 28MB asset lands in the bundle. UNCHANGED keeps the old path and the tier cap; 2K/4K/custom upscale only when the request is larger than the photo being edited, otherwise they resize down. Guests keep UNCHANGED and 2K. Tiling is 256px with an 8px overlap, so memory follows the target size rather than four times it.	2026-09-22 09:40:18 +07:00
3dtours	f9a40a9e1c	web: the histogram opens top-left, and CLEAR asks before it forgets ... The histogram used to park itself in the top-right corner on the first paint; it now starts at the top-left of the photo and is dragged from there, the way the rest of the overlay is. Nothing else changed in it — same drag, same clamping, same resize. The stage also gains a CLEAR button, sitting before the picker button, which is now OPEN PHOTO. CLEAR takes the photo off the stage, but not before asking: SAVE PHOTO files it first and only then clears, EXPORT IMAGE writes the JPEG and then clears, CLEAR WITHOUT SAVING drops it there and then, and CANCEL leaves everything alone. Saving from that modal resumes the clear once the file has really landed — a guest, a capped account or a cancelled name prompt never loses the frame. Clearing forgets the working photo (source, preview, GPS, ISO, and the IndexedDB copy session.ts now deletes), while the look, the crop and the undo history stay put, so the next photo opens on the same settings the way replacing a photo already did.	2026-09-22 08:56:58 +07:00
3dtours	59d90ae068	web: the sim chips keep their legacy names ... The name table is a reference for what each sim has to look like, not a renaming order: the ten PHOTO STYLE chips go back to PROVIPES, VELVIPES, CLASSIC CHRIPES, CLASSIC VIVIDIPES, CLASSIC NEGIPES, ASTIPES, ETERNIPES, ACRIPES, LC STREETLIFE CLASSIC and LC STREETLIFE VIVID. The comment above FILM_SIMS now says so outright — label on the left, the stock's colour and tone it must match on the right, and neither side moves the other. The grading is untouched: a sim is still colour and tone only, its `adjustments` stay neutral, and LC STREETLIFE VIVID keeps its +2 exposure as SIM_EXPOSURE_BIAS in colorUtils rather than as a knob.	2026-09-22 08:37:19 +07:00
3dtours	428e7fa682	web: a film sim is colour and tone only ... The ten PHOTO STYLE sims now carry nothing but their stock's own grade, and each is named for the stock it stands for: PROVIA, VELVIA, CLASSIC CHROME, CLASSIC VIVID (Velvia spliced with Classic Chrome at the blue row), CLASSIC NEGATIVE, ASTIA, ETERNA, ACROS, LC STREETLIFE CLASSIC, LC STREETLIFE VIVID. Grain, clarity, saturation and light moves were dropped from their `adjustments`, so a sim is a clean starting point and the general knobs read their defaults while the look still lands on the pixels. LC STREETLIFE VIVID keeps the one brightness step its stock needs, but as SIM_EXPOSURE_BIAS in colorUtils rather than as an adjustment: it is folded in where the Exposure slider applies, so the picture gets the lift and the parameter stays at 0. Also in this checkpoint: the watermark/GPS boxes and their colour pickers, the WATERMARK chip column, the real admin stats, and the fix that stopped presets from doubling and a frame from refusing to come off when a photo was reopened (/file is the finished render, /base the editable pixels).	2026-09-22 08:32:28 +07:00
3dtours	52b672deec	web: PRO needs a proven address — email verification gates the studio ... A signed-in account is served exactly like a guest until it opens the verification link: watermarked 2048px export, no saving, no PRO frames, GPS stamp or HDF. SMTP is declared in .env; with SMTP_HOST unset the link goes to the container log. Allowlisted admins count as verified.	2026-09-20 07:39:03 +07:00
3dtours	efe578f61c	web: the mobile chip strip lies down ... Tapping a tab on a phone opened a 148px column with the chips stacked one per line, so the strip read as a ladder down the side of the photo. Android's own panel runs its chips as a row — see src/components/AdjustmentPanel.tsx — and that is what the phone now gets: the columns stack into one vertical scroll and each chip row runs sideways again, wrapping inside the full width. Desktop and tablet keep the columns and the stacked chips; the change lives in the <=860px block.	2026-09-20 07:00:55 +07:00
3dtours	6afb7d9fea	web: the mobile rail wears Android's pills ... On a phone the studio's tabs are now the row the Android app draws: text pills in uppercase mono, rounded full, amber and a step larger when open, no glyph, scrolling sideways when the ten tabs outrun the screen. Desktop keeps its icon-over-label column — the change lives in the <=860px block, so nothing above that breakpoint moves.	2026-09-20 06:24:27 +07:00
3dtours	15bacacafa	web: logging out ends the studio session, not just the cookie ... A session followed the browser, not the account: log in, open a frame, log out, come back as a guest — the same photo stood on the stage, because the studio's own store (localStorage knobs + the photo in IndexedDB) outlived the cookie with nothing to clear it. clearSession() now drops both, and the three log-out buttons call it. The studio's own button reloads after the delete has committed — a reload mid- delete aborts the transaction, so the promise resolves on tx.oncomplete, not on the request. The account's frames are untouched: they reopen from MY PHOTOS.	2026-09-18 21:48:19 +07:00