55 Commits

Author	SHA1	Message	Date
3dtours	c1397c58cb	web: separate global endpoint curves (blacks/whites) from local tone mapping to eliminate grey aura around silhouettes and bump sw cache to v4	2026-10-02 16:06:41 +07:00
3dtours	e98b4d9d5c	web: fix halo artifacts on highlight/shadow/white/black adjustments with edge-aware tone mapping and update docker packages	2026-10-02 15:27:32 +07:00
3dtours	acbb2bba4b	web: the four tonal knobs are sized by what the eye can see, and the highlight head is squared so a bigger rate fits inside the cube ... The report was "giá trị thay đổi của các thông số quá nhỏ, không thể hiện được trên thị giác của ảnh" — at the doc's own rates a full +100 was worth 0.060 of luma on BLACKS, 0.082 on HIGHLIGHTS and 0.042 on WHITES, and the probe that ran the frame through the pass read BLACKS +100 moving its mean by 0.0001. Every rate below is now the largest its own move allows, measured rather than inherited: 0.058 -> 0.080 on BLACKS, 0.082 -> 0.113 on HIGHLIGHTS and 0.042 -> 0.080 on WHITES, with SHADOWS' 0.151 left where it was because it already bit. - `TONE_BLACK_LIFT` 0.7 -> 0.93. The ceiling is a FOLD, not a slope: past 0.9387 the doc's own square root carries luma backwards inside its window (0.94 folds 3.4e-6, 0.95 folds 8.9e-5) and a gradient wears it as a band. 0.93 is the last round rate under it — monotone on the check's 1/32768 grid, and the 1e-4 of travel between it and 0.94 is not a code value. - `TONE_BLACK_CRUSH` 0.85 -> 8.0. The doc's own form — `L * (1 + amount * W * 0.85)` — is bounded by its own window, which is 1 only AT the floor, so its whole visible travel at full -100 is 0.019 of luma: five code values on a black patch, and a rate past 1 drives the product negative and clips the toe to a flat black instead of deepening it. The toe's own EXPONENT, `L -> W * (L/W)^(1 + rate * W)`, is monotone for ANY rate and worth 0.054, while x = 0 stays on 0 and the 0.18 edge stays on 1 — both anchors and the compact support kept. - `TONE_HIGH_GAIN` 2.5 -> 14.0, with the head term moved from `(1 - L)` to `(1 - L)^2`. The linear headroom dies too slowly to keep the rate's own ceiling off the clamp: above a gain worth 2.6 the move overshoots 1.0, the clamp draws a plateau and the ramp falls back over it by 0.018 — the fold the knee check now measures as a drawdown from the running maximum. Squared, the move has died out by the time the ramp reaches the clamp: 14.0 is fold-free at both signs and still lands 1.44x of the 1.5x the quarter it owns is allowed. - `TONE_WHITE_GAIN` 1.5 -> 3.0, which takes the top of the ramp TO the ceiling from 0.92 up and leaves the clamp to flatten what is left. That is the doc's own §2.4, where a WHITE is the frame's clipping point ("giới hạn cháy sáng") and not a Hermite that cannot move the head; it is felt only above the 0.80 shoulder and the head is still exactly 1.0 on 1.0. `FILM_TONE` is re-solved for the squared head, which is worth less at the 0.75 knot for the same rate: monochrome -0.16 -> -0.1143 and mono-high-contrast +0.83 -> +0.5929. The four knots the stocks are tuned to do not move — 0.22 and 0.7375 on Acros, 0.17 and 0.815 on Acros HC — and the check pins each of them. The knee check's guard is REPLACED. The old one compared the first cell of the sweep against the second (a slope at 1/512), which is blind to a fold that starts later: it passed a ramp whose own drawdown was 0.018. The new one walks 1/32768 of the ramp and measures `running max - value` for each knob at both signs, over the four moves alone and then over a 243-combination sweep, so what is pinned is the fold itself and where it is. Two folds are pinned rather than removed, both named in the check: - SHADOWS -100 dips 0.018 (4.6 code values) around 0.06..0.11 of its own accord. It is the doc's §2.2 formula — `L *= 1 + amount * W * (1 - L)^1.8` — where the window rises faster than the light, and it PREDATES this change. The monotone rewrite (`L' = 1 - (1 - L)^(1 - SH * |a| * W(L))`) is written out beside it and was NOT taken: it is exact but it costs the knob 30-50% of its crush. - WHITE +100 rests a plateau on the clamp from 0.92 up. That is what §2.4 asks of the knob and the ramp is non-decreasing through it, so it is not a fold. `scripts/tone-base-check.mjs`'s mirror of the pass takes the same three moves (its own `toneBlack` and the squared head) so the pixel it predicts is still the pixel the pass draws. Checked: node scripts/highlight-knee-check.mjs; node scripts/tone-base-check.mjs; node scripts/auto-tone-check.mjs; node scripts/half-check.mjs; node scripts/mask-wb-check.mjs; node scripts/preview-match-check.mjs; node scripts/raw-develop-check.mjs; node scripts/white-level-check.mjs; node scripts/wb-table-check.mjs; node scripts/sharpen-check.mjs; node scripts/denoise-check.mjs; npx tsc --noEmit.	2026-10-02 10:54:54 +07:00
3dtours	76d84503c9	web: SHARPENING lifts only the edge it was pointed at, so a flat half of the frame keeps the grain it came with ... SHARPENING was the doc's §4.2 kernel with the two parts of §4.2 missing from it. `CLARITY_SKSL` evaluated the 3x3 unsharp mask with Mask = 1 on every pixel and no coring at all, so a flat sky, a cheek and a noise speckle all took the gain an eyelash took. That is `thay_doi_thong_so_giong_lightroom.md` §1 written out as a bug: "khi Sharpen, ảnh nổi đầy sạn hạt cát" — the knob could not raise the contrast of an edge without raising the noise of everything beside it, and on a grainy frame the second effect won. `SHARPEN_SKSL` is the doc's own line, `Image + Amount x HighPass x Mask`, with the two terms it names: - EDGE DETECTION: the Sobel magnitude G = sqrt(Gx^2 + Gy^2) on luminance, put through the doc's soft threshold smoothstep(T, T + 0.1, G). Flat fields read G = 0 and get Mask = 0 — the pixel is handed back untouched. - DETAIL (halo coring): a high-pass under SHARPEN_CORE is a speckle, not a detail, and is suppressed. The coring is soft (a ramp across the threshold, not a cliff) so a detail sitting on it is not switched on and off from one pixel to the next. The HIGH-PASS is the doc's Radius, held at one image pixel — 0.7-0.9px on a Retina panel — and it is a LUMINANCE high-pass carried by all three channels. A per-channel kernel sharpens a red edge against a green one and draws a colour fringe down every contour; the file's own §3 rule is to keep R/L, G/L and B/L where they were. `scripts/sharpen-check.mjs` pins the three properties the old kernel could not have: a flat field and a field of grain come back unchanged, a step below the threshold comes back unchanged, and a hard step moves apart on both sides while the flat halves beside it stay put. `CLARITY_SKSL` and `clarityUniforms` are gone with it, and the header note that said CanvasKit had two convolution steps to replace now says the one it has. Checked: node scripts/sharpen-check.mjs; node scripts/denoise-check.mjs; node scripts/tone-base-check.mjs; node scripts/highlight-knee-check.mjs; node scripts/auto-tone-check.mjs; node scripts/half-check.mjs; node scripts/mask-wb-check.mjs; node scripts/preview-match-check.mjs; node scripts/raw-develop-check.mjs; node scripts/white-level-check.mjs; node scripts/wb-table-check.mjs; npx tsc --noEmit.	2026-10-02 08:55:53 +07:00
3dtours	90a7ec9e46	web: NOISE REDUCTION takes the colour speckle out of the frame and leaves every strand of it where it was ... The knob was a `MakeBlur` image filter on the draw of the graded photo — one sigma over all three channels — so at NOISE REDUCTION 100 a 1024-pixel preview lost every edge finer than 0.6 of a pixel of its own and nothing brought the luminance detail back. That is thay_doi_thong_so_giong_lightroom.md §4's own warning ("Noise Reduction sẽ làm nhòe toàn bộ chi tiết sợi tóc và vân da") written into the engine, and the filter had a second cost: a paint filter is handed the shader's INPUT, so the pass could never read the graded pixels it was supposed to correct. It is a two-child pass now, NR_SKSL, run after the draw: the frame, and a blurred copy of it (blurredFrame — the snapshot read back through the same MakeBlur the ramp's base and the negative sharpening use). The output takes its CHROMA from the blurred child and its LUMA from the frame, the split the tone ramp's header already describes (`rgb - luma`), so the output's brightness is the input's at every amount by construction — the eye is nearly blind to a hue change at that scale, which is the whole reason the colour half is free. The reference reaches NR_CHROMA_SPAN = 0.4% of the frame's width, the doc's own 3..5 pixels of a full-resolution frame, where the knob's blur was 0.6 of a pixel. The luminance half of §4.1 (its bilateral filter) is deliberately not here: it is the half that costs detail and no frame has shown grain the colour half left behind. ponytail: add it as a second child of this same pass when one does. Checked: `tsc --noEmit` clean; `denoise-check.mjs` (new) compiles NR_SKSL on CanvasKit, asserts the engine still wires both children and no longer blurs the draw, and renders the pass at five amounts against a flat pair — amount 0 is the pixel exactly, amount 1 carries the neighbourhood's colour difference, and the luma never moves at any of them; `highlight-knee-check.mjs`, `tone-base-check.mjs` and `mask-wb-check.mjs` still green.	2026-10-02 08:14:25 +07:00
3dtours	e4f5407c19	web: each of the four tonal knobs moves its own band of the ramp and not the guard the four used to share ... BLACK, SHADOW, HIGHLIGHT and WHITE were four bumps summed into the identity, and the sum carried a guard: the two bumps of a half shared a slope, so past a total of 1 the curve folded backwards, and the ceiling that stopped it was shared by the amplitudes of a half. A stock already sitting on SHADOW therefore took BLACK's lift down with it — on the monochrome stock (sh = -0.24) BLACK at -100 came back with 0.663 of the travel the knob has on its own, which is the "kéo theo sự thay đổi của thông số khác" report exactly. thay_doi_thong_so_giong_lightroom.md section 2 asks for four WINDOWS instead: each knob owns a compact band of the ramp and is exactly zero outside it, and the four moves are applied ONE AFTER ANOTHER rather than summed. A composition of monotone maps is monotone by construction, so it needs no guard, and each knob then measures 1.00 of its travel on every stock. BLACKS is the doc's toe — u = clamp(1 - L/0.18, 0, 1) cubed, opened by sqrt(L) - L at 0.7 and deepened by 0.85, both of which are exactly zero at L = 0, so (0,0,0) stays (0,0,0): the grey pedestal that BLACK +100 left on a black was the sum adding its bump's height at the black point, which is the doc's own "Milky / Foggy". SHADOWS is the doc's bell over the deep tones, HIGHLIGHTS the bell over the bright ones, WHITES the doc's Hermite on the shoulder from 0.80. The ramp keeps its two anchors — 0.00 and 1.00 — at every setting of the four knobs. One deliberate departure from the doc: HIGHLIGHT carries a (1 - L) the doc's raw knee does not, because pow(L - 0.5, 1.5) added to L overshoots the cube above 0.94 — 17% of the ramp driven to flat white at +100 before the clamp. Read against the headroom that is left, the move is zero at L = 1 by construction and the head rolls instead of clipping. The windows are read in the sRGB-encoded luma this file already works in, not in linear light as the doc's section 1 sets out: the doc's own boundaries (0.18, 0.05..0.45, 0.55..0.95, 0.80) land as perceptual positions there, and moving the whole renderer to the linear domain is a bigger change than this pass. The divergence is the one the scratchpad compat doc already warns the Android port about, and it is noted at the windows themselves. Checked: `tsc --noEmit` clean; `highlight-knee-check.mjs`, `tone-base-check.mjs` and `mask-wb-check.mjs` updated to the four windows and passing; the twin ramp over a 1/512 grid is monotone to -0.00119 (0.30 code values, at t = 0.098 with every knob at full negative), both anchors hold for every combination, and a knob outside its band is the exact identity.	2026-10-02 08:11:32 +07:00
3dtours	bc550569ad	web: BLACK keeps the picture's texture and not the base it was read off, clarity stops the blur at an edge instead of at a colour, and a backup folder that refuses is handed back to the picker ... BLACK at full deflection returned a soft picture, and on a monochrome frame it returned the blurred base outright. The tone pass reads the ramp at the neighbourhood's base and then rebuilds the pixel, and it rebuilt it by the RATIO the base had moved by — `Base' * (Input / Base)`, the other half of fix_shadow.md's decomposition. A ratio is a gain, and that gain is a function of the neighbourhood: the knob that takes the base toward zero scales every pixel's detail by the same coefficient, so the knob that darkens the frame takes its texture with it. Measured on lightroom_shadow.jpg at 1024px through tone-sim.mjs, the pass in plain JS with the shader's own constants: at BLACK -100 the finest gradient came back at 0.75 of the input under the ratio and at 0.98 under the sum, while the frame darkened the same either way (mean 0.416 to 0.359 both). A monochrome stock is the whole frame of that error, because all three channels ARE the pixel's luma there, which is why the picture came back as the base — soft, and short of every edge it had. The reconstruction is `Base' + Detail`, ADDED and not scaled, and it costs nothing where there is no move to make: with every knob on zero the ramp at the base IS the base, so the difference is exactly zero and the pass is the identity however coarse the base is. A caller that hands in no neighbourhood at all — a mask — hands in the pixel's own image as its base and gets the global move back, which is what the ratio gave it too. `o` is held inside the cube before the detail is added, so a neighbourhood the ramp has pushed under the floor keeps the structure around it instead of carrying its pedestal down onto every pixel in the region. The bright side of the same move is untouched: the lift is still the neighbourhood's, and at SHADOW +100 the band above the lifted knot still keeps 0.81 of its spread where the global move kept 0.42. CLARITY drew a light stroke down every contour, and the reason was in what the blur called a neighbour. The range weight was the colour difference, `exp(-dot(d, d) * 24)`, which is loose on any coloured edge — two sides of a hair, a branch or a rail can share a red and differ in green — so the reference reached across the edge, and the reference is exactly what the blend subtracts. The wider it reaches, the more a contour reads as detail. It reads LUMINANCE now, one decision per tap at the doc's own scale (`CLARITY_RANGE_SIGMA` = 0.04), so an edge of any hue stops the blur dead. The blend moved the three channels by their own differences, which is what coloured fringing along every contour was, and the amount it moved them by was the MASK's `CLARITY_GAIN` borrowed for a different child. It moves LUMINANCE now — one value carries the whole pixel back with it, so hue is untouchable and skin does not go sallow at the top of the knob — under the doc's midtone weight M(L) = 4L(1-L), which deepens the greys a picture is made of and leaves the burnt ends and the deepest shadows where they are. The positive side's gain lives inside the shader (4.5, raised from the doc's 1.8 because the range weight above reaches less far and carries less detail): clarity-halo.mjs, which measures the pass pushing a pixel outside the range of its own neighbourhood, reads a bright stroke of 55.3/255 on lightroom_shadow.jpg and 54.3/255 on DSCF1701.JPG at +10, against the old pass's 145 and 127 at the same knob — and 8.0 already reads 98, so the knob does not need to go further to keep the flat areas moving. `exportEngine` passes the knob's own units now, `[clarityKnob / 10]`, since the gain and the sign are the shader's business and the mask's gain is not the frame's. And a backup folder the browser had stopped letting the page write to wrote nothing and said so, once, with no way back: a permission outlives the tab only while the tab does, so the row kept reading a permission of a moment ago while the write went to the disk without one. A refusal that names the permission, or the folder that is not there, now goes through the picker ONCE — the picker is the only thing that hands a folder back — and the run is repeated; anything else is the folder itself saying no, and is not asked twice. The sentence on the screen is one line over a strip of photographs and cannot carry a reason, so the reason goes to the console and a word of it into the note (`{why}`, the name the browser gave the refusal and never a stack), which is the whole of what tells a folder that was moved from a permission that lapsed. Both dictionaries learn the word. Checked: `tsc --noEmit` clean; `tone-base-check.mjs` and `highlight-knee-check.mjs` updated to the new reconstruction and passing; `tone-sim.mjs` on lightroom_shadow.jpg at 1024px for the numbers above; `clarity-halo.mjs` for the stroke.	2026-10-02 07:20:31 +07:00
3dtours	166a677590	light: the tone ramp is four bumps on the identity, not straight segments between five knots — a knot is an angle, an angle in a tone curve is a Mach band, and the wedge reads the seams: BLACK +100 broke at 0.030 with 105 of second difference, HIGHLIGHT -100 at 0.747 with 72 ... The ramp was a0..a4 with the pixel's base interpolated straight between them. A segment meets its neighbour at an ANGLE, and the second derivative of a tone curve is what a gradient reads as a band — so a knob left a line across the mid-tones, worst exactly where it was reported: BLACK +100 put its whole lift inside 0.25 and the stretch from 0.25 up came back identical to the untouched frame (the "transition stays grey" it was reported for), and HIGHLIGHT -100 folded a seam into 0.747, between the highlights it pulled and the shadow it left under them. Measured on a 1024-step luma wedge through the exported pass, second difference through a ±1% box: BLACK +100 read 105 at 0.030 against 0.000 from 0.25 up, HIGHLIGHT -100 read 72 at 0.747. Step of the first derivative across the knots: 0.955 at 0.25 and 1.146 at 0.75 — the curve arrived folded, and 1.146 is a sign flip, not a bend. So each knob is now a BUMP on the identity, peaking on its own knot — BLACK on 0.00, SHADOW on 0.25, HIGHLIGHT on 0.75, WHITE on 1.00 — with the kernel (1-u^2)^2 over a half-width (a half of the ramp for the two ends, whose knots ARE the ends, a quarter for the two heads). Level at u = 0, so a knot moves without a fold at its own top; level at u = 1, so a move lands on the identity and on its neighbour without an angle; C1 everywhere between. The two bumps of a half meet on 0.50 both on zero, which is the same fixed midpoint as before, and DR still moves the same knots (0.12 on the toe, 0.18 on the head, half of each on the heads beside them). A sum of bumps can overshoot where two steep sides land on one stretch — past a slope of 1 the curve runs BACKWARDS, a worse band than the seams this replaces, and it is reachable: DR alone was under it, BLACK and SHADOW +100 together were not (unguarded min slope -0.0141). The guard reads each pair at its own steepest points, 8/(3*sqrt(3))/w per unit amplitude (TONE_BUMP_SLOPE_HALF 3.0792, TONE_BUMP_SLOPE_QUARTER 6.1584), holds the two under one and gives them up together past it. A single knob never reaches it (a full BLACK is 0.77, a full SHADOW 0.77), so every slider keeps its whole travel; the worst case is DR at full, which gives up a tenth of its head roll (0.18 -> 0.8376 on the head), and BLACK with SHADOW both at +100, which arrive at 0.65 of their own lift instead of folding. Guarded, the sweep over five levels of all four knobs and DR reads a min slope of +0.0183 and a max of 1.9937, with the largest slope jump 0.00005. After: the same wedge, the same pass. The knot steps are 0.096 at 0.25 and 0.478 at 0.75, with no sign flip — C1 across the knot instead of a fold. BLACK +100 now carries the rework out of its own quarter: +0.139 at 0.25, +0.101 at 0.30, +0.033 at 0.40, 0.000 at 0.50, where it used to read 0.000 from 0.25 all the way up. HIGHLIGHT -100 keeps its lift (-0.126 peak against -0.121 before) and spends it over the quarter instead of into a line. Every knob on zero is the identity to the last bit — the pass also runs for the stock split tones and for DR alone — and 0.50 is still the one value no knob moves. Checks: tone-base-check.mjs now runs the bump and the guard as arithmetic beside the shader (with the negative control: the unguarded pair still folds, the guard is what stops it). highlight-knee-check.mjs reads the kernel and the two slope constants off the source, pins the four amplitudes and the guard, and sweeps the travel of every knob as before. All ten checks that run without a browser pass, build clean. Skipped: the guard's ceiling is a constant, not a search for the widest travel that still clears a band we cannot see. Add when a frame shows a band the deflections in hand cannot explain.	2026-09-30 21:24:01 +07:00
3dtours	097e383b86	light: the tone base is a real blur, not nine point samples of one — the ring aliased the luma and the ramp painted the alias back as mottle ... The base layer shipped last commit was nine POINT SAMPLES of the child, one ring out at TONE_BASE_RADIUS. A ring is not an average, and on a frame with texture at the ring's own scale it is worse than one: the nine lumas differ, the sample pattern beats against the texture, and the base field comes out aliased. The gain the pixel then rides, o(base)/base, is a function of the base with a kink at every knot — so each alias of the base becomes an alias of the gain, and the reconstruction paints it straight back over the detail it was supposed to leave standing. Reported on a waterfall: grey patches loose on a mountainside, a smear across the face of the falls, and plateaus in cloud and sky (the pass runs whole-frame, so its base is read in the bright end too). Measured, 1160x774 at SHADOW +100, the high-frequency part of the gain field (9px high-pass, where a real base can hold none): 0.0627 for the ring, 0.0048 for a blur of the same radius. Thirteen times. The fix is not more taps — a 7x7 at a third of the step is still point samples, only smaller — it is to stop sampling: the caller blurs. So the base is now a second CHILD of the tone pass, the frame blurred by Skia's own MakeBlur (blurredBase in exportEngine.ts, the draw drawBlurred already made for the sharpening pass) at TONE_BASE_RADIUS of the frame width and sigma TONE_BASE_SIGMA of that radius — a box's equivalent at the radius, so the neighbourhood is the one the radius always named and the cuts are smooth instead of hard. The shader reads it ONCE per pixel and baseLuma loses its loop and its `bx`. That is also the cheaper pass: nine child evals walked the exposure/matrix chain nine times, one eval does not. A caller with no frame to blur hands in the image it is already shading as the base. The tap then lands exactly on t and the ramp is the global move again — a mask's degenerate bx of zero, spelled as a child that IS the source, which is what gradientMask.ts's own call (base == t) already meant. Checks: tone-base-check.mjs is new — SkSL is only compiled at runtime and nothing here compiled TONE_SKSL whole, so the pass is compiled and rendered for real, with the frame and the base held at two flat values a little apart: the pixel has to land on the value the ramp over THAT base predicts (171 for a 128 pixel over a 76 base), and a base equal to the pixel has to be the identity. highlight-knee-check now pins the one tap, the absence of `bx`, the blur, and the two-child wiring. 9/9 pass, build clean. Skipped: no guided filter proper — the base is a plain blur, so a strong edge is no longer held out of it the way the range weight held it (a dark rock a blur's width from the water reads a lifted base and keeps its own darkness). Add when a frame shows the halo; the doc asks for a plain blur and this is one.	2026-09-30 19:03:55 +07:00
3dtours	e61dccc784	light: the tone ramp is drawn through a base layer, not the pixel, so a SHADOW lift moves the region and leaves the texture in it standing — the quarter above the knot came back at 0.57x of its own spread, 0.78x now ... The four knots were read at the pixel's own luma, which makes the ramp a global curve: every pixel at luma t lands on the same o whatever surrounds it. SHADOW's a1 is the head of the quarter above it, so lifting it squashed that whole quarter to the half slope left over — measured on a real frame, 0.50 of its spread (shadow-band.py), 0.57 on the deployed bundle — the grey sheet the knob was reported for. A curve drawn through the pixel cannot see local contrast; that is what the eye was reading. So the ramp is read at TONE_BASE_RADIUS (2.5% of the frame) of the luma around the pixel — a 3x3 range-weighted blur, the fix_shadow.md Base x Detail split — and the pixel then rides the neighbourhood's gain o/base, keeping its own difference from it. Base moves, detail stays: the same lift on the same pixels, with the texture inside the region left standing. Full deflection keeps 0.78 of the band's spread now. The base is the same maths in every caller: bx = 0 (a mask, which has no neighbourhood) reads the pixel nine times and gets the old global move back, and with every knob on zero the ramp at base IS base, so the ratio is 1 and the pass is the identity however coarse the base is. Skipped: no chroma compensation (Hunt). Measured, the ratio held saturation (0.3184 -> 0.3169), so it is not earned yet. No linear-light ramp either: the multiply is a uniform gain on encoded values, which is the same stop exposureMove already argues for.	2026-09-30 18:46:36 +07:00
3dtours	25b1312e0a	light: AUTO and the shipped recipes ride the halved knobs too — AUTO's ceiling doubles with them so a blown frame still comes back the way it did, and each recipe's HIGHLIGHT/SHADOW doubles so its look stays on the knot it was tuned to	2026-09-30 18:10:51 +07:00
3dtours	a56581c757	light: the HIGHLIGHT knob rides half its anchor too, so a lift stops drawing a cloud to paper and a pull stops flattening the quarter under it — the top quarter came back at 0.26x of its own contrast, 0.62x now	2026-09-30 17:59:57 +07:00
3dtours	36fb93658b	light: the SHADOW knob rides half its anchor, so a lift stops drawing the band above it flat — a waterfall's spray came back at 0.10 of its own contrast, 0.55 now	2026-09-30 17:36:29 +07:00
3dtours	851563ed73	light: the pixel rides o/t, not a held chroma — SHADOW and BLACK drained a dark red to 0.505 of its saturation, it is 0.742 now	2026-09-30 16:26:42 +07:00
3dtours	cc186c4d09	The trial gets a date and WB's presets get a table ... Two asks, one row of the studio each. The first is copy: a band under the header, the same shape the verify bar below it takes, saying which features are on trial, on whom, and until when. It is a notice and not a task, so it wears the plain surface rather than the accent, and it carries no dismiss: the date is the message. The string is in the dictionary like every other, Vietnamese as written and English beside it — the band is one line at both lengths in a 1440-wide window, and it sets no nowrap, so a narrow window wraps it rather than cutting it. The second is the WB panel's presets. They were a wrapping strip of seven identical pills, which is the wrong shape for one kind of value read against the others: nothing about "SHADE" said 7500K, and nothing about the row said which end of the scale anything was on. They are a TABLE now — two columns of buttons, laid out as a grid — and each button is painted with the cast it puts on the frame: the same swatch the TEMPERATURE ruler already prints under its track (temperatureSwatch, the engine's own gains on a mid grey, halved), so the button and the ruler cannot disagree, and the kelvin is printed on the button beside the name. A button that is a swatch cannot use the theme's text colour for its label: the fill is a mid grey by construction, and mid grey is exactly where white and the light theme's near-black both sit near the 4.5:1 line. So the label is given the ink that fill can carry, chosen by WCAG's relative luminance against black and against white — whichever of the two ratios is larger, which is the one that cannot fall under 4.5:1. The border is that same ink, which is what makes a button stand out from the page it sits on and from the six beside it; the accent takes the border over while the preset is the one in force, since the fill can no longer say so. Both the fill and the ink ride in as inline styles — they are the value, not the theme — so the chip needed two fields and a tinted class, and the row needed a grid mode. The TEMP strip reads the same two fields through choiceChips, because the same seven presets are painted in both places and two opinions about 3200K is the bug this would have been. The chip's own value slot is deliberately unused here: `.chip .val` sets its own dim colour, and a dim grey on a mid grey button is the failure this commit is about. Verified: scripts/wb-table-check.mjs — readableInk picks the better of its two inks for black, white and four mid greys, all 151 swatches across the ruler (2500..10000K, every 50) and all seven presets clear 4.5:1 under the ink they are given, the swatch runs the way the ruler does (red up, blue down, #517eff at 2500K to #947d61 at 10000K), and the seven presets collapse to the five fills their kelvins do. In the running app through a probe: the notice prints in both languages (Vietnamese one line, unclipped), 7 buttons in a 147px + 147px grid, TUNGSTEN filled rgb(98,130,187) with ink rgb(11,14,18) and a 2px border of the same, AUTO the accent border rgb(206,117,9) while it is the preset in force, and the panel holds at 420px wide without overflowing. The panel was viewed in both themes. npx tsc --noEmit clean, npm run build clean. Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-29 20:21:08 +07:00
3dtours	899921ef8a	A dark detail stops being copied beside itself: DEHAZE reads its prior off a copy of the frame ... Raising DEHAZE drew bright copies of every dark detail in the photo, stacked alongside it. The prior was the reason, and the prior was read wrongly. The 5x5 patch of DEHAZE_SKSL was sampled inline, five taps out at 0.625% of the frame's width each — one tap every 6.67 pixels of the 1067-pixel preview, an average spacing over a 26-pixel patch that is meant to be the minimum over it. A detail thinner than that spacing therefore sat between two taps on one row and under a tap on the next, and the transmission swung between "this patch holds a shadow, leave it alone" and "this patch is all haze, divide hard" with a 7-pixel period around every dark thing on the frame. A rising DEHAZE drew that period: `t` is a per-pixel divisor, so the rows of the detail that were left alone stayed put while the rows read as haze came up bright, and the 13.3-pixel column spacing made the next copy and the copy after that. That is what was stacking. Measured on a synthetic frame of sloped haze with four one-pixel dark lines: the old shader departs from the clean correction by +58 to +102 codes (8-bit) at exactly +/-6.67 and +/-13.3 pixels around each line — the two spacings, in both directions, which is the whole signature of the bug. That frame is otherwise flat, so those deviations are the copies. Three things had to be got right, and each is the smallest fix that removes one of them: - The patch is no longer sampled. The caller builds the dark channel as an image — a 64x64 copy of the frame, smallest channel over a cell-wide neighbourhood, then two box passes — and hands it to the pass as its second child, so the shader's own `dark.eval` IS the patch: one cell covers a whole neighbourhood rather than sampling it, and the bilinear upscale interpolates it back up with no period left in it. The box passes are the doc's soft matting in the one form free here — the map is smoothed, not the pixels. The copy is made with drawImageRect, rect to rect: a paint shader drawing a 64x64 rect reads only the source's 4x4 corner, and a one-pixel line in such a copy lands at 166, i.e. pure haze, because the cell covering it is mostly sky. - What travels as that image is the dark channel and not the transmission. t is 1 + 0.95 at the negative end of the knob, more than a channel can carry, so a copy of t would arrive here clipped to 1 and "put the scattered light back" would become a pass that returns its input. The dark channel is 0..1 by construction and the signed amount stays a uniform, where it costs no range — the knob keeps both of its directions. Swept on the real photo, DEHAZE -100 moves 779,237 pixels brighter and 703,114 darker (worst 110 codes) while the same frame at 0 either side of it moves exactly none, and +100 moves the frame the other way at atmosphericLight [0.93155, 0.90980, 0.93084]. - The pass was reading a shader that does not exist yet. `effects()` is what it asks now, not the module variable: nothing above DEHAZE has asked for the effect, so on the first render the variable is still null and the knob stayed dead until some later render happened to fill it in. A map this small only covers the frame if it is told to, and the matrix that does it is the last thing that had to be right: CanvasKit reads a shader's local matrix as the map's own pixels to the frame's, so the 64x64 copy needs frame over map, `[W/64, 0, 0, 0, H/64, 0, 0, 0, 1]`. Without it the pass covers only the top-left 64 pixels and clamps every pixel past them onto the map's last texel — one constant t over the whole photo, a global inversion and not a dehaze. Measured against the ideal ramp, `scaled(n/w)` clamps the same way; the reciprocal lands on it. The knob is left to over-correct at the top of its range, and that is deliberate. A hazy sky still goes white and a saturated colour beside a dark edge still deepens: `(c - a)/t + a` with an airlight near 0.93 and a plain clamp, which is the arithmetic the doc asks for. It is smooth on the frame — 6x zoom panels of the hazy frame at DEHAZE 100 show one wide gradient and no band repeating at any period — so no knee is added to soften a correction that is no longer producing the symptom. If that side ever needs taming, DEHAZE_MAX_OMEGA is the one number. The MASK's DEHAZE still samples the old 5x5 patch inline (gradientMask.ts, unchanged): the frame-wide pass is what the report was about and what is fixed here. Verified: the synthetic harness over four patch configurations puts the new shader at zero deviation from the clean correction at N=64 — the 16.7-pixel cell swallows the test line, which is why the real photo is the judge. The real photo through the running app, with the slider swept 0, 100, -100, 0, is exact at both zero points and moves the frame at both ends, and its zoomed panels at DEHAZE 100 — roof, floor and a wooden rail at 3x and 6x — show the remaining change as one smooth region, the blue of a tarp and the green of a floor stain deepening where the haze was hiding them, with nothing repeated around the dark detail that used to copy itself. npx tsc --noEmit clean, npm run build clean, scripts/mask-wb-check.mjs and scripts/highlight-knee-check.mjs both pass. Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-29 20:02:35 +07:00
3dtours	6d60d452e0	One move of the light for the whole app: a mask's EXPOSURE and its four tone knobs stop being a second opinion ... A gradient mask had its own tone formula and its own exposure, and both disagreed with the frame's. Before any of this was tidied, the mask ran a smoothstep luma lift with an arbitrary 0.55..1.35 chroma clamp while the frame moved the knots of a four-zone ramp, and the mask's exposure was a stop on sRGB-encoded values while the frame's was a stop on light. Two names, four moves, and the same slider meant different things depending on whether the pixels were inside the shape you drew — the divergence §3.3 of the Android port's compat doc warns about. The maths is one string now (TONE_MATH_SKSL, interpolated by both passes): the ramp the four knots build, the hue-preserving rebuild behind it, the transfer pair, and exposureMove. A mask calls the same functions the frame calls. The rebuild carries the chroma instead of re-scaling it. Lightness takes the curve and the colour rides the difference — the channel differences move by ONE shared scale k, pulled back only where the cube has no room left. The doc's ratio (R_new = R_old * Luma_new / Luma_old) was the old reading and it is exact only while nothing clips: a channel past 1.0 stops being scaled with its neighbours and the hue goes with it. Measured on a flat patch frame, a skin tone at 24.0° came back at 48.0° at HIGHLIGHT +100, a warm white at 37° at 57.4°, and under L = 0.5 the same ratio multiplied a near-black pixel's cast by x30 — colour noise amplified, which is why the 0.55..1.35 clamp was there. The scale is the chroma's own now: over 135 knob combinations on seven colours and five greys, the ramp moves the luma and the hue does not move at all (Δ < 1e-9°). EXPOSURE gets the same treatment, which is what the second half of the request was: the linear domain decides where the luma is going, and the pixel is rebuilt onto it through the same lightMove. The old pass multiplied the three channels in linear light, so +1 EV clipped them by three different amounts: measured on the scratchpad probe, 29.2° of hue drift on a skin tone at +1 EV and 33.3° at +2, against 0.00° here. The stop is applied as a ratio on the pixel's own encoded luma rather than pointed straight at the encoded linear target, which is what makes the knob exactly the identity at 0 EV — the transfer does not commute with the luma weights, so pointing at it brightened a colour by a couple of code values even at zero. A grey is the knob it always was: 128 through +1 EV is 176, the same number the linear per-channel multiply put there, so nothing a user has dialled in moves. Verified: `npx tsc --noEmit` clean, `npm run build` clean. highlight-knee-check now runs EXPOSURE_SKSL for real — compiled with CanvasKit and four pixels pushed through it, agreeing with the twin to a code value on a grey at +1 EV (176), a skin tone at +1 EV and +2 EV, and a shadow at -2 EV; it also pins the hue, the cube, the identity at 0 EV and the black pixel that has no light to move. mask-wb-check compiles the mask pass and pushes the same stops through it: 128 through +1 EV is 176, through -1 EV is 92, +2 EV lands the channel on the ceiling at 255 and holds the hue within 3°. auto-tone-check, preview-match-check, white-level-check, raw-develop-check, half-check and roll-walk-check all pass. Live on the built bundle in a 1440x950 browser: the LIGHT panel's EXPOSURE +1 EV takes the mid grey of a flat patch frame from 0.502 to 0.690 (a stop on light gives 0.686) and moves no patch's hue at -1 EV (Δ 0.00°), and a linear gradient mask's EXPOSURE +1 EV and HIGHLIGHT +100 move the pixels inside the mask (luma 185.9 -> 211.1 and 185.9 -> 197.5) while the corner outside it does not move at all (220.2 -> 220.2), with no console error. Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-29 18:04:50 +07:00
3dtours	3b92e4e2d2	A gradient mask can carry the LIGHT column's white balance now: COLOR TEMP and ... TINT, the same two rulers, read on the mask's own pixels. The pair was asked for as the two rows the develop column already has, so it is the same pair and not a second opinion about what a kelvin means: the gain comes from one function, colorUtils.whiteBalanceGain(temperature, tint), which the frame-wide colour matrix now calls too — the RGB kelvin fit of kelvinToRGB, the symmetric ±0.08 magenta/green tint, and the division by the product's own Rec.709 luma that keeps a cast from being a brightness move. A mask that never touched the pair reads 5500K / 0 (readMasks' own defaults, clamped to the ruler's ends), whose gain is exactly (1,1,1), so nothing moves and every recipe stored before this reads the same. The measured rule holds inside a mask exactly as it does on the whole frame: at 10000K the mask's pixels came out R/B 1.25 -> 1.72 against 0.994 -> 0.994 outside it. The Kelvin fit is a curve, so it is resolved on the JS side and handed over as a gain: maskUniforms grows one more float4 array (wb[i], three gains and a zero pad) between the spatial pair and the frame size, in declaration order like every other array in that buffer, and the shader multiplies the mask's colour by it right after EXPOSURE — one clamp, three multiplies by one for a mask that leaves the pair alone, and no second copy of the fit in SkSL. The spatial build is a second shader text with a second signature and reads the same array. App.tsx draws the rows where the panel's other rows already are, and TINT rides the existing maskKnobRow helper: same store unit (±10), same ±100 slider the frame-wide row wears since the develop knobs were deepened. COLOR TEMP keeps its own scale (2500..10000, step 100, "10000K"), because a temperature is not a percentage, and it carries the same swatch the frame-wide row paints. Verified: npx tsc --noEmit; npm run build; the repo's check set (highlight-knee, auto-tone, half, white-level, preview-match, library, scan-nav, roll-walk) all pass; and scripts/mask-wb-check.mjs, which is new here — it transpiles the gradientMask graph into a temp dir and checks the gain (neutral at 5500K/0, warm at 10000K, cool at 2500K, luma-preserving, ±TINT symmetric), the clamps, the uniform offsets (the gain lands where the shader reads wb[i], the frame size one array further on), and then compiles the real shader through CanvasKit and pushes a mid-grey through it: neutral leaves 128, 10000K warms it, +TINT magenta-ises it, and both the plain and the spatial builds and a two-mask list read it. The UI was driven on the built bundle too (a linear mask dragged on the preview, then the two rulers moved through their own range inputs): the mask column reports 11 rows, opens at 5500K / 0, takes 10000K and +40 ±100-scale TINT, the swatch follows, and the preview's own pixels warm inside the mask and nowhere else. ponytail: the mask's WB is not skipped for monochrome stocks the way the frame-wide matrix skips it — a local kelvin on a B&W frame is a tint someone asked for by hand, not the colour leak that rule exists to stop. Add the same isMonochromeBase guard (and pass the base filter into maskUniforms) only if that turn out to read wrong on a live B&W recipe. Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-29 17:35:19 +07:00
3dtours	bd57dd72b3	EXPOSURE reads in stops: -5..+5, two decimals, on an unchanged store ... The tone spec draws EXPOSURE as `min="-5" max="5" step="0.01"` with a `0.00` readout, and the app's row was still the original whole-unit knob: -10..+10 in one step, printed as a bare `+2`. The recipe file behind it has always carried units where one unit is EV_PER_UNIT = 0.25 of a stop, which is the same ±2.5 EV travel, so the two are the same range said two ways. The def now talks stops on its face and units in the store: `min: -5, max: 5, step: 0.01`, a `twoStops` readout (`0.00`, `+0.50`, `-0.25`, no unit because the label is the unit), and accessors that translate — `get` multiplies by EV_PER_UNIT, `set` divides and rounds to 1/10000. EV_PER_UNIT is exported for that one use. Because the ×10 of `deepen` is not applied here and the store's field is untouched, a recipe that shipped with EXPOSURE 2 still means the two units it always meant: nothing gets brighter or darker, and half a stop is still 2 units in the file. The knob steps by 0.01, which is 0.04 units — the slider can express a quarter stop where the old one could only express quarter stops, and everything between them. TINT and TEMPERATURE keep the web's ranges (tint ±100 on the ±10 store scale, temperature 2500..10000 K). The spec's ±150 tint and its 2000..50000 K temperature were reviewed and left as they are: the tint at ±100 is already what `deepen` publishes and the wider pair would move stored looks. Verified: - `npx tsc --noEmit` clean; `npm run build` clean. - Repo checks re-run green: `highlight-knee-check`, `auto-tone-check`, `half-check`, `white-level-check`, `preview-match-check` — the last two render real looks through the engine, so a shifted EXPOSURE scale would have shown up as a brightness change in recipes that carry a non-zero one. - Live browser pass on the deployed build: the row reports `min=-5 max=5 step=0.01`, prints `+1.00` at a full stop, `+0.01` at a hundredth, `-0.25` at a quarter stop down and `0.00` at rest, and EXPOSURE +1.00 still lifts the graded frame (mean luma 184.3 -> 203.4). ponytail: the CREATE RECIPES form (RecipeCreatePanel) still edits a sim's raw adjustments in store units, EXPOSURE included. Leave it there until that form is asked for stops: it is a store editor, not the develop panel, and every field on it is in the same units. Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-29 17:09:01 +07:00
3dtours	c0aaa67361	Studio: fold WB and FX into LIGHT, and put every develop slider on -100..+100 ... WB and FX were separate tabs whose only content was the same Lightroom-style develop column LIGHT already renders, so the rail carried three doors into one room. LIGHT now owns the whole column: white balance, tone, presence, the effects group (grain, dehaze, vignette) and the filters, in that order. The `wb` and `fx` TabIds, their rail entries, their `wbLabel()` helper and the now dead `tab.wb` / `tab.fx` i18n keys are gone; `ToolRail` documents eight tabs. Every continuous develop value that the UI exposes as a symmetric knob now runs -100..+100 instead of -10..+10. `paramDefs` gains the `HUNDRED` key set and the `deepen` helper, which widens a def's range and scales its accessors by ten, so the store keeps its -10..+10 internal scale and every stored look, DEFAULT_RECIPES entry and URL round-trip is byte-identical. Params with a meaningful physical scale (temperature in kelvin, exposure in EV-ish units, grain, grain size, hdf, vignette, rotate, crop) keep their own units. Highlight recovery no longer bends hue. The old knee clamped the per-channel gain into 0.55..1.35, which is a per-channel operation and therefore a hue rotation: on the flat skin patch it walked hue from 24 deg to 48 deg at HIGHLIGHT +100, and on a saturated 30:1 chroma ramp it desaturated toward black instead of toward white. The shader now caps the pixel's distance from its undersaturated knee point while preserving the direction of that offset, i.e. it scales chroma and keeps hue, then clamps into gamut. Verified: - `npx tsc --noEmit` clean; `npm run build` clean. - `node scripts/highlight-knee-check.mjs` (pins the new shader source and twin-tests 135 knob combinations) ok. - Existing checks re-run green: `auto-tone-check`, `half-check`, `white-level-check`, `preview-match-check`, `library-check`, `scan-nav-check`, `roll-walk-check`. - Live browser pass: rail shows exactly the seven expected tabs with no WB or FX; LIGHT renders 5 panels / 23 `data-key` knobs; 12 knobs report `min=-100 max=100`; everything else keeps its own range. - Highlight hue measured on ten flat colour patches: HIGHLIGHT -100 gives a hue delta of 0.00 deg on every chromatic patch; HIGHLIGHT +100 stays within 0.22 deg (sky) and 0.28 deg (magenta) wherever chroma survives, and the patches the ramp intentionally drives to white arrive fully neutral. Greys stay neutral (channel spread <= 2/255) at every knob setting. Skin patch before/after: 23.94 deg -> 0.00 deg. ponytail: temperature (2500-10000 K), exposure (+-10 units at 0.25 EV each), grain, grain size, hdf, vignette, rotate and crop deliberately keep their own scales rather than the blanket -100..+100; widen them the day a user asks for more range, not before. Hue assertions live in the flat-patch check because real-photo measurements pick up 2-4 deg of resample drift from the snapshot pipeline that has nothing to do with the shader. Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-29 17:04:08 +07:00
3dtours	34f8601c91	studio: the develop column becomes five panels, and the four tone knobs move knots instead of channels ... Two specs, one commit: the develop state becomes the panel column the Lightroom spec draws, and HIGHLIGHT, SHADOW, WHITE and BLACK stop being edits and become shapes of the tone curve, the way the mapping spec measures them. The column. The left rail used to hand LIGHT a row of chips and nothing else; the four tone knobs were chips that opened a curve, and the rest of the develop state lived in the chip row's own vocabulary. `DevelopPanels` renders the five sections of the spec instead — PROFILE, WB, TONE, PRESENCE, DETAIL & EFFECTS — as an accordion, all open, and every parameter the recipe holds has a row in it with a `data-key` off the parameter name: slider, value readout, double-click to default. Sliders are always visible, so a knob is one drag away instead of two taps, and TEMPERATURE and TINT draw their gradient underneath (blue through amber, green through pink) so the direction is on the control. The PRO looks the spec marks stay in the list but locked, tagged PRO, and tapping one asks for PRO — they are shown, not hidden, and not silently dropped. WHITE and BLACK move out of the WB group. They were the temperature group's extremes, which is what a white balance control does — the toe and the shoulder of the same ramp — but the spec puts them with the tone knobs and gives them the two ends of the tone curve, and that is what they now are. `wb` is TEMPERATURE and TINT and nothing else; `whites` and `blacks` sit in `iq` beside `highlights` and `shadows`, labelled WHITE and BLACK, in the tone panel where the slider lives. A recipe written before this commit still reads: the keys are unchanged. The four knobs. The first pass of the mapping spec added a mask per zone onto the channel: `luma += knob * mask * intensity`, and the shader followed it. It is the wrong shape, and the twin harness in `highlight-knee-check.mjs` shows why — the four masks are not a partition of the ramp. They sum to one at the ends and to zero at the midpoint, so an adjustment in the middle of a zone is applied where the mask is half and not at all where the mask has fallen to nothing, and the ramp inverts: with every knob at its stop the curve folds over itself, slope −5 at t=0.87, and the twin catches it as a non-monotone ramp. So each knob moves a knot on the curve instead, which is the reading the spec's own mask geometry points at — BLACK peak at 0.00, SHADOW 0.00→0.25→0.50, HIGHLIGHT 0.50→0.75→1.00, WHITE peak at 1.00 — and the shader builds the curve through those four anchors. `TONE_ANCHOR` is 0.25: one full knob at its stop is a quarter of the range at that knot, so the range is 0.75..1.00 at the top and 0.00..0.25 at the bottom, and the anchors stay ordered (`a0 ≤ a1 ≤ 0.5 ≤ a3 ≤ a4`) by clamping each against its neighbour. Between knots the curve is a straight line, and 0.5 is untouched by every knob, so a knob at zero is the identity exactly rather than nearly, and any combination of the four is monotone. The mask sum survives where the spec is right about it: it hints the split between the two dark zones and the two light ones, nothing else. The hue is kept the way the spec keeps it: work in luma, then scale the chroma offset — `rgb = luma_new + (rgb - luma_old) * luma_new / luma_old` — so a saturated red stays the same red and only its brightness moves. The ratio is clamped to 0.55..1.35 because at luma near zero the division is the whole highlight of the picture on one code value. Verified: - `node scripts/highlight-knee-check.mjs` passes. It pins the settled shader — four masks, four anchors, the four `mix` lines — and asserts the constructions it replaced are gone, then drives a twin of the ramp in JS: the masks do not overlap, every knob at zero is the identity, the midpoint is 0.5 for all 162 combinations of the four knobs, every combination is monotone, the amplitude at each stop is a quarter, and the DR offsets land on 0.12 and 0.82. The folded case from the additive build is in the harness as a regression. - `npx tsc --noEmit` clean; `npm run build` emits `index-DXIIw2F1.js` and `index-A4pA1U5f.css`; `library-check.mjs`, `scan-nav-check.mjs`, `roll-walk-check.mjs`, `auto-tone-check`, `half-check`, `preview-match-check` and `white-level-check` all pass against the bundle — the catalogue, the RAW path, auto tone and the white level are untouched by the panel move. - Driven in a real browser (`tone-live-check.mjs`, Chromium against `vite preview`, a P1010256.JPG in the source control, mean luma of the preview canvas read before and after each knob): neutral 184.25, WHITE +1 187.35, BLACK +1 186.35, SHADOW +1 194.53, EXPOSURE +1 206.99, HIGHLIGHT −1 173.80. Every knob moves the picture the way the spec says it should and none of them moves it much — a stop of a knob is a quarter of a zone, not a level. - The same run asserts the built DOM: five panels, the 23 `data-key` rows, `dev-temperature` in WB, `dev-whites`, `dev-blacks`, `dev-highlight` and `dev-shadow` together in TONE, the gradient classes on the two white balance sliders, and the chip slots the panel is handed. The only failed request is `/api/events`, which is the backend this preview does not run. ponytail: the recovery of blown highlights that used to sit under HIGHLIGHT — a per-channel rolloff in linear light — is gone, deleted rather than ported. The additive mask is why it was there: HIGHLIGHT had to do two jobs because a mask could not shape a curve. Now that WHITE owns the top end, HIGHLIGHT only bends, and the per-channel rolloff is a second knob for the same picture. Bring it back as its own parameter if a frame ever clips badly enough to need it. Also dropped: DR used to ride along as two additive terms. That is where the fold at t=0.238 came from, BLACK −1 and SHADOW −1 together — the two terms pushed the ramp past its own end. It shifts the knots now, which is what the film sims always meant by it, and the numbers in the sims were kept and their meaning recommented (classic-chrome toe 0.22, head 0.7375, etc.). Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-29 16:38:56 +07:00
3dtours	224ff0b935	web: open a RAW at the resolution of its sensor, not at the quarter of it ... LibRaw's half-size demosaic was on. The Ricoh GR's own DNG (D0004128.DNG) developed to 3010x2012 while the JPEG written beside it in the same second is 6000x4000, and the Fuji's RAF to 3008x2007 against its own 6000x4000 -- the quarter was the flag, not the file. With `halfSize: false` the same develop returns 6020x4024 and it is the sensor's frame on every body tried: D0004128.DNG 6020x4024 IMGP6916.DNG 6028x4024 DSCF1701.RAF 6016x4014 _DSC0009.ARW 6024x4024 AFXT2721.RAF 6246x4170 Nikon-D850 NEF 6216x4136 _GDN0447.NEF 4284x2844 P1010607.RW2 3472x3472 5G4A9396.CR2 2880x1920 Nine files, 27s to 155s a develop on one core. Checked through the app itself, not only through LibRaw: photo-dims 6020x4024 on the DNG against 6000x4000 on the JPEG, both err none. The colour it opens with is now fitted per file to the preview the camera wrote into it (previewMatch.ts): a 3x3 over a block grid of the develop against the same grid of that preview, then one cubic a channel for what the 3x3 leaves. The offline per-body table this replaces (cameraMatch.ts) stopped matching the moment the path under it changed -- its rows no longer summed to 1 once the highlight knee landed ahead of it -- and a body with a row opened with a cast one without did not. The file's own preview does not age. The white level the gain carries is the frame's own plateau rather than `maximum` (sensorWhite.ts), a factor of 1.89 to 2.00 out; without it every frame opened a stop bright and a body that sat lower (X-Trans, 1.892) never reached the highlight desaturation at all. The desaturation gate reads the gain-lifted levels as well as the sensor's, which is the whole of the magenta: on a body whose cam_mul lifts red and blue (the GR's [2.64, 1, 1.73]) a blown sky crosses the white level at 0.38 of the raw range in red while green crosses at 1.0, so a gate read on the sensor's levels alone stayed shut across it. Measured in the app against the camera's own JPEG, mean dRGB over a 16x16 block grid: +1.20, -5.95, -6.11 with the sensor's clip alone, +0.21, +0.24, +0.47 with both, mean |dL| 21.5 against 10.3. The same grid on the Fuji comes back balanced (+4.7, +5.0, +3.6) and best aligned at offset 0,0. -HL is recovery and +HL is a lift, so they are different moves now: recovery is the doc's soft knee in linear light over the top half, which is the only term in the tone shader that is not a shift and the only one that can put detail back into a blown sky rather than merely darken it. The four checks pin the develop down where it can only run in a browser: raw-develop-check, preview-match-check, white-level-check, highlight-knee-check.	2026-09-28 15:24:37 +07:00
3dtours	9164bf3228	web: read DEHAZE off the dark channel, and let it run both ways ... DEHAZE read its haze estimate out of the frame's own bilateral reference — the patch AVERAGE — where the Dark Channel Prior asks for the patch MINIMUM. That one word is the whole prior: `dark = min(min(r,g,b)/A)` over a neighbourhood reads 0 for any patch that holds a shadow or a black frame line, so the transmission stays at 1 and the patch is left alone, while the average of a patch that holds a dark pixel is still bright, so every patch looked hazy. The positive end therefore ground the frame down instead of taking haze out of it: at +9 the mask moved its own middle band -0.2127 and the frame-wide row moved the whole frame -0.2311, and the local contrast went the WRONG way (dhp -0.0060 on the mask, -0.0056 frame-wide) — a haze remover that lowers contrast is a haze remover that is lowering everything. The pass reads the dark channel from the image it is correcting, five by five taps at DEHAZE_PATCH_STEP (0.625% of the frame's width per tap, a 2.5%-wide patch — the DCP's own 15 pixels on a 600px frame, and the same fraction of a 4000px export) in DEHAZE_SKSL and in gradientMask's block, so the mask and the frame-wide row are the same neighbourhood at every render size. Five by five rather than fifteen by fifteen because 225 child reads per pixel is what CLARITY_BLUR_SKSL already refused for a reference the prior does not need to be that wide. The bilateral reference is now only what CLARITY compares against, so DEHAZE no longer takes a second child at all. DEHAZE is signed, which it was not: the knob was 0..10 and the export engine skipped the pass unless the amount was above zero, so a negative value was a slider the UI would not even offer. It is -10..+10 now, and the transmission carries the sign — positive pushes t below 1 and `J = (I - A)/t + A` takes the scattered light out, negative pushes it above 1 and the same expression scatters light back in. That is the direction a photo shot through mist wants, and it needs no second formula: one expression, both signs, the ceiling at 1 + DEHAZE_MAX_OMEGA. CLARITY's negative side was the last place where a knob meant two different things depending on where it was read: the frame-wide row softened with a mist blur of its own radius (MakeBlur, sigma |c|/10*4) while a mask mixed toward the bilateral reference the positive side reads — two neighbourhoods, two strengths, one name. CLARITY_BLEND_SKSL now carries both directions of the one move (above zero the doc's unsharp, below it the mix back toward the same reference, gain 1), so the frame-wide row and a mask's CLARITY are the same reference at the same strength, and the frame-wide mist blur is gone. Measured in one harness, one photo, one session, knob at +-9, before -> after, mask phase and frame phase in the same run (the box is the mask's own middle box for the mask, the stage's own box for the frame-wide row): - FRAME DEHAZE +9: dmean -0.1680 -> -0.0751, dhp -0.0056 -> +0.0036, white band -0.2156 -> -0.0522 — it darkens the haze and raises the contrast instead of lowering both. - FRAME DEHAZE -9: dmean +0.0469 (was not offered), dhp -0.0010 — the same knob on the other side, and the frame gets hazier. - MASK DEHAZE +9: dmean -0.1490 -> -0.0513, dhp -0.0060 -> +0.0039, white band -0.1234 -> -0.0274, dark band -0.0595 -> -0.0075 — a mask's DEHAZE is now the frame-wide move on the mask's own pixels (dhp +0.0039 against the frame's +0.0036). - MASK DEHAZE -9: dmean +0.0319, dhp -0.0013. - FRAME CLARITY -9: dhp -0.0200 -> -0.0094, white band -0.1112 -> -0.0203, so the frame-wide row no longer pays for its soften by flattening every white in the frame; MASK CLARITY -9 is the same move (dhp -0.0150, white band -0.0103) and the two now agree in direction, sign and rough magnitude at -9. CLARITY +9 is untouched on both sides (+0.0335 mask, +0.0307 frame) and every other knob's numbers are unchanged to within +-0.0005, which is the run-to-run noise of the same harness. `step` was the uniform's first name and SkSL refused the shader with it (a builtin), which is how a whole DEHAZE row came back with all-zero deltas in the first measurement after the change; `stepPx` is what compiles. `npm run typecheck` and `npm run build` are clean, and the stage draws with no page error (the only console error is the dev server's own `/api/events` 404). Not ported: nothing. The phone's renderer has no gradient mask and no atmospheric-light estimate to mirror; `shared/utils/toneShader.ts` and `shared/utils/gradientMask.ts` are the web engine's own files. Probes: measure-parity (both phases in one run, one photo, before and after — the same harness the previous commit was scored with), measure-dehaze2 (the same script with only DEHAZE in both phases, plus a console listener, which is how the `step` uniform was caught), sim-dehaze-dcp (the offline simulation that picked the min-patch over the average: clear frame +9, contrast 0.0248 -> 0.0292 against the average's 0.0248 -> 0.0235).	2026-09-26 20:16:13 +07:00
3dtours	5f3257a4d8	web: make a mask's knobs the moves the frame-wide row of the same name makes ... A gradient mask carried its own copy of the six tonal and spatial formulas, and four of them had drifted from the columns of the same name. HIGHLIGHT was inverted: the single shift `0.5 * (shadows*ms - highlights*mh)` put the knob's `x` on the shadow mask and its `y` on the highlight mask, so turning HIGHLIGHT up pulled the bright band DOWN and turning it down lifted it — measured at the mask, +9 moved the top band -0.2295 and -9 moved it +0.0454, and the whole frame's HIGHLIGHT row reads the other way. WHITE and BLACK were a flat gain on the end each one owns (`c * (1 + 0.5*k*mh)`), which scales every pixel above the midtone by the same fraction and so drags the near-whites into the greys rather than leaving them white: a lowered WHITE took the top band down -0.2117 while the middle band moved -0.0036, and a raised BLACK pushed the middle band up +0.0195 for +0.0414 at the bottom — the lift went everywhere except where it was asked for. CLARITY's negative side was the same unsharp as its positive side with the sign flipped — `c + k*(c - blur)` with k negative — which is a soften only in name: it sank the mask's whites (top band -0.0543 at -9) and left the mask's own contrast where it was (dhp -0.0008), the opposite of what the knob is named for. DEHAZE ran after CLARITY, so a mask sharpened its haze and then tried to remove it; frame-wide the two are the other way round, and for a reason. The four now mean inside a mask what they mean on the whole frame, because toneShader.ts is the reference the app's own rows are written from and the same name on the same knob should not be two different moves. HIGHLIGHT and SHADOW are TONE_SKSL's additive luma shifts — HIGHLIGHT weighted by the headroom it has left (1 - t) so it cannot drag a blown white to grey, SHADOW by its own floor — with the colour difference riding along at TONE_SKSL's damped gain so a lift cannot collapse a colour. WHITE and BLACK are TONE_SKSL's per-channel point moves, cubic in each channel's distance from the end it owns, so the toe and the shoulder move and the midtones stay put. DEHAZE runs before CLARITY, the frame-wide order. CLARITY's negative side is a real soften, `mix(c, blur, -k)` toward the same bilateral reference its positive side works against. TONE_SKSL's two smoothsteps (0.50..1.00 and 0.00..0.55) replace the mask shader's own pair, and the soft masks are computed in float and narrowed once, the way the frame-wide shader does it. Measured in one harness, one photo, one session (the mask's own middle box, knob at +-9, before -> after on the mask, with the frame-wide knob of the same name as the reference it is now written from): - HIGHLIGHT +9: top band -0.2295 -> +0.0298 (frame-wide +0.0547), dark band 0.0000 -> -0.0001 — the lift is a lift, and the inversion is gone. HIGHLIGHT -9: +0.0454 -> -0.0385 (frame-wide -0.0674). - WHITE -9: top band -0.2117 -> -0.0646 (frame-wide -0.0860) — a lowered white stays a white instead of becoming a grey — while the middle band goes -0.0036 -> -0.0150 (frame-wide -0.0139), which is the move a white ends up making when it is a point move rather than a gain. - BLACK +9: bottom band +0.0414 -> +0.0997 (frame-wide +0.1036) and the middle +0.0195 -> +0.0347 (frame-wide +0.0402) — it goes to the toe it owns. - CLARITY -9: dhp -0.0008 -> -0.0149 (frame-wide -0.0200) — negative CLARITY softens now — and the top band -0.0543 -> -0.0113, so it no longer pays for that soften by sinking the mask's whites. CLARITY +9 was already right (+0.0333 both sides) and stays. - DEHAZE, the one knob with nothing on the negative side: unchanged at -9 (-0.1490 both sides, the pass order was the only thing wrong with it), and the mask and the frame-wide row now agree across the whole range (1/3/5/7/9 at -0.0124/-0.0397/-0.0711/-0.1074/-0.1490 on the mask against -0.0133/-0.0423/-0.0759/-0.1151/-0.1619 frame-wide), monotone. DEHAZE's own numbers are therefore not a mask-only bug: an estimate of the haze that reads a mask differently from the frame would be inside `atmosphericLight` and `DEHAZE_MAX_OMEGA`, which both paths share, and changing either moves the frame-wide DEHAZE column too — left as it is rather than changed under a mask report. Everything else about the mask is untouched: `dctrl` is +0.0000 on all six knobs (a knob still moves the mask's own pixels and nothing outside it), the shader compiles and the stage draws with no page error. Not ported: nothing. `shared/utils/gradientMask.ts` is the web engine's own file and the phone's renderer has no gradient mask to mirror. Probes: measure-mask-knobs (the six knobs on a selected mask, before and after), measure-frame-knobs (the same six frame-wide, the reference the mask is now written from), measure-parity (both phases in one run so the two are the same photo in the same session), png-parity-report (the before half of that run died in its frame phase and left no log, so its already-captured mask frames are re-read off the PNGs with the same box and the same bands), measure-dehaze-curve (DEHAZE 1..9 on the mask against 1..9 frame-wide, for monotonicity and for the pass order).	2026-09-26 19:04:32 +07:00
3dtours	97bdf605e2	web: import the camera's RAW, and grade it like the phone ... The studio took JPEG, PNG and HEIC and nothing else, so a photographer's own negatives never reached it. A RAW now loads the way any other file does — `isRawName` reads the extension off a 24-entry list, the file goes into OPFS under one slot (`current_image.raw`, beside `current_image.name`, so a reload finds it again) and `rawDevelop` runs it through LibRaw-wasm: half size, 16-bit output, camera white balance and the camera's own 3x3 matrix, in bands of 2M pixels so a 30MB file never holds a second copy of itself. `example-sony.ARW` (30.3MB) lands as a 3120x2084 picture, no page error. DEHAZE joins the FX tab, where Lightroom keeps it: a chip off the same PARAM_DEFS entry (`dehaze`, 0..10) so nothing new renders chips, and the pass is the dark channel prior — `atmosphericLight` reads A off a 32x32 draw of the photo, `DEHAZE_SKSL` takes omega up to 0.95 over a floor of 0.1 — measured at 71.8% of the stage's pixels moved between 0 and 10. The gradient mask grows the six knobs the phone's has: HIGHLIGHT, SHADOW, WHITE, BLACK, CLARITY and DEHAZE. The mask's falloff is a smoothstep rather than a line, and CLARITY/DEHAZE inside a mask get a blurred copy of the photo plus the air A as a second child of the mask shader — so a mask's clarity is clarity and not a flat brightness lift. The column shows all nine rulers; CLARITY 9 moves 42.2% of the stage, DEHAZE 9 moves 27.9%. CLARITY stops reading the whole photo per pixel: the single pass that sampled a 15x15 box 225 times is now the three passes the same math wants — 1x15, then 15x1, then a blend, `orig + (orig - B) * 3.2` — about 30 reads. Both signs work (77.4% of the stage moves at +10, 79.6% at -10), and the negative branch keeps its mist as it was. The pointer reviews a look before it is taken: resting on a PHOTO STYLE chip or a recipe chip lays that look on the photo while it stays there and gives it back the moment it leaves — byte-identical, measured on four of them (24.9%, 23.8%, 24.5%, 25.3% of the stage moves on, 0.00% off) — while the recipe, the UNDO stack and the session stay on the look the click left. A hovered look brings its colour alone: the masks, the dust spots and the mosaic of the photo being edited ride along, or a pointer crossing a chip row would rub them off. A PRO sim is left out, since a hover that showed its look would hand over what the click gates. Probes: e2e-raw-verify, e2e-dehaze-mask, e2e-mask-verify, e2e-clarity-verify, e2e-hover-preview2.	2026-09-26 18:18:22 +07:00
3dtours	7e47a153b8	web: make EXPOSURE, EV and HIGHLIGHT mean what Lightroom means ... A stop is a multiplier on light, so EXPOSURE and EV stop living in the sRGB colour matrix and get a linear-light pass of their own (EXPOSURE_SKSL: linearise, `C * 2^EV`, re-encode). The matrix keeps CONTRAST: a gain on encoded values is what made +1 EV land at x1.5 instead of x2. Measured on the neutral PROVIA sim: EV +1 = x2.011, EV +2 = x3.999, still unclipped at 239. The pass sits between the matrix and the tone shader, and the tone / cinema / curve / glow / halation children all sample through it, so HIGHLIGHT finally sees the value exposure produced instead of the one before it. Recovery keeps `L + strength * mask * (1 - L)` over `smoothstep(0.50,1.00,luma)`, and the colour comes back as `color * (luma_new / luma)`: a blown white stays white (255 -> 255 at -10, 255 at +10), a 0.8 grey loses 33 luma, the midtones beside it do not move. AUTO is the histogram the LIGHT tab already draws: weighted mean luminance (guard 0.001), target 0.48, `log2(0.48 / avg)` clamped to +-2.5 EV, handed to the same knob. A 0.251 grey asks for EV 0.9 and lands at mean 83.0 against the 83.3 predicted, idempotent on a second press. A stock's own bias rides the same pass (`SIM_EXPOSURE_BIAS_EV`, VIVID +0.25 EV) and cancels against the knob, so -1 EXPOSURE on VIVID returns the CLASSIC rendering (measured 0.4149 vs 0.4177). ponytail: the phone app's `src/utils/colorUtils.ts` keeps the old math, so the two copies have to move together; recipes saved before this commit (EXPOSURE 2, HIGHLIGHT +-1) render under the new stop semantics. Verified on the rebuilt container (BASE=http://localhost:8090): - web-exposure-probe.cjs 20 PASS / 0 FAIL (neutral 128 -> 128, EV +1 ratio 2.011, EV +2 ratio 3.999, EXPOSURE +10 ratio 5.62 / -10 ratio 0.172, AUTO EV 0.9, HIGHLIGHT -10 on a 204 grey 204 -> 171, white 255 -> 255, no console errors) - sim-exposure-test.cjs 9 PASS / 0 FAIL (classic 0.4149, vivid 0.4531, knob -1 returning 0.4177, bias 0.0382) - regression suite, 28 probes: mask 53/0, brush-edit 35/0, heal-idle 23/0, heal-zoom-drag 28/0, sims 31/0, sim-vivid 9/0, white-black 4/0, temp-swatch 33/0, tone-curve clean, compare 25/0, create 52/0, wb-preset 33/0, zoom 25/0, save-recent 25/0, web-smoke 9/0 (its export step was stale — EXPORT opens a size picker now). panel-test 4 FAIL, histogram-wb 1 FAIL, studio-save-hl and progate timeouts, landing-test 6 FAIL ($0.99 pricing) are pre-existing. - npx tsc --noEmit clean.	2026-09-25 17:44:28 +07:00
3dtours	c70edce8c1	web: mirror the frame with H-FLIP and V-FLIP, and stamp a typed place ... ROTATE gains the two mirrors: H-FLIP and V-FLIP toggle one at a time and stay on through the quarter turns and STRAIGHTEN, which makes them compose with every rotation the strip already offers. ROTATE's own RESET levels the whole frame, mirrors included. The flip itself lands last, in screen space, so a mirrored photo is what the eye sees rather than what the sensor saw; the pixels are copied axis-aligned, so there is nothing to resample. Session state carries the two flags, so a reopened photo comes back mirrored. Also fixes the stamp: a typed PLACE NAME with no GPS fix now prints on its own (latitude/longitude ride in as NaN), instead of the whole stamp and its box being skipped for want of coordinates.	2026-09-25 08:46:27 +07:00
3dtours	b568fa3fdc	web: let FX carry Lightroom's two gradient masks, and grade inside them ... FX had two tools that change the photo where it is — HEAL repairs a speck, MOSAIC hides a patch — and every knob that graded the frame graded all of it. The scratchpad's gradient_mask.md asks for the two local adjustments the phone's own editor has and Lightroom made familiar: a linear gradient and a radial one. This is that spec, written for the renderer this app actually has. A mask is a SHAPE rather than a value, so it is dragged rather than turned: the LINEAR chip arms a ramp and the next drag on the photo is its two ends — zero at the press, one at the release, the spec's own convention, which is what makes the same gesture a wide fade or a hard edge — and RADIAL arms an ellipse whose centre is the press, whose semi-axes are the drag's own distance and whose axis lies along the direction the hand went, so the circle a drag describes is the circle the mask starts life as. Both shapes keep a pin (the whole shape travels by it) and, while chosen, the handles that move the ends or the axes and the one that turns the ellipse; what is drawn is the shape the render will read, so the ramp and the rim are visible before a knob is moved. Inside the shape, three knobs grade in the spec's own order and its own maths: exposure as `pow(2.0, e)` in stops (its -5..+5), contrast about the middle, saturation as a mix away from the pixel's own REC-709 luma — the mixer's -10..+10 read as the spec's -1..+1 — and a radial mask adds the feather it fades over, which is the fraction of its own axis the alpha holds full before it dies at the rim. Several masks run in the order they were drawn, each reading what the one before it left, which is what a stack of local adjustments is. The maths is GLSL in the md and the renderer is Skia (canvaskit-wasm, SkSL runtime effects), so it is ported stage for stage: one pass, after the frame-wide grade and the vignette and before HEAL, because a local adjustment is part of the look and not a repair — the pixels a repair borrows are then meant to carry the mask's light already. Preview and export both come through renderPhoto, so the file carries the masks the stage is showing by construction, and the shape and the knobs ride in the recipe's own JSON, which is what makes them survive a save. The chips sit with HEAL and MOSAIC because all four take the pointer on the photo, and they are exclusive with every other armed tool, the eyedropper included — while a mask tool is armed the layer takes the photo, so a drag means "draw the next shape" and a press on a pin means "take hold of this one", which is why the shapes already laid are answered through their pin and handles alone. A knob drag on a mask is one undo step, a shape drag is one more, a press that only chose a mask records nothing at all, and RESET is the way back with the whole frame as it was imported. ponytail: the spec's own "Gợi ý nâng cấp" rung — Highlights and Shadows isolated with pow(luma, 3) and pow(1-luma, 3) weight masks — is not here, and neither is Lightroom's per-mask invert and colour/tone range. The three knobs are what "gradient mask" means until a photo shows a sky that has to be rescued apart from the grass under it; the md itself calls it an upgrade, not the feature. Verified: tsc clean; mask-probe 35/0 on the dev server and again on 8090 (the two chips, both shapes drawn and moved and turned, the ramp read off the pixels — 61 -> 244 at the release and 61 at the press — the feather read off the rings, DELETE/UNDO/REDO/CLEAR, and one gesture one undo step); brush-edit 33/0, heal-idle 23/0, heal-zoom-drag 28/0, landing/pro-gate/award-column/otp-code/ tone-curve all ALL PASS, backend 180/0.	2026-09-24 10:42:58 +07:00
3dtours	88d6d0e648	web: read the ring's light by direction, and off the dust's soft edge ... The last commit pasted the borrowed patch at the light of the place it lands in, and read that light as one number per spot: the mean of the ring around the dust minus the mean of the same ring around the patch. That number is a light the place has when the ring is all one thing. It is not a light the place has when the ring is not. A twig, a hairline, the edge of a table under the brush, and a minority of the taps stand on the thing rather than on the ground: the mean then follows the minority — it is a colour the place never had — and the patch is pasted in it. The donor was of exactly the right light, the search had gated it at LIGHT_GATE, and the repair still lands as a dark blotch. A mean is the wrong estimator for a ring that is not one thing; the search already knew that, and reads its own ring as a median for the same reason. So the light is read once PER DIRECTION. Each of the sixteen taps is a pair of readings — the place's ring and the patch's ring at the same sixteen places — and a pixel takes the correction of the two readings it lies between, interpolated by its own angle around the spot, in the same single draw. The rim then meets the place all the way round instead of on average: a tap that landed on the twig bends the part of the rim near the twig, and the far side of the circle is left where it was. Sixteen taps rather than eight because a tap's influence reaches only as far as the next tap, so the finer the ring, the less of the rim one hard pixel of the photo can drag with it. The second half of the change came out of the app, not out of the lab. With the per-direction reading and no other change, heal-probe.cjs went from 49 PASS to 41 PASS / 8 FAIL: the repair's own centre came out 15-18 levels dark on a flat field, with the frame around it clean. The reason is the estimator again, from the other end — one direction is one pair of pixels and carries no averaging, so whatever the ring reads at that direction, the patch gets in full. And the ring at RING_R alone is not clear of the dust: a speck spreads about a pixel past where it is drawn in the pixels the shader samples, so the nearest taps sit inside the dust's own soft edge and read the dust's light. The mean had been hiding it: one contaminated tap in eight is a level off; the same tap read whole is the blotch. The ring is now a pixel further out again (RING_PAD), in the same pixels the sampler works in — a fraction of the radius would be nothing at all at the sensor-dust end of the brush, which is where this tool is aimed — and the probe is back to 49 PASS / 0 FAIL. Measured on a sweep of the two ways of reading it (heal-ring-sweep.cjs, CanvasKit, three scenes, the step the eye reads at the rim plus the level of the patch's own middle against the ground it landed in, levels out of 255): scene shipped mean 8@1.15 this: 16 taps, per direction uniform light difference step 0, centre 0 step 0, centre 0 twig across the ring step 53 (mean 16.4), step 56 (mean 2.4), centre 34 dark centre 0 brush fits the speck centre 5 dark centre 0 The worst step on the twig scene is unchanged — that is the twig's own edge crossing the rim, which no level can meet, and the floor the copy set at 85. What moved is the average (16.4 levels to 2.4) and the level of the patch's middle, which is the blotch: 34 levels of a place that never had them, down to none. No new dependency. cv.seamlessClone is the same thing this shader already does — the membrane half of a Poisson edit — and OpenCV.js would be 5-10 MB off a CDN, solved on the CPU per spot, outside the one draw the preview, the recipe and the export all read from: the correction is recomputed from the snapshot on every render, which is why the preview and the exported file agree by construction and why a saved photo opens onto the same repair. It also cannot run in the worker the brush paints in or against the fractions the recipe stores. Verified: heal-blotch-lab.cjs (scratchpad, CanvasKit, no browser) — new, 12 PASS / 0 FAIL, and 8 PASS / 4 FAIL against the bundle built from 57ade27, which is what the lab is for. Two scenes, each run twice through the real pipeline: the mean (kept inline in the lab as the "before") against healSkSL from the bundled heal.ts. Twig across the ring: the mean puts the patch's middle down at 116 against a ground of 150 (34 levels dark), the module at 150. Brush fitting the speck exactly: 145 against 150, the module 150. In both, the dust is gone rather than dimmed, and the frame away from the circle is the photo. heal-edge-lab.cjs — 9 PASS / 0 FAIL, its ring metric narrowed to the rim the ring has already handed back to the light (one tap spacing either side of the band excluded: the rim nearest the band is bent toward the band on purpose, and that bend is the fix, not an error). Light side of the rim 0 levels off (the one mean level: 32), and the band the ring caught is met at 34 against the copy's 90 — under the old ceiling, not over it. heal-seam-lab.cjs 10, heal-skia-lab.cjs 28, heal-search-lab.cjs 15, heal-probe.cjs 49, heal-zoom-geom.cjs 5, heal-zoom-probe.cjs 8, mosaic-skia-lab.cjs 27, mosaic-probe.cjs 51 — all 0 FAIL, against the rebuilt app at http://localhost:8090 (docker compose up -d --build frontend). Regressions against the rebuilt app, rc=0, 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; frontend tsc --noEmit clean. ponytail: the correction lives on the rim — every pixel takes the two readings it lies between and interpolates — so it is the boundary of a Poisson edit and not its interior: a repair laid over something the patch cannot reproduce still carries the patch's own texture inside, bent to fit the rim, and the other half of the solve (a correction that relaxes inside the circle, a Jacobi ping-pong per spot) lands when a real photo shows an interior the eye can find from the rim alone. A direction's level is one tap pair on each side, so the grain the mean used to average away now rides the rim as a wedge of a level or two across the circle — a tangential average of three taps per direction is the rung for that, when a photo shows the wedge. RING_PAD is one pixel because that is the width of the dust's own soft edge in the sampler's pixels; a speck whose blur is wider than that still reaches the ring. The source is still found by the ring search — eight directions at three distances, each mirrored — and not by PatchMatch, and the recipe still stores fractions with no correction in it, so nothing about this change is versioned in a saved photo.	2026-09-24 06:29:47 +07:00
3dtours	57ade27eee	web: paste the borrowed patch at the light of the place it lands in ... HEAL borrows a patch of the photo and copies it over the dust. The copy brings the patch's texture — which is the point, the repair is the same picture rather than a blur over the speck — and it also brings the LIGHT the patch was photographed in, which is not the point at all. The search already refuses a donor from another light: LIGHT_GATE is 20 levels, and a candidate past that is not scored. But inside the gate a patch can still be 20 levels off, and 20 levels is a soft blotch of its own at the rim of the circle — a mark where the dust used to be, which is what the user is complaining about when they say the repair is visible. On skin, sky and sand the dust is not the problem the eye finds; the step the paste puts down is. So the paste is now the patch's gradients worn at the destination's level: the shift is the mean of the ring the spot sits in minus the mean of the same ring around the patch it borrowed, and what lands is the borrowed pixels plus that. It is the membrane half of a Poisson edit — keep the texture, adopt the level — and it is eight taps per spot inside the shader that was already running. No solve, no ping-pong, no extra pass: the correction is recomputed from the snapshot inside the shader on every render, so the preview and the export agree by construction and the recipe carries nothing new. The same spot in a saved photo opens onto the same repair, because nothing about the correction is stored. Where the ring is measured turned out to be the whole of the change. The first cut read it at the feather line, 0.85 of the radius, which is where the pasted patch is still at full strength and therefore looks like the natural place to compare — but that ring sits just inside the circle, and when the brush fits the speck snugly, which is exactly how a dust brush is used, it reads the speck: the light the repair is measured against is then the dust's own, and the patch gets shifted onto the very dark it exists to erase. It also reversed the smoothstep edges the moment the ring was pushed outside the brush (a radius past rad, edges the wrong way round, and the pass quietly drew nothing). The ring now sits just OUTSIDE the brush, at RING_R of the radius — the same radius the search reads a spot's light at. Outside, both sides are photographs: the ground the repair has to sit in, and the ground the patch came from. That the two are the same measurement is the point: a donor that passed the gate was already within LIGHT_GATE of this ring, so the shift it now receives is bounded by the gate. The decision to borrow and the correction to the borrow stopped being two different opinions about the same pixel. Eight taps at the same angles on both sides is what makes the difference read as light rather than as texture: the grain, the detail and the neighbouring specks that differ between two patches are averaged out by sampling both rings at the same places, and what is left is the level. The rim, measured as the level inside the circle against the level of the ground outside it, drops from 20 levels to 0 on a scene built for it, while the borrowed contrast stays at 40 — the level moved and the gradients did not. That is the line between this and a blur, and it is the line the lab holds it to. Verified: heal-seam-lab.cjs (scratchpad, CanvasKit, no browser) — 10 PASS, 0 FAIL: one scene, the speck on the grey ground with every reachable patch inside a block 20 levels darker, run twice through the real pipeline — the paste the branch shipped before this change (the copy, kept inline in the lab as the "before") against healSkSL from the bundled heal.ts. The copy puts the block's own level down at the rim: inner 100/110/120 against outer 120/130/140, rim step 20.0 levels, contrast 40. The shift lands the borrowed texture on the ground's level: inner 120/130/140 against outer 120/130/140, rim step 0.0 levels, contrast 40 — the borrowed feature is still pasted at the strength it was borrowed at, the hole reads as the ground it sits in, the block the patch came from is untouched, and the frame away from the repair is the photo. heal-skia-lab.cjs 28 PASS / 0 FAIL against the bundled module: the pass still runs, the uniform block is the size its shader declares, and the paste is still an exact copy of the source pixels — the lab's paste scene now borrows from the SAME light (a white pixel at the middle of the borrowed patch, so a copy and a blur of the dust cannot be confused), and its forty-spot and three-spot runs still draw every spot in order. The scene where the two lights differ is the seam lab's. heal-search-lab.cjs 15, heal-probe.cjs 49, heal-zoom-geom.cjs 5, heal-zoom-probe.cjs 8, mosaic-skia-lab.cjs 27, mosaic-probe.cjs 51 — all 0 FAIL, against the rebuilt app at http://localhost:8090 (docker compose up -d --build frontend). Regressions against the rebuilt app, rc=0, 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; frontend tsc --noEmit clean. ponytail: the shift is one number per spot, measured over the rim, so a border the two patches disagree about along its length is only matched on average — a repair laid across a hard edge keeps a faint step where the edge crosses its rim, and the other half of the Poisson solve (a correction that bends inside the circle, a Jacobi solve over the spot's own box, a ping-pong pass per spot) lands only when a real photo shows that step and the eye can find it. The gate is still needed and still refuses: a shift corrects a light, it cannot invent a patch where no patch of that light exists, so a speck surrounded by dust from another light is left alone rather than covered with a guess. The source is still found by the ring search — eight directions at three distances, each mirrored — and not by PatchMatch: the search already refuses dust and wrong light, and PatchMatch lands when a real photo shows the search picking a bad donor. The run is still drawn spot by spot, with no stroke id in the recipe, so a long drag is a row of circles rather than one region.	2026-09-23 22:10:33 +07:00
3dtours	f1385d8a08	web: hide what the brush paints, in cells, and never in a blur ... HEAL borrows a patch of the photo and pastes it over what the brush covers. The other half of the same gesture is the opposite thing — a patch of the photo the user does not want shown to anyone, a face at a table, a plate, a badge, the number on a note at the edge of the frame — and hiding it is the second tool on the same layer: MOSAIC, next to HEAL in the FX row. Everything the two tools share was already shared by the time this landed: one layer, one circle riding the pointer, one wheel, one gesture that is one undo step, spots stored as fractions of the render so the preview and the export draw the same circle. Only what a spot MEANS split, and it split into two files over the piece of physics both of them were already carrying: heal.ts and mosaic.ts, and brush.ts under them for the size and the spacing of the circle they both lay. What a mosaic spot does is destroy what it covers rather than replace it. The frame is cut into square cells of MOSAIC_CELL (0.02 of the width — 5.12px on the probe's 256px photo, 40px on a 2048px one) and every pixel of a cell takes the colour found at that cell's own middle, read with img.eval so the block is the snapshot's bilinear tap and not a neighbour's cell. What is under the circle is still a picture of that place, at a resolution nothing can be read out of. A blur was never in the running: it leaves the SHAPE of what it hides — a face under a blur is still a face, a plate still a plate — and the arrangement is exactly what the user is asking to keep to themselves. Cells coarse enough to lose the arrangement are what "do not show this to anyone" needs, and the blockiness is the price of it. The cells are one grid over the whole frame, not one grid per spot: a pixel's cell comes from its own position, and every block reads the snapshot rather than the output, so two overlapping spots never pixelate a pixelation and a run lays one band with no seam where its circles cross. The rim is hard for the same reason in reverse — a feather would mix the cells back into the sharp photo along the edge, which is a half-hidden thing leaking the arrangement it exists to hide. A mosaic spot borrows nothing, so the layer draws no donor circle beside the cursor: the second circle appears only when a spot has a source ('sx' in it), which is the one place the two tools' DOM parts company. Each tool keeps its own brush size, and each CLEAR chip clears only its own list, because the size a dust speck is healed at is never the size a face is hidden at. The recipe carries the list as adjustments.mosaic — x, y, r, the same fractions HEAL stores, and readMosaic guards them the same way — and the renderer builds one RuntimeEffect per count exactly as it does for HEAL (mosaicEffectFor), the pass sitting right after the heal pass so a repair made on the same photo ends up underneath the cells that hide the rest of it. The backend needed nothing: a recipe is spread through as it stands, so a saved photo keeps its mosaic and a shared one opens with it. Verified: mosaic-skia-lab.cjs (scratchpad, CanvasKit against the bundled mosaic.ts) — 27 passed, 0 failed: the cell rides in the frame block in the render's own pixels and is a fraction of the WIDTH, so it is square on any shape; 4912 cells inside a spot each carry one colour, and 164/164 of them carry the colour at their own middle; the 2px white dot on the dark square reads 250 -> 20; nothing outside the circle changed (0 stray pixels) while the cells reach the rim (852 pixels at the edge); a spot wider than the frame still runs; overlapping spots share one grid over 6335 pixels with 0 differing between them (no cascade); readMosaic refuses a zero radius, an off-photo spot, junk and a missing list, and keeps a forty-spot list whole. mosaic-probe.cjs (the rebuilt app at http://localhost:8090) — 51 PASS, 0 FAIL, no page errors: FX offers a MOSAIC chip that arms the same brush layer and says which tool it is painting for; the wheel sizes each tool on its own (8.0% up, 5.0% back) and the circle follows it; a click lays exactly one spot with no borrowed patch beside it; the pixels of the cell are one colour (0 levels across, cell 5.12px); the dot is unreadable (250 -> 15); nothing outside the circle changed (0 pixels, worst 0) and the cells are not the photo that was there (221/509 pixels changed); UNDO gives the photo back exactly and REDO hides it again; a drag paints ONE band 25.6px wide, as wide as the brush, standing for 5 points of travel and laying 5 spots that leave 0 pixels outside them changed, with the step within a cell 3.43 levels against 21.25 between cells (635 + 157 pairs) — the cells are flat and their borders jump; one gesture is one undo step; arming HEAL and arming MOSAIC hand the pointer over and back with each tool's spots intact; CLEAR hands the photo back pixel for pixel and leaves no chip behind. The probe's own reading is deliberately a shape, not a colour: the app's preview is the engine's render at preview scale with a JPEG on top (and its auto dynamic range), so a cell's colour read back from the base would be two encodings apart. The exact cell colour is the Skia lab's claim, where no encoder sits between the shader and the reading. heal-probe.cjs 49 PASS / 0 FAIL against the same build, heal-search-lab.cjs 15, heal-skia-lab.cjs 27, heal-zoom-geom.cjs 5, heal-zoom-probe.cjs 8 — the brush HEAL paints with is the one MOSAIC now paints with. 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; frontend tsc --noEmit clean. ponytail: the cell is a fixed fraction of the width, not a fraction of the brush, so a brush smaller than one cell paints a single block's colour; tying the cell to the radius would mean a cell size per spot in the recipe, which is a recipe change this tool does not need yet. The grid is one grid for the whole frame, so a run of overlapping spots and one wide spot give the same blocks, and the run's circles are laid spot by spot — drawing a run as one region wants a stroke id in the recipe, the same change HEAL's own run is waiting on. A spot is in the recipe by its fractions alone, so what the export prints is the mosaic the user saw, and the original pixels under it are gone from the record on purpose.	2026-09-23 22:03:33 +07:00
3dtours	b795517d9f	web: read a patch's light before pasting it, and paint with the brush ... The brush was not healing: clicking a speck deleted one black spot and made another, and the borrowed patch landed in a light the spot was not in, so the repair read as a mark of its own. The circle the brush draws also slid off to the side of the pointer as soon as the photo was zoomed in, and a drag showed itself as a row of overlapping circles rather than as a brush being drawn. The search was comparing the wrong thing. findHealSource scored a candidate against the spot's own PATCH_TAPS — the centre and a ring at half the radius, which is INSIDE the brush, where the dust is. The patch that matches a speck best is then the one carrying a speck of its own, which is exactly how "heal a spot" became "move it a few pixels": with a neighbour sitting at the 2.6r ring the search itself prefers, the winner was that neighbour, 26 dark pixels pasted where the repair was meant to be. The taps are split now, by what they are for. The light a repair has to sit in is read off the spot's RING — twelve taps at 1.15r, just outside the dust, the scale the eye reads a spot's surroundings at — and taken as their MEDIAN, because the ring can only be a little way out: some of its taps land on the speck's own softened edge, and a mean drags the whole light down by them (the eight-tap mean read 84 where the ground was 150, and with the gate below that refused every candidate on the frame). What a candidate would actually paste is the mean of its own inside taps, now including the ring at HEAL_FEATHER of the radius — the circle is copied at full strength out to there, so that is where a neighbour's dust leaking into the patch shows up and the middle of the patch would never see it — and its cleanliness is how much those taps spread around their own mean: dust is an outlier in its own neighbourhood, grain is not. A candidate from another light is not scored at all. Past LIGHT_GATE (20 levels of the 0-255 the sampler answers in) the patch IS the mark the user is complaining about, so the search returns null rather than sending a wrong clone and the caller leaves the speck alone. Within the gate the score is light * 3 + cleanliness, so the light decides and cleanliness breaks the ties the eye would not see. A spot the search refuses is not laid down at all — healUp skips it instead of recording a self-patch, which was a repair that changed nothing — and a stroke that is refused end to end reports no spots, which addHealSpots already treats as nothing to do: no step in the history, no spot on the photo. The ring had to be a fraction, not an offset. healPos was the pointer's pixels inside the layer, and the layer carries the stage's transform, so a zoom scaled that offset a second time: at 1:1 the pointer sat at screen x 846.5 and the ring was drawn at 1288 — 442px away, the same distance the user sees as "the circle is in the wrong place when I zoom in". The pointer is stored as a fraction of the photo now — healPoint already answers one for the spot it lays — and drawn as a percentage of the layer, so the layer's own transform scales it once; off the photo there is no ring. The eyedropper's icon had the same shape of bug (its sample was always right — pickAt reads the photo's own rect) and got the same fix in the same file, since it was two lines. The stroke is one mark of the brush. The trail was a circle per point of travel, laid one HEAL_SPACING (0.6) radii apart, which is what a row of beads looks like; it is one SVG path with round caps and round joins now, its width the brush's own diameter and its colour the accent at 45%, so what the pointer draws reads as the band it is about to lay down. The count of travel is kept on the element (data-points) so the probe can still hold the run it becomes to the run it showed. Verified: heal-search-lab.cjs (scratchpad, Node against the bundled heal.ts) — 15 PASS, 0 FAIL: one speck alone is repaired, from a patch that is clean field, and its light is 0.0 levels off the spot's own; a speck with a neighbour exactly at the search's first ring borrows from the far side with 0 dark pixels pasted; a speck ringed with dust in all eight directions skips past the ring (0 pasted); a speck in the corner stays inside the frame; a speck at the lip of a shadow, where every reachable patch is 60 against a ground of 150, is refused (null); ground with a dark edge through it is not a refusal — the repair comes from the light side and its light is 0.0 levels off. heal-skia-lab.cjs — 27 PASS, 0 FAIL (the shader and the search unchanged in everything the search is not asked here). heal-probe.cjs (the rebuilt app at http://localhost:8090) — 49 PASS, 0 FAIL, no page errors: the circle rides the pointer at the size the chip reads; one click heals a speck to 151 with its four neighbours field; the borrowed patch is a real distance away and is clean field; a drag shows ONE mark, 6.1px wide against a 6.1px brush, standing for 15 points of travel, lays exactly 15 spots, clears on release, and UNDO takes the whole stroke back; 25 spots carried with the first healed speck still first; everything gone after a reload; CLEAR brings it all back. heal-zoom-geom.cjs — 5 PASS, 0 FAIL: at fit and at 1:1 the ring's screen centre is the pointer (846.5,452.5 both times, against 1288 before), the ring keeps the brush's size on screen, and a repair made at a zoom lands under the pointer. heal-zoom-probe.cjs — 8 PASS, 0 FAIL: on a structured 2048px photo at 1:1 the speck goes, the donor is at least a ring away, the patched circle is within 1.07 levels of the ground it landed on, the donor's own circle is drawn on the pixels it borrowed; on a navy field with three specks, two repairs land 0.0 levels from their ground. heal-look2.cjs (scratchpad, PNGs in /home/locpham): the pair case used to paste its neighbour and read min 3 inside the healed circle — the pasted dust — and reads 151 now, the untouched second speck alone in the frame; the big-speck case (dust r=9 under a 6px brush) now lays NO spot at all, which is the refusal working: the speck is left alone instead of smeared. 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 refusal leaves the speck on the photo and nothing on the screen — the user closes the brush in a size that covers it and clicks again — which is the honest half of the trade the user asked for, but it is silent; a hint would mean a toast or a shake, and neither is worth a component. The gate is a flat 20 levels, not a percentage of the local contrast, so a photo with a hard edge through the brush's own ring reads as one light and can still take a donor from the other side of it. The search reads the preview JPEG rather than the original, so a patch near the preview's own edges is chosen from the pixels the user is looking at, not from the ones the export will print. And the run a stroke leaves behind is still drawn as its spots, circle by circle, because each one is a repair with a borrowed patch of its own — drawing the laid run as one band would need the recipe to remember the gesture (a stroke id on the spots), which is a recipe change and not what was asked.	2026-09-23 21:36:33 +07:00
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	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	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	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	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	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	4057566a14	web: the three mixer knobs move the whole image, a frame chip toggles itself, ROTATE lets go when STRAIGHTEN steers ... HUE, SAT and LUM leave the colour row: behind an IMAGE divider they are hslHue/hslSat/hslLum, seeded into the shader's band accumulator at full weight for every hue, while the eight band chips keep picking which colour the panel on the photo edits. The image lightness term stays ungated so a frame drained to grey by -SAT still answers +LUM. FRAME loses its NO FRAME chip: pressing the frame already on the photo takes it off. ROTATE's quarter turns stop lighting the moment the fine angle leaves 0, so the strip shows which of the two is steering the photo.	2026-09-18 18:45:41 +07:00
3dtours	1b71c0196f	web: the eyedropper reads a colour and the mixer moves that hue band	2026-09-18 17:41:45 +07:00
3dtours	d7d7be2c6b	web: add CLASSIC VIVIDIPES, spliced at the blue row ... Classic Chrome's blue row, verbatim, with the red and green rows taken from VELVIPES: skies keep the muted teal/cyan lean while everything that is not blue reads loud. The shadow crush rides along from FILM_TONE, since it belongs to the stock rather than to a row. CLASSIC CHRIPES stays untouched beside it.	2026-09-18 16:09:09 +07:00
3dtours	8308b3e65f	web: move WHITE/BLACK onto the WB tab as per-channel points ... LIGHT already spends its slope budget on the tone knees, so the two end points were doing nothing a tone knob could not. On WB they act on each channel's own distance from the end: the darker channel of a shadow and the brighter channel of a highlight move most, which neutralises a cast at the toe and the shoulder. Both shuffles stay cubic in the channel value, so every channel's curve is still monotonic (>= 0.46).	2026-09-18 14:35:48 +07:00
3dtours	1c4cdf8af1	web: put the white and black points on the LIGHT tab ... WHITE (whites) and BLACK (blacks) get the same slider rows as HIGHLIGHT and SHADOW, so the tone curve's two ends are editable on the stage, not only typed into the CREATE form.	2026-09-18 12:49:07 +07:00
3dtours	0627f8dd91	web: keep a saved photo's look in EXIF and its own row ... EXPORT no longer burns the caption strip: the pixels stay the photo's own and the look travels as metadata — ImageDescription (0x010e) for the tag, UserComment (0x9286, ASCII header) for the recipe JSON. SAVE PHOTO now stores the look with the frame (photos.recipe) and the uploader's consent for the community film strip (photos.consent, PATCH /api/photos/:id for the owner). The landing reel skips non-consented frames, and a new MY PHOTOS tab lists the account's saves, reopens one with the settings it was stored with, and carries the two consent switches.	2026-09-18 12:49:05 +07:00