83 Commits

Author	SHA1	Message	Date
3dtours	e43c02c36f	fix(library): spell the names the browser refuses to write ... A backup folder is picked, not created: the frames in it carry the names a camera or a person gave them, and Chromium's IsSafePathComponent will not spell a name back onto a disk if it holds a control or format character, one of ": * ? " < > | \ /", a space, dot or tilde at either end, or a .lnk/.scf/ .url tail. The library is read through a handle, which lets all of those through, so the refusal only surfaced on the way out: getDirectoryHandle threw "Name is not allowed" on the first such folder, the run stopped there and left an empty thumbs/ behind it. Spell a component that would be refused as %XX per its UTF-8 bytes, on the way out and on the way back in, so those frames keep their tiles in the backup and the restore still finds them. A name that was already safe is handed back untouched, which keeps an existing folder readable, copyable and rsyncable by hand. The run also no longer dies on the one frame that will not write: it skips it, names it in the console, and finishes the rest.	2026-10-02 21:51:25 +07:00
3dtours	07a38be5a9	fix(super-res): warm the export runtime's bytes, not the runtime, and release its session on the way out ... Opening the export menu imported onnxruntime-web, and importing that runtime is what starts its thread pool: one Web Worker per thread, each holding a copy of the 27MB wasm build, held by the page until it dies whether or not an export is ever asked for. Those workers are the child processes a visitor finds hanging off the tab (and the tab, and the browser, goes when one of them is killed), and the memory is what a laptop has none of when the studio is closed and opened again. The menu now fetches the files by name and lets the browser's cache do the warming; the runtime is imported by the export that needs it. The threads are capped at four, and pagehide hands the session back instead of leaving the renderer to reap it with the page.	2026-10-02 21:04:56 +07:00
3dtours	c802c43e04	fix(assets): give the frame sheets a build-stamped URL, so a replaced sheet stops arriving from cache	2026-10-02 20:10:02 +07:00
3dtours	8d0a46e7f5	fix(frame): give OLD FILM PORTRAIT a real portrait output ... The sheet was stretched over the visitor's frame, so the portrait variant only turned the paper inside whatever shape the photo had: a landscape photo stayed landscape. The film now has its own opening like the walls do — the frame is scaled up to the photo, the photo is cover-cropped into the whole sheet, and `old-film-portrait` is the PNG turned 90° CW, so the pair is one frame standing and one lying. The torn edge has no straight sides, so the photo runs under all of it instead of being cut against a measured window.	2026-10-02 19:54:42 +07:00
3dtours	84b8e64652	feat(frame): add OLD FILM LANDSCAPE and OLD FILM PORTRAIT from old_film.png	2026-10-02 19:46:06 +07:00
3dtours	256fe6c2e2	fix(raw): refine RAW highlight clipping threshold to preserve sunset sun color without white dome clipping	2026-10-02 18:15:21 +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	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	3f5ef88de5	web: the mark of a reading follows the folder the walk stands in, and the head of the tree never wears it ... The mark was pinned to the folder a reading was kept to, which is a fine thing to say and no use at all to look at: a reading kept to the roll is kept to the roll for the whole of an afternoon, so the one row that said anything said the same word from the first frame to the last while the walk went through every folder under it. The reader asking which folder is being read was told, in answer, which folder they had asked about. A reading is where it is, not where it was pointed, and where it is is a thing only the reading knows — so the walk now tells it. The frame in hand names the folder it sits in, and the progress carried to the screen says so with the rest, which is where the column reads it. The mark is a way down and not a single row: the folder being read says so, and so does every folder above it. That is what keeps a reading visible under a branch folded shut — the row doing the work is the row the fold takes away, and the rows above it are all a reader would have left. Two rows say the same thing and no more, which is the point: the eye follows the marks down to the work. The head of the tree is never one of them, and this is the rule that survives from the last reading of the question. A roll is the head of everything under it, and a head marked while one folder below it is read says the whole of the tree is being read — an answer that is both loud and false, and worse than the silence it replaced. So the mark stops one row short of the top. The one case left bare is a reading whose frames sit in the roll's own folder and nowhere else: there is no row between the work and the head, and a flat roll is a roll in which the toolbar's line, which names the count, is the whole of what there is to say.	2026-10-01 20:30:25 +07:00
3dtours	4f87f022da	web: a reading of a hundred thousand frames says where it is once, counts what the catalogue holds, and keeps a quarter of the disk it kept ... A roll of a hundred thousand frames is read by a walk that tells the screen about every frame it lands. The column is redrawn out of that count, so the telling was a whole tree rebuilt a frame at a time — on the large library that is the reading spending its afternoon drawing itself, and to the reader it looks like a scan that has started over from the top every time the column breathes. Five tellings a second is a counter that still moves to the eye and a page that is doing the reading instead; every frame still lands in the counts, and only the copy the screen reads waits. What the counter said was wrong twice over, and both were the same mistake told two ways. The total was the frames already reached plus the frames still in the queue, so a roll whose catalogue already holds most of it announced itself as `29980/61211` — the numbers of the reading underneath, printed as if they were the numbers of the roll. The reading now measures itself against the frames the catalogue already holds of the folder it was pointed at: the roll's own size while the walk is still up in its first folders, and the frames under a subfolder alone when it was kept to one. And a row says at least what the catalogue holds of it, never less — where the reading's number alone had the head of the tree count 29980 while the line above it counted a hundred thousand, one question with two answers. Nor is a scan of nothing announced as `0/0` before its first pass has come back; the line waits until it knows what it is reading. The third thing is not a number but a weight. The tile kept for a frame is the tile the grid cell and the strip both paint, and there is one of them per frame of a roll that reaches six figures. At 512 on the long edge a tile weighed 42KB and a hundred and sixty thousand of them weighed six and a half gigabytes of the reader's disk — for a grid cell that is ~240px wide and a strip tile that is 132. A quarter of the pixels at the quality Lightroom keeps its own grid previews at puts the same picture in the same cell: the tile is now ~12KB and the roll a quarter of the disk it was. The canvas a tile is drawn onto is told it is opaque, so it no longer carries a channel of noughts through every draw and every encode. The stage loses a little softness at 2.4x, which is the trade and is known.	2026-10-01 18:31:08 +07:00
3dtours	c93f9fdd19	web: a scan right-clicked inside the tree reads that folder and what lies under it, and leaves the rest of the roll alone ... A roll is dated folders inside dated folders, and the reader who wants April re-read is not a reader who asked for the four years around it. Right-clicking a subfolder row carried the roll's own menu, and RESCAN on it read the whole tree from the top — every folder of every layer opened again, every frame in them asked for its size and its time, to reach the one folder the pointer was on. On a library of a hundred thousand that is a walk of minutes for a folder of twenty. The scan now takes the folder it was pointed at, spelled as the walk spells a path: '' for the picked folder, `2026/04/` for a subfolder. The walk is handed that path as its queue and reads down from there, so the tree is entered three levels in rather than at its root, and the menu row passes the path of the row under the pointer. A right click on the head of the tree still reads the whole roll, which is what a right click on the picked folder has always meant. What a reading kept to one folder must not do is speak for the roll. What it names in the column is a branch of the tree, so the column keeps what it has and the rows outside the folder being re-read stand where they are. What it counts is a branch too, and its numbers drawn over the rows would count a roll down to one folder of itself, so the column falls back on the catalogue until the reading is through — the frame the reader is waiting for is the frame that was re-read, and it is in the column the moment it lands. Nor does it write a position down. `walk/ROLL.json` belongs to the reading that walks the whole roll: a fraction of the tree written into it hands the next visit a roll with the rest of itself missing from the walk, and it clears a file another reading may be in the middle of. One folder is short enough to read again, and the frames it does not re-read are skipped on their size and their time anyway. A jump is refused for the same reason — the reading answers to the folder it was kept to, and a click elsewhere is a different reading's business.	2026-10-01 17:29:47 +07:00
3dtours	39f80088c7	web: a folder is chosen by picking one — the backup row names it and opens the picker, and restore always asks which backup ... RESTORE was dead on a machine that had never written a backup: the button was `disabled` while no folder was remembered, and nothing in the handler could ever pick one, so the reader who had carried a copy over on a stick had no way to point at it. The button now stands, and the folder it restores from is whatever the reader picks in the dialog that opens — which is the whole of the choice there is, because a backup is a folder of rows and tiles. The folder on the other disk, the one made before the edit: the folder is the version. BACK UP asked for a folder only the first time one was ever chosen. After that it wrote into it in silence, and after a restart — when the browser takes the permission back, since a permission outlives the tab only while the tab does — it wrote nothing and said so, which is a backup that quietly stops happening. It now picks whenever it cannot write, and the picker is the only thing that can hand a remembered folder its permission back; a permission asked for with no picker behind it is one the browser may refuse. The run that follows a scan is untouched: it is guarded by the permission it would be asking for. And the folder is a control, not a caption. The line that names it — with the frames in it and when they were written — is what tells one backup from another, and pressing it is how a folder is picked, a name given, a permission handed back. It keeps the hint's own look through five lines of CSS, so the row still reads as a caption and not as a third button. What the line says is now read out of the folder rather than out of this browser's memory of it. `pickBackupFolder` reads the catalogue file inside the folder just picked and takes its count and its date as the row's own; a folder with no catalogue of its own has none, and the row says so instead of showing the numbers of the folder next door. That is also what the confirm names before a restore — the frames and the time in the folder just picked, which is the thing about to be restored. `restoreNow` already read that file; this reads its header first. Checked on the running bundle with the picker stubbed, since the dialog is one a probe cannot press: with nothing remembered, RESTORE now opens the picker where it did nothing at all, the row names the folder the picker returned, and a folder without a catalogue of its own is refused with a line saying so rather than restored as an empty catalogue. BACK UP opens it too, from the same fresh state. The line computes to a button with no border, no background, the page's own font and the hint's own 12px dim grey — a caption that happens to be pressable. The wall, the strip, the grid, the deep link and the phone's recipes all pass their checks.	2026-10-01 17:12:29 +07:00
3dtours	e2d468b77d	web: a scan hands its frames to the strip as it reads them, and coming to the library no longer walks the roll behind the reader ... LIBRARY drew the strip from the catalogue and the catalogue from a `getAll` of the `photos` store: every row and every thumbnail in it, read back on a clock to learn what a scan of its own had just stored. On a catalogue of 150,000 frames one read measured 2036ms and sixty megabytes of rows; under a scan in the same window, with four lanes of RAW bytes and a LibRaw of a quarter of a gigabyte beside it, that read is the read that gives way — and a read that gave way answered `[]`, so the screen threw away the frames it was showing. That is the strip that loses its count and its thumbnails under a scan, and the frames the reader cannot pick while the roll is being read. The reading now hands its frames over as it stores them. `scanFolder` keeps the rows it met for the first time in the batch they landed in, and `flush` gives them to `watchRows` the moment the transaction closes; the screen appends them, so the strip is the roll arriving and not the roll found again. A batch is fifty frames, so this is fifty rows over a callback where it used to be a hundred and fifty thousand rows over IndexedDB. A frame the catalogue already held is not handed over — it is on the strip already, and it takes its place again when the reading is through. Which is why the read on the clock is now done for none of them. It stands for the reading another window holds, whose frames never come through this one: a reading of this window's hands over every frame it stores, and the counter that says so is what decides. The scan's own tail read went with it — the screen watching a reading reads the catalogue back once the reading ends, and that is the whole catalogue read once per scan instead of twice at the end of every one. `readPhotos` answers null where `listPhotos` answered an empty list. A read that came back with nothing is a read that failed, not a catalogue that emptied, and the frames it would have cleared are the frames the reader is working their way through. The strip keeps them. And the strip starts on what the last screen read. STUDIO and LIBRARY are two screens of one page, not two pages: the reader who goes to develop a frame and comes back was reading a hundred thousand rows again to see the strip they had just left. The folder is walked on the way in only when the last reading of it never finished. A reading that reaches its end clears its position, so "is there a position" is "was this roll cut off", answered by one small file opened and shut. Before this, every visit to the library paid a walk of the folder the reader was opening — a hundred thousand names off the disk, on the folder they had just asked to browse — and the reader who came to choose a frame paid for a scan they never asked for. A folder the reader wants looked at again says so itself, from the menu on its row. Checked on the running bundle: a 3000-frame scan reads the catalogue back twice, one of the two the screen coming up on a catalogue that is still empty — against three for the commit before this one and thirteen for the one before that, and nothing read back for the whole of the scan. The peak heap is 116-138MB with no long tasks, and 3001 rows went in. A reading stopped at 59 of 4000 still leaves `walk/ROLL.json` at 113,626 characters with no local storage key beside it, and the visit after a reload carries on with the strip filling under it — 162 rows, 312, 463, 612, 762, 913, 1062, 1212 as the scan went on. LIBRARY on 150,000 frames shows no "No folder yet" at any point and settles on "150000 photos" in 4.9s against the 8.1s it took. The wall, the strip, the grid, the deep link and the phone's recipes all pass their checks.	2026-10-01 17:00:53 +07:00
3dtours	137d54d37d	web: a scan watches the catalogue on a clock and keeps its place in a file, not in five megabytes of local storage ... LIBRARY read the whole catalogue back on every batch the scan wrote: `reload()` is a `getAll` of the `photos` store, every row and every thumbnail in it, and on a catalogue of 150,000 frames one read was measured at 2036ms, twenty of them at 315s with the worst at 58s, the heap behind them going from 44MB to 89MB — beside a LibRaw open of a quarter of a gigabyte and four lanes of RAW bytes. On a folder of RAW that is the crash, and on any long roll it is the strip taking the roll's own time to move. The read-back now runs on a clock: at most once every five seconds of a scan, and once more when the reading ends, which is when the last of it is due. A batch lands every second or so, and reading it back costs every frame in the catalogue — so a scan that read it back each time spent the roll doing nothing else. The strip still fills while the scan runs; it fills in steps. The walk's own position went to the origin private file system. It is one path per frame the walk has found and not read — about twenty-eight characters each, measured over a folder of three thousand, which is the 85,626-character write — and local storage on this origin takes 5,000,000 characters and then throws, measured the same way. That is a hundred and seventy-five thousand frames: past it the first write of a long roll fails, the position is nowhere, and the next visit walks the whole roll from the top. That is the reading that goes back to the start, and OPFS takes the same text as a file. It goes down at most once every two seconds, for the same reason the catalogue is read back on a clock: the string is a few megabytes of paths. The folder is walked again for being raised no more than once every thirty seconds. A hundred thousand frames is a hundred thousand stats on the disk, and this screen is raised every time the reader comes back from the studio. And the column no longer says there is no folder before it has looked. The note waited on `folders` alone, which is empty for as long as the screen is coming up: on the catalogue of 150,000 it said so for the whole of the load and showed the folder after. It now waits on `loaded`, and says nothing until there is something to say. Checked on the running bundle: a 3000-frame scan reads the catalogue back 13 times where the code read it back once per batch, writes the position 21 times, and leaves the peak heap at 116MB with no long tasks. A reading stopped at 483 of 4000 leaves `walk/ROLL.json` at 101,107 characters naming 3,550 unread frames, with no local storage key beside it, and the visit after a reload carries on at 585 rather than at the top. LIBRARY on 150,000 frames shows no "No folder yet" at any point and settles on "150000 photos". The wall, the strip, the grid, the deep link and the phone's recipes all pass their checks.	2026-10-01 16:34:46 +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	3e3045d912	library: the reading is copied into a folder of the reader's own, so a cleared profile gets it back without a frame being read twice	2026-09-30 16:41:11 +07:00
3dtours	325d5c0470	library: the walk position belongs to the origin, so the app beside the browser carries a reading on instead of listing the roll again	2026-09-30 16:26:42 +07:00
3dtours	75ff444621	library: the screen reads the catalogue back when a batch lands, not on a 700ms timer, and a tile keeps the object URL it was given	2026-09-30 15:41:18 +07:00
3dtours	c9e72595f7	library: the other window on the same origin draws the scan instead of running a second one ... An installed app and a browser tab are one origin, one catalogue and one roll. Without a word between them the second window opens, finds nothing in flight, and reads the same frames again — two readers of one folder, two RAW decoders at 256MB apiece, for a progress the first window already has. The window holding the reading now announces it on every frame and on a heartbeat, and answers a window that has just opened and asks. A window that does not hold the reading takes it as its own: the same progress line, the folder marked as being read, the same STOP — which it relays rather than redirects — and the same jump. What it does not do is read the disk. A reading that is through leaves the catalogue behind, and a window watching it has nothing left to be told, so the screen reads the catalogue back once more when the session goes away: the frames that arrived with the last flush would otherwise never be drawn in the window that was only watching. Measured over one origin (two pages, 24 RAW frames): the second window read 25 frames before and 1 after (the open frame), the peak over an idle browser fell from 1412MB to 1155MB against 944MB for a single reader.	2026-09-30 12:58: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	64d41f67e9	library: read one RAW at a time, and hand the decoder a size it already read ... A folder of RAW took the page down. The catalogue reads four frames at once — that is what makes a roll land quickly, and for a JPEG it is free — but a RAW is not read by this page at all: it is handed to libraw-wasm, which opens it inside a worker of its own, and that worker is built with a quarter of a gigabyte of linear memory (emscripten's shared memory, 256MB, instantiated per instance) and the whole frame is copied into it. Four of those at once, on frames of 22.6MB, is past what a renderer is given before a single tile is drawn, and the page goes with it — which is the crash this answers. One open at a time now, whoever asks for it: the gate wraps the read of a RAW and nothing else, so the frames around the one being opened still have their bytes read off the disk, their decodes run and their tiles encoded side by side. Only the open queues. A folder of JPEGs never touches the gate and keeps all four lanes. The tile also stops asking the decoder a question the bytes answer. A JPEG — and the preview a camera writes inside a RAW is one — carries its frame size in its own header, in the first few hundred bytes the read already holds for the date. `jpegSize` reads it there, and `tile` is handed the size instead of decoding the whole frame a second time only to learn which edge is long. `jpegSize` existed for exactly this and had no caller; it has one now. Verified: - library-check.mjs, scan-nav-check.mjs, roll-walk-check.mjs all pass against the built bundle — the catalogue still reads a roll, a RAW still becomes a tile off its own preview, a frame still says where it was shot, an interrupted reading still goes on by itself. - A stand-in folder answered `showDirectoryPicker`, 48 frames of 22.6MB, resident memory of the whole browser process tree sampled every 150ms: - before: 4 frames read at once, peak RSS 1335MB, 565MB before the roll was picked, 12s, 48 tiles, no error; - after: 1 frame read at once, peak RSS 1180MB, 32s, 48 tiles, no error. The 2.6× on the clock is mostly the harness: its `getFile` copies 22.6MB per frame, so serialising the open serialises that copy too. A real folder pays a disk read and an open in sequence instead. - 200 frames of 8.5MB JPEG, same harness: peak 1713MB, 4 at a time, 200 tiles, no error — the JPEG path is untouched by this commit. ponytail: reading a RAW could skip LibRaw entirely — the camera's preview is a plain JPEG and could be cut out of the head of the file this page has already read. Probed on four samples: RW2 carries a 1920×1280 preview at 54KB, NEF one at 6016×4016 of 1.08MB, but DNG has only 720×480 inside its first 4MB and RAF keeps almost none, and picking the wrong segment risks a thumbnail for a tile. Not worth it until a RAW that is neither DNG nor RAF is the common case. The JPEG path still peaks high (1713MB over 200 frames) and that is `createImageBitmap` decoding every 5472×3648 frame whole, at four lanes — an app that reads fewer at once trades time for the same headroom, if a page that large is ever the crash again. Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-29 16:08:26 +07:00
3dtours	53cb1c97e9	web: a frame is scored under the picture, and the wall is read through the score ... The catalogue could say what a frame was and when it was shot, and nothing about whether it was any good. A reader who had been through a roll of two thousand had no way to say "these four", and the thumbnail wall drew every frame the open folder held in the one order it had: newest shutter first, always. The frame that is up now carries its own score — five stars under the picture, and the star the click lands on is the score it gets. The star it already has takes the score back, so a score that was given by mistake is taken off without a sixth control. It is the catalogue's own row and nothing on the disk is touched: the file is not written and not read, the browser only stores one more number against a frame it already holds, and the number is the reader's. The wall is read through three of them. The score is the first — four stars and up is the floor, any rating is the wall as it was — because that is what a reader who has just been through a roll wants next. The year the shutter fired in is the second, offered as the years the open folder actually holds and not a century of empty ones. The hours it fired in are the third, as a from and a to: 16:00 to 18:00 is the afternoon the reader was out, and either end alone is "from 16:00" or "up to 18:00". All three read the shutter time, on this machine's own clock — the same reading the frame's date line prints, so the afternoon is the afternoon and not an offset of it. Beside them, the order: the newest shutter first, the oldest first, or the most stars first. What the filters hold is the wall and only the wall. The strip under the picture is the shelf the open folder is, and a shelf that quietly loses three quarters of its frames is not a shelf any more; the frame that is up has to stay reachable while the wall is narrowed around it. That is also why the filters are drawn in the thumbnail view: they are a way of looking through the shelf, not a property of the roll, and nothing about them outlives the visit. Verified: library-check.mjs — 52 steps, all passed, five of them new. The frame that is up is scored from the row under it and the catalogue holds star 4 against it (aria-pressed on the fourth star true); the wall narrows to one tile at 4★, to none at 5★, and back to three with the rating cleared; the year 2016 holds the two JPEGs of three and 16:00–18:00 the same two, out of a roll whose frames are written years apart in different parts of the day (the JPEG in the afternoon of 15 Feb 2016, the RAW at seven in the morning of 1 Jan 2026); read by score, the scored frame comes first. Every earlier step still holds, including the two that count what a reading costs and the stand-in folder's two frames — the JPEG carrying the GPS tag and the RAW printing "26.4mm · f/2.8 · 1/320s". scan-nav-check.mjs, roll-walk-check.mjs — all passed. frontend tsc --noEmit clean, vite build clean. ponytail: the score is one number on the frame's own row — no rating table, no votes, no accounts; the catalogue is a per-browser shelf and so is the score. The filters live in the thumbnail view's own state, so a reload starts with the whole shelf again, which is what a filter is for. No text search: a roll of date folders is three levels deep at most, and the three that a reader actually digs with are the ones here — add the box when a folder of mixed names makes one worth typing into. Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-29 08:02:05 +07:00
3dtours	477c71d1f4	web: the frame under the preview says where it was shot and what it was shot with ... A negative is opened to be looked at, and the two things a photographer reads off it first are the numbers the camera wrote and where it stood when it wrote them. The stage gave the name, the folder, the date and the weight of the file, which is what the catalogue knows; the rest was a trip into the studio. Both are now under the picture. The numbers are the camera's own — ISO, focal length, aperture, shutter, frame size — printed in the order a photographer says them, and every one the file does not carry is left out rather than stood in for: a Fuji RAF gets no line at all, a Panasonic RW2 gets the glass and the shutter and no ISO, and a JPEG gets the lot. Where the frame was shot is the GPS it carries, named by the geocoder when one answers and left as the coordinates it holds when none does — a naming is a network round trip on a PRO account, and the numbers do not wait for it, so a refusal or a miss costs the reader nothing. What this costs is one read of the frame's first few hundred kilobytes, the same head a scan hands the parser, and only the frame that is up pays it: the strip walks past a hundred negatives without reading one of them. The read is held by the read itself and not by the frame object under it, because the catalogue is read back on a timer while a scan runs, which hands the screen a fresh object every few hundred milliseconds — a screen that went by the object would read the same file again and again for as long as the scan lasts. The check's stand-in folder had no frame of its own with a GPS tag on it, and none of the samples carries one, so the check writes one: an APP1 segment holding a GPS IFD and nothing else, spliced in right after the frame's SOI. It is deliberately the first APP1 — a JPEG carries one EXIF segment and the catalogue reads the first, so a file that has a place is a file that spent its EXIF on the coordinates. That is also what makes the RAW the frame that shows a spec line, and the two frames now check the two halves of the same feature. The run counts what a reading costs, and a head is not what it counted before: it counts the whole file a lane develops apart from the head a parser is handed, because "the RAW was read" is a claim about the scan and the preview legitimately reads the same file's head. Verified: library-check.mjs — 47 steps, all passed, two of them new. The JPEG off the check's server carries a GPS tag and the page keeps 16.0544, 108.2022 under the frame, with no geocoder behind it to name them; the RAW prints "26.4mm · f/2.8 · 1/320s" — the glass and the shutter it has, no ISO and no frame size it does not. Every earlier step still holds, including the one that says a scan does not read a RAW whose size and write time have not moved: whole reads {}, heads {"P1010256.RW2":1,"P1010256.JPG":2}, the one RAW head being the frame that is up. scan-nav-check.mjs, roll-walk-check.mjs — all passed. frontend tsc --noEmit clean, vite build clean. ponytail: the place is named by the API's geocoder and nothing else — no map, no picker, no place a reader can type. The coordinates are what the file carries, and a file that carries none shows no line, which is the honest answer and the common case for a phone frame with location off. The line is read for the raised frame only; a grid of hundreds is a list of names, and a row of ISO numbers under each tile is not what it is for. Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-29 07:57:36 +07:00
3dtours	753eea0d7b	web: a reload in the middle of a reading goes on, it does not start over ... The reader opens a roll of a few thousand frames and holds Ctrl+Shift+R while it is being read — over a reading that takes minutes, that is the one thing they do. What came back was a reading that started again at the top: every folder listed a second time, the toolbar counter back at zero, the frames that were already in the catalogue walked over so that their size and their write time could say they had not moved. None of that was in the catalogue, because the catalogue only holds the frames that were read. What was lost with the page was the reading's position: the folders the walk had been through, the folders still in its queue, and the frames it had found and not yet read. The catalogue alone can never answer where a reading was. The position is now written to session storage as the reading goes — walked, pending and the frames in hand — and read back on the way in. Session storage and not local storage, because a position belongs to the tab: the tab that reloads carries on from the frame it stopped at, and a tab opened beside it starts a reading of its own. The key goes when the reading finishes, and goes with the folder when the folder is removed. The frames in hand are the part worth spelling out. A frame a lane is in the middle of, and a frame whose row is in the batch and not yet in the catalogue, are on neither side of the line the position is written on: the catalogue does not hold them and the walk will not find them again, so both are written into the queue and read again. They also were counted when they left the queue, and the count is written with them — else the reloaded reading would count them a second time. The counter now carries on from where it was instead of restarting from zero. One thing was hidden behind the other: the stand-in folder the check hands the page had no `getFileHandle` and no `getDirectoryHandle`, so the path that asks the root for the frames a position names threw and answered nothing — and the reading then walked the roll from the top, exactly the behaviour the check was meant to catch. The check's folder answers both now, the way the browser's does. Verified: library-check.mjs — 45 steps, all passed, two of them new. The reading is stopped on the frame it is reading (`check.hold`), the tab is reloaded, and it comes back at "Scanning 3/3 — 0 new…" — the same line it was stopped at, not a reading starting over — with the position still holding 4 folders walked, an empty queue and 3 frames in hand. Listing 3 tiles and letting the key go, the reading finishes the roll: 3 tiles in the strip, the catalogue written, the position cleared, and every folder listed once ({"2026":1,"CheckRoll":1,"Empty":1,"04":1}) where a reading that started over lists each of them twice. scan-nav-check.mjs, roll-walk-check.mjs — all passed. frontend tsc --noEmit clean, vite build clean. ponytail: the position is the tab's, so a reload keeps it and a new tab does not — the tab that reloaded is the one the reader is looking at, and a second tab reading the same roll from the top costs a walk and no bytes, because a frame that has not moved is dropped on its size and its time. The position is written at the batch beat, so a reload reads at most one batch again, and the frames in hand are read again on purpose: their rows were never stored. Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-29 07:50:01 +07:00
3dtours	d7241531f9	web: a reading walks past the recycle bin, not into it ... The walk already turned its back on the folders a camera and an editor leave behind: a name beginning with `.` or `@` is skipped, which is `.thumbnails`, `.git`, `.Trash`, and the `@eaDir` a Synology writes beside every frame. An external volume drags along a second set of names, and none of them begins with a dot, so every one of them was walked. `$RECYCLE.BIN` and `RECYCLER` are where Windows parks what the reader deleted — frames among them, at full size, and every one of them decoded into a thumbnail on the way in. `System Volume Information` is Windows' own bookkeeping. `#recycle` is the Synology share, and `lost+found` is the directory a Linux volume keeps for repairs. A frame that comes back out of a bin is a frame the reader threw away, and the pictures in a share's recycle folder are pictures someone else deleted; neither belongs in the catalogue, and both cost the reading the same seconds a real frame does. The folder also stood in the column as a row of its own. The rule is now one `SYSTEM_DIR` expression over both sets, matched case-insensitively — the same volume spells the bin `$RECYCLE.BIN` on one drive and `$Recycle.Bin` on the next — and the walk asks it before it looks at what the entry is, so a refused folder is neither read nor named. Verified: roll-walk-check.mjs — all passed, with two new assertions: the stand-in roll now carries `$RECYCLE.BIN`, `$Recycle.Bin`, `RECYCLER`, `System Volume Information`, `#recycle` and `lost+found`, and every one of them holds a file named like a frame, so nothing about the files can be what keeps them out. No frame is read from them, and none of them reaches the column. library-check.mjs — 43 steps, all passed. scan-nav-check.mjs — all passed. frontend tsc --noEmit clean. ponytail: the list is the names the volumes being read actually use, not a guess at every spelling there is — a box that files its junk under something else gets a line in that expression, which is the whole of the change. A folder of the reader's own that happens to be called `#recycle` is skipped too; that name is worth the trade. Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-29 07:10:41 +07:00
3dtours	fbe9a1bb5b	web: a roll is read where it was left, and only for the frames that moved ... A reader with a large roll ran into three things at once, and they were one thing: a reading is dropped the moment the tab goes, and the second one over the same folder took as long as the first. The catalogue was never emptied — `scanFolder` has no delete anywhere in it — but it read every frame again. The test that was meant to skip a frame that has not moved compared the frame's *shutter* time with the file's write time (`seen.taken === file.lastModified`), two numbers that are equal only by accident: a still's EXIF date is when the picture was taken, not when the file was written. So a rescan of any indexed roll went back to the disk for every file, decoded every frame and wrote it back — which is what reads as "it threw the index away and started over", and it cost the same minutes the first read did. A frame that cannot say when it was taken was worse off: it falls back to the file's own time, so it matched, was skipped forever, and never picked up an edit. A row now carries `mtime`, the write time the browser reports for the file, and a frame is skipped on the same size and the same write time — which is what the comment over that line always claimed. A row filed before the field existed has no `mtime` and is read one last time. On the 36-frame roll the bench serves (24 JPEG 8.2MB + 12 RAW 22.6MB, two levels deep): first reading 5209ms the same roll again 2887ms 24/36 frames read again first reading 5320ms the same roll again 603ms 0/36 frames read again And the screen starts that reading itself. Opening LIBRARY on a roll whose reading ended when the app did now walks it again on the way in — and again when the tab is raised — so the frames it never got to are read with no one asking, and frames that landed in the folder since are picked up by the same walk. The scan belongs to the tab and the walk skips what the catalogue already holds, so a frame that has not moved is a name, a size and a time and nothing else; the run that does it says nothing in the toolbar, the ring on the row and the progress line are the report. The folder menu's commands lead with a mark of their own — fold ▴, rename ✎, scan ↻, forget ✕, reconnect ⚿, add ＋ — the way the tool rail and the view switch already do: a column of marks reads at a glance where a block of uppercase does not. Verified: library-check.mjs — 43 steps, all passed, six of them new: the folder menu's three marks, the row menu's four, the add-only menu's one, the refused folder's lone reconnect carrying its ⚿, a reading cut short that goes on by itself (three rows back, and the bytes read are the two frames the catalogue had lost, not the one it still held), and the folder read again from its own menu. The stand-in folder now carries `__fake` on both handle kinds — a folder handle that does not is one the screen cannot ask about after a reload, which is a folder it offers to reconnect — and the frames it hands out report one write time instead of `Date.now()` per call, which is what a real handle does and what a frame is skipped on. scan-nav-check.mjs — all passed, the row still counting the reading as it comes rather than the catalogue standing still. roll-walk-check.mjs — all passed. frontend tsc --noEmit clean. ponytail: nothing watches the folder, so a roll that changes under a screen left open is picked up on the next visit or the next raise, not on the change — a FileSystemObserver when the browsers ship one. A frame is skipped on size and time alone, so an edit that keeps both is invisible until that frame is read again; the row's own rescan is the way to ask for exactly that. Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-29 06:33:41 +07:00
3dtours	77729ad99a	web: read the roll through four lanes and a JPEG's header ... A scan of 36 real files off the local disk took 8957ms — 249ms a frame — and the page was idle for nearly all of it: a CPU profile over the walk is 61.5% idle, so what the catalogue was doing was waiting, not working. Of that time the bytes and the LibRaw preview are 2656ms and the tile 5761ms, while the EXIF read is 14ms of the lot. One frame at a time spends the disk's latency and the decoder's thread on nothing, and a JPEG was read whole — 8MB through a JS array to find a date in its first kilobyte — then decoded at 24MP to be drawn at 512px. The walk now runs four frames at a time. A frame that is new is read as a 256KB header slice unless it is a RAW, which LibRaw has to have whole to seek to the preview inside it; the shutter time comes off that slice. The tile is asked of the decoder at 512 on the long edge, so a quarter of the pixels of a 24MP frame are ever allocated, and the aspect comes from the frame's own SOF header for a JPEG and from an eight-pixel decode for anything else; the canvas is left to re-encode what comes back. The column still counts a frame the moment the scan reaches it, so which frames are up is unchanged, and a frame that has not moved is still dropped on its size and its time before a byte of it is read. Measured on the same roll (24 JPEG 8.2MB + 12 RAW 22.6MB, two levels deep, served over loopback with no added delay): one frame at a time 8957ms 249ms/frame four lanes 5474ms 152ms/frame + the header slice 4793ms 133ms/frame Six lanes came out worse than four (5259ms) and is not what this does: past a few the disk and the decoder are the limit. Verified: library-check.mjs — 35 steps, all passed. scan-nav-check.mjs and roll-walk-check.mjs — all passed. frontend tsc --noEmit clean. Live 8090 on index-CdakqRi8.js matching dist/: /, /library and /app 200 with 0 console errors. ponytail: the lanes run on the main thread, and a RAW still reads whole per file — a few LibRaw opens at once now — so a 5000-frame folder is still lumpy; move the walk into a worker and a RAW's preview onto a sync handle when that is real. A frame smaller than 512 is now scaled up to it rather than drawn at its own size, which is invisible at the 132–220px a tile is painted at; keep the old fit if a print is ever taken off a tile. Co-authored-by: PenguinHarness <noreply@penguin.local>	2026-09-28 22:01:03 +07:00
3dtours	1cb2618fd7	web: count a roll as it is read, and open a frame without losing the count ... Two holes left by the last change. A frame is opened with `window.location.href` rather than a link, so the studio was still handed a fresh page and the scan with it — every route out of the catalogue now goes through `go()`, which pushes the address instead of reloading while a scan is in flight. And a row counted what was filed away rather than what had been read, so it sat at zero for the whole of a first scan: the catalogue's frames only reach IndexedDB in one batch at the end. `ScanProgress.counts` carries the frames the scan has reached, per row, off the scan's own bookkeeping, and the column reads it while the scan runs — the row under the reader's eye moves as the roll is read, and the toolbar's line stays the whole picture. A re-read counts from the start, which is what it is doing. The regression check grows the two: a frame opened mid-scan from the catalogue (of a roll it already holds) has to stay in the page, and the row has to count.	2026-09-28 20:39:51 +07:00
3dtours	79b0d0db86	web: keep reading a roll while the studio is up ... The catalogue hands the visitor to the studio with a plain `<a href>`, and the app has no router: following it threw the page away, so a scan that was halfway through a roll died with it. A scan belongs to the tab, not to the screen that started it. The scan now lives outside the component (`scanSession`/`startScan`/`stopScan`, watched by whoever is up), so the catalogue can unmount and come back to a reading that never stopped; a screen that returns joins it and sees the toolbar line, the stop button and the rows filling in. The internal links are taken over for a history push *only while a scan is in flight* — everywhere else the browser navigates exactly as before, so the landing-to-studio flow is untouched. `scripts/scan-nav-check.mjs` is the regression: a roll read one frame at a time off a slow server, handed to the studio mid-scan, back to the catalogue, and the whole roll read to the end with the studio up, counting documents along the way.	2026-09-28 20:28:00 +07:00
3dtours	3aedd67ca0	web: open the catalogue without a version another tab can block	2026-09-28 20:16:58 +07:00
3dtours	52732a17ee	web: name a roll's folders before reading their frames	2026-09-28 20:06:10 +07:00
3dtours	d0fddba1e8	web: walk a roll layer by layer, and let the strip drop the branch	2026-09-28 19:55:02 +07:00
3dtours	4c65923eff	web: rename a folder, and add one from the empty column ... A folder's own menu gains a rename, which paints a label over the folder without moving it — the frame ids and the recipes hang off the directory's name, not the label. The empty part of the column answers a right click with ADD FOLDER, the FOLDERS heading goes (the count already rides on each row), and the column narrows to 118px so the stage takes the room.	2026-09-28 18:38:02 +07:00
3dtours	d1abda141a	web: browse the catalogue as a tree of folders ... The library page was a flat wall of thumbnails. It now reads like the admin pictures tab: a folder tree on the left, the picked node's frame on the stage, that node's frames in the strip below, and a chip pair to swap the stage for a wall of every thumbnail in the node. Folders are walked recursively (dot/@-prefixed names skipped, an unreadable subfolder is dropped rather than failing the scan), so a roll with a dated subfolder keeps both levels. Node counts include the subfolders underneath.	2026-09-28 18:15:14 +07:00
3dtours	81637b8502	web: a catalogue of the folders on the visitor's own disk ... A RAW studio that cannot see a folder is one photo at a time. /library now takes a folder through Chromium's directory picker, keeps the handle in IndexedDB so the folder is there on the next visit, and walks it into a grid: one thumbnail per frame, the frame's own date, and the recipe it was last graded with. Nothing is uploaded and nothing is read twice — the RAW itself is opened only when a tile is clicked, at which point the studio develops it and the recipe comes back on top. The studio files every change back against the frame, debounced, so reopening a RAW is not doing the grade again. Thumbnails come off LibRaw's unpack_thumb for a RAW, which is a seek and a copy where a develop is a full decode of every pixel, and off createImageBitmap for anything else. A RAW with no preview inside it gets a placeholder tile rather than a minute of decoding per file. node scripts/library-check.mjs ok both frames indexed as tiles — 2 tiles from P1010256.JPG + P1010256.RW2 ok thumbnail for P1010256.JPG — 40400 bytes, jpeg=true ok thumbnail for P1010256.RW2 — 39895 bytes, jpeg=true (LibRaw preview) ok studio developed the frame from its handle ok the address was handed back — url=/app (no ?lib= left behind) ok the look was filed back against the frame — baseFilter=none, 19 knobs ok the tile says the frame is edited	2026-09-28 17:46:12 +07:00
3dtours	d1e9425b9c	web: read a frame's white off its pile, not off its largest sample ... sensorWhite hung its nine counts of window off the plane's largest sample. A hot pixel sits hundreds of counts above the level the sensor stops at, so on a frame that carries one the window held the stray alone, found no pile in it, and handed the develop the factor two instead of the frame's own level. Measured on a Panasonic DMC-LX10 RW2: one sample at 15993 and one at 14665 over a pile of 9,594,544 at 13855. The frame's level is 1.75x the fall-back, so the develop opened 0.81 of a stop bright, clipped the sky the sensor had held to flat, and the fit to the camera's preview could only pull the exposure back after the highlight detail was gone. Against the camera's own JPEG of the shot, mean |dL| 23.48 and dRGB +8.57,+0.90,+4.90 became 19.14 and +5.32,+1.89,+2.04, and the level itself 7908 (gain 8.2872) became 13874 (gain 4.7236) against the 13855 the plane piled at — 0.14%, 0.002 of a stop. The level is now the highest count the plane piled at, off a whole-plane histogram: `floor` counts is a pile, and the same cliff rule as before still has to hold over the count below it, so a smooth bright sky is left alone and a frame that has not clipped still falls back on the factor two. The same stray was in four of the ten bodies to hand. A Nikon _GDN0447.NEF read the fall-back 8190 where its plane piles at 13806 (gain 8.0018 -> 4.6022, 0.79 of a stop), a Fujifilm RAF 29696 where the documented level is 30993, and a Sony ARW 31742 against the 2.002x the body's ratio was measured at. Six were untouched, and a Canon CR2 develops byte-identical through the change — the window moves only on a frame whose largest sample is not its highest pile. scripts/white-level-check.mjs keeps the LX10 shape: a plane piled at 30995 with a stray above it has to answer 30995.	2026-09-28 15:55:04 +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	b824308182	web: hand the RAW develop's plane to Skia as half, so the GPU keeps its shadows ... An RGBA_F32 image with an sRGB tag comes back off the GPU backend sampled on a 1/255 grid; the same shader on a raster surface returns the floats untouched. The plane is raw/65535, so the shadows the black level is there to keep sit at 1e-3 and quantise to zero -- a 3010x2012 develop landed 41189 pixels under luma 2 with the dark end speckled blue/yellow, against none on the raster surface. A half is uploaded as float, so the plane stays exact either way. Rejects the earlier guess that the render target's colour space was to blame: gpu+rt-srgb and gpu+img-untagged came back byte-identical to gpu. scripts/half-check.mjs checks the conversion: the named encodings, and no plane value in a 14-bit sensor's range moving more than 4.8e-4 relative.	2026-09-27 08:56:42 +07:00
3dtours	610a274103	web: give a RAW the colour its own camera would have given it ... LibRaw is deliberately kept out of white balance and tone here, so a RAW opened in the studio lands on the neutral demosaic — while the JPEG on the back of the camera carried the body's own rendering. cameraMatch.ts holds that difference as one 3x3 per body, fitted offline against the camera's own preview of the same frame and applied in the develop shader right after the sRGB encode. Measured on held-out blocks, mean CIEDE2000 against the camera preview: GR III 5.99 -> 4.28 X100V 8.19 -> 4.22 GR II 11.68 -> 9.73 X100S 7.41 -> 7.27 X-T3 9.03 -> 6.12 The matrix is fitted luma-preserving and the shader holds that exactly, so the profile moves colour and never exposure: a preview that came out dark stays dark, by design. What is left over is largely high-frequency (sharpening, noise reduction, demosaic) — the error keeps falling as the blocks grow. The fits are weak evidence on their own. Validation on colour charts came out poor: the daylight chart is an Adobe DNG Converter export that aligns to the body's own develop at only 0.785 correlation and gets worse with the profile applied, and the tungsten chart is a different illuminant entirely. The honest claims are the self-fit numbers above and that the X100S — whose cast was small to begin with — barely moves. Verified end to end through the real develop: an unfitted body (Sony ILME-FX30) develops byte-for-byte identically to before, and reading the matrix back out of each profiled develop recovers the fitted one. ponytail: one matrix per body, no tone curve and no 3D LUT (a curve on top measured 2% better and needs a spline plus array uniforms). The match is applied to the 8-bit band the develop already produces — give develop 16-bit output if a profile ever has to grade rather than match.	2026-09-26 22:27:38 +07:00
3dtours	432acba9c1	web: put the mask's column away with the tool, and keep a blown highlight's hue ... The column of mask knobs belongs to an armed LINEAR or RADIAL shape, and it stayed on the stage after the hand had moved on: arm a shape, draw it, click another chip or another tab, and the strip of mask sliders was still there belonging to a tool that was no longer in hand. A capture-phase `pointerdown` on `window`, armed only while `maskTool` is set, now puts the tool down in the same gesture that reaches for something else. A press on the rail (the tabs) or on any chip except the shape's own two dismisses; a press inside the column is left alone, because the column's own chips handle their click themselves, and a press on the photo is left alone, because dragging on the photo is how the shape is drawn. It is the dismissal the STRAIGHTEN tool already had, one effect over, so the tab-switch effect needed no `setMaskTool(null)` of its own. A RAW's blown highlight came out magenta, and was measured before it was touched. `example-sony.ARW` through the lab (`rawblow.html`, the same camera white/black and the same `rgb_cam` the app's develop uses): white 16380, black 512, cam_mul green-normalised to (2.581, 1, 1.553). The pixels the sensor could not hold — 0.7% of the frame, raw max channel at or past 0.99 of the white level — average (0.775, 1.416, 1.108) in raw, and per channel 26.3% / 96.0% / 46.7% are at or over white: green is 1.4x the white level while red is still under it. The develop shader clamped every channel to 1.0 BEFORE the white-balance gains, and that one clamp is the whole cast. Green is the channel the gains are normalised to, so it stopped at 1.0, while red and blue — which need their 2.581 and 1.553 — were already past it and were carried over by the multiply. The blown area therefore left the matrix at (1.0, 0.53, 0.62) instead of at white: measured on the develop output, (254.4, 217.0, 242.9) — red and blue 38 above green, which is magenta. On the stage, pixels with red and blue over 235 and green under 225 in the same framing: 1191 with the clamp, 33 without it. The shader now only floors at zero, keeps the channel ratios through the matrix, and fades whatever ran past white towards white (`mix(rgb / mx, 1, 1 - 1/mx)`, the desaturate-to-white dcraw uses for the same problem). The blown area comes out (254.5, 253.9, 246.6): an overflow that stays bright and stops taking a hue, broken per channel at sd 8.7 / 28.0 / 26.4 today against 5.4 / 3.3 / 17.8 now. Whole-frame averages move by 0.008/0.278/0.140 of a level — the fade only touches pixels that were over white, which are the 0.7%. "cannot be rescued" is the second half of the same fact, and it is now a measurement rather than a hope: LIGHT's HIGHLIGHT row is a curve over what develop emitted, and while red and blue were pinned at 255 the curve had nothing to pull on. The fade leaves a compressed ramp there instead, which is what the row now pulls. LibRaw's own reconstruction modes are not the answer on this file: `-H` 1, 2 and 3 hand back byte-identical develop output to `-H` 0 (`pxAt65535` is 0 — the sensor never reached its 65535, only the camera's white level), so `SETTINGS.highlight` stays 0. What the app cannot do is keep the two stops above white, because the band still leaves develop as 8-bit JPEG; that ceiling is named at the point of the fade, for whoever needs RAW highlights recovered rather than merely correct. `npm run typecheck` and `npm run build` are clean (bundle `index-BJy_3HCz.js`). Probes: verify-mask-column (dev server, real photo, arm a shape and draw it, then reach for another chip and for LIGHT and FX — 8 checks, 8 pass: the column stands while the shape is armed, survives a press on the photo and on the shape's own kind chips, and goes on any other chip or tab), rawblow (the real ARW through the real develop maths in the page, before/after chains side by side, which is where the magenta and the reconstruction modes were measured), probe-raw-highlight (the app itself, ARW uploaded, blown pixels counted and the HIGHLIGHT row driven to both ends).	2026-09-26 20:55:05 +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	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	cb1839e36b	web: shoot through the live camera ... The one path where the look is chosen before the picture exists: OPEN CAMERA grades the camera's own feed with the recipe in force, many times a second, and the shutter hands the studio the sensor's still under that same recipe. Preview and file differ in resolution only — the still is `takePhoto`'s own frame, not a copy of the small preview video, with `grabFrame` and a 2d copy of the element behind it for the browsers that ship no ImageCapture. The renderer gains two inputs for it: `sourceImage`, a picture the caller already decoded (re-encoding the camera's frame to JPEG only to decode it again would cost more than the whole render), and `drawTo`, which paints the finished picture instead of encoding it. One render is in flight at a time; a frame that arrives during one is dropped, so a slow device shows a lower frame rate rather than a queue of moments that have passed. The view flashed black on a phone. Setting width/height on a canvas resets its bitmap: measured on the preview, a resize leaves mean 0 until the next render lands, which on this box is 0.5s and on a phone more. The buffer was sized from every incoming frame, and a capture that renegotiates its resolution — which Chromium does when the page is too slow to consume its frames, and this pipeline runs ~2 fps at 720p under software GL — strobed black/picture at every switch. The buffer is now sized on the first frame and after that only when the frame's aspect changes: a same-aspect frame is scaled into it. Swapping a 1280x720 stream for a 640x360 one mid-view now leaves the buffer at 1280x720 with no black frame, and 640x360 renders at 6-13 fps instead of 2. The frames are read from a <video>, which is now IN the document (1px, behind the black backdrop) rather than detached: Safari draws blank frames from a detached video, which is the same black-between-pictures. It leaves the document with the view, and the tracks are stopped, so the camera light goes out. Probes: cam-smoke (feed painted, resolution, frame rate, a monochrome sim reaching the live frames, shutter into the studio, close, console clean), cam-renegotiate (no resize, no blank frame, status line on the frames), cam-close-flip (flip returns a picture; video gone on close).	2026-09-26 08:26:28 +07:00
3dtours	fd2d9935c1	web: filter the exports the model was only smearing ... The upscaler ran for every enlargement, including the ones a plain resample wins: measured on a 2048px source cropped and blown back up it loses to lanczos on PSNR and SSIM at 2x and 3x, and its smoothness reads as plastic skin and lost texture next to it. From 4x — the model's own factor — it stops losing, so the threshold moves to 4 and the crop no longer drags a 2x export through it. The resamples it now carries never set imageSmoothingQuality, and the default 'low' point-samples: a 1px stripe comes out at full amplitude instead of the average of what it crossed. Both callers ask for 'high'. Probe on a 2400x1800 source exported at 4K: 299.9s -> 7.8s, correlation with the source's 1px/2px bands 0.89/0.95 -> 0.98/0.98, grain sd 25.4 -> 47.1 (a plain HQ resize of the same source keeps 16.1).	2026-09-25 20:32:52 +07:00
3dtours	a9030fc0c0	web: give the GPU path a half-precision upscaler ... The GPU export now runs the same upscaler in half precision. The chip is handed 2.34MB of weights instead of 4.88MB, and where its shaders can multiply in fp16 it does twice the work per pass. `realesr-fp16.py` is the conversion, run on what `realesr-gpu.py` already wrote (the PReLU-rewritten model), never instead of it. onnxconverter-common's `keep_io_types` needed two of its own mistakes put right: - It rewrites the consumers of the graph input but misses the one that never goes through the network. This model adds a Resize of the ORIGINAL photo to the upsampler's output, that Resize reads the graph input directly, and the runtime refuses a graph whose final Add mixes fp32 and fp16. The consumer is rewired onto the cast that `keep_io_types` should have sent it through. - It also half-precisions Resize's `scales` — ONNX defines that input as float32 whatever the rest of the graph does, and a runtime that opens the file at all rejects the whole graph: "Type 'tensor(float16)' of input parameter (/Constant_output_0) of operator (Resize) is invalid", on the GPU as much as on the processor. The script widens it back and asserts it did. The tensor the app builds stays float32 and the model's two Cast nodes are its own edge, so nothing in superRes.ts or App.tsx has to know which copy it got: 205 nodes, 101 fp16 weights, io still float. `openSession` asks for the model only where the adapter advertises `shader-f16` — a provider without it emulates the type on the same file at the same speed, so the smaller download would be the only thing gained. The order is fp16 on the GPU, fp32 on the GPU, fp32 on the processor, each attempt falling through on its own failure. Measured on the rebuilt container (BASE=http://localhost:8090): - fp16 vs fp32 on a 128x128 tile, same graph: max abs diff 0.0025 (0.65/255), mean 0.00028, psnr 71.0dB. - sr-f16-chooser.cjs 4 PASS / 0 FAIL: on a forged adapter advertising `shader-f16`, the fp16 file is the FIRST model asked for; on one whose device refuses, the fp32 file is fetched for the processor and the 4K export still lands (7,555,377 bytes, 19.6s), no console errors. - superres-test.cjs 32 PASS / 0 FAIL, sr-crop-export.cjs 0 FAIL, web-smoke.cjs 0 FAIL, sr-model-probe.cjs 0 FAIL. - npx tsc --noEmit clean. ponytail: the speed of the fp16 path is NOT measured — this container has no WebGPU adapter (not even lavapipe/swiftshader, headed through xvfb), so every export here runs the wasm fallback. sr-model-probe.cjs on a machine with a GPU is what would show it. Also worth noting for the next person: in a browser with no working adapter, the runtime builds the device BEFORE it fetches the model, so no probe in a GPU-less container can observe which model was chosen — a stub whose device throws leaves the network silent. The chooser probe forges a device good enough to be accepted for exactly that reason.	2026-09-25 20:01:51 +07:00
3dtours	12113088c8	web: hand the upscaler the photo's own pixels ... An export larger than the photo came back flat: the model was never shown the finest detail the photo held. Before it ran, the source was drawn down to `scale / 4` of its size — floored at half — and only then handed over, on the reasoning that a four-for-one model reading `target / 4` invents exactly the destination and a whole photo would waste three quarters of its output. That holds for a perfect resampler; it is not what this one is. A 2400px photo going to 4K was fed at 1200px, and detail finer than the feed's own pixel — 1px stripes, skin, foliage, fabric — was averaged into flat grey before the model ever saw it. The draw then had that grey to enlarge, and no model can put back what it was never given. The feed is now the bitmap itself, read once at its own size: `drawImage(bitmap, 0, 0)`, no intermediate scale, no floor. The model's four-for-one is spent in the destination draw instead, which reduces to `scale` and keeps what the photo actually held. That draw also stops defaulting to `low` — it is usually a reduction by up to four, and `low` would keep one sample in four of what the model has just drawn. Measured against the same running stack, a 2400x1800 source exported at 4K with bands of 1/2/4/8/16px stripes and a patch of per-pixel grain, each band scored by how it correlates with the pattern the source held at the source's own pixel pitch (`r` / on-minus-off swing), plus the grain's high-frequency energy: p1 p2 grain sd secs before -0.01 / -0.0 0.94 / 204.0 13.9 51.0 after 0.89 / 179.3 0.95 / 214.7 25.3 188.4 hqresize 0.96 / 83.2 0.99 / 125.9 16.1 — The 1px band went from uncorrelated and flat to 0.89 — the finest detail the photo has now reaches the file. Grain lands above the plain-resize reference rather than below it, which is the model enlarging texture instead of a filter smearing it. ponytail: the whole photo per tile means 80 tiles for a 2400px source where 20 were enough, so the wasm path (no WebGPU in the test chromium) grew from 51s to 188s for that export. It is the price of the detail and it is paid once per export, off the critical path; a device with WebGPU, or a smaller source, does not pay it this way. Verified on the rebuilt container (BASE=http://localhost:8090): - sr-detail-probe.cjs, midtone source so the app's tone pipeline cannot clip the very detail being measured (an earlier all-contrast version of it reported "grain 0.00" for the model AND for a plain resize — it was measuring the clip) - superres-test.cjs 32 PASS / 0 FAIL (export sizes, 4K tile seams clean) - sr-crop-export.cjs 0 FAIL - npx tsc --noEmit clean.	2026-09-25 18:48:13 +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