15 Commits

Include renames

Author	SHA1	Message	Date
dtourolle	affdaecaee	Stop describing a base curve the pipeline no longer has ... D19 retired the per-body base curve, moved the matrix ahead of the edits and the film into the view transform's place, but a dozen doc comments still listed the curve among what a pixel passes through, or said the film skipped it. The detail stage's module doc still drew the matrix after the edits and the last detail pass encoding, which the view pass took over. The film crate's README gave the base curves as its reason for being data, and the ops README's list of hand-written nodes had neither the view transform nor three of the five kernels. FR-MRG-2 gave the base curve as why the merge cuts below the profile; the view transform is why now. The decision table still said colour defaults were a per-body curve, and FR-DEV-3j said only the default view transform skips a JPEG, where the node skips one whatever its sliders say. frame-budget.md records the view pass as unmeasured.	2026-09-27 19:42:41 -04:00
dtourolle	37a6d99dc4	Replace the per-body base curve with a scene-referred view transform ... The base curve was a five-point spline on the unit square, flat past its last point: every value above 1.0 left it as the same number, per channel. Exposure and highlight recovery put values up there, and the curve threw them away, then handed the result on as though it were still scene-linear. The six per-body curves were also, by their own file's account, hand-tuned shapes rather than measurements, and not enough is known about where they came from to keep them (D19). In their place, one view transform for every body (FR-DEV-3j): a log-logistic sigmoid per channel, with the middle channel put back between the other two so a hue survives the shoulder. Its two free constants are solved from two conditions rather than set: scene grey 0.13, where the retired default curve put it, lands on display 0.18, and the scene white four stops above grey lands on 1.0. So a highlight a stop past sensor saturation still rolls into white, and the midtones stay within 0.26 EV of the retired default between scene 0.03 and 1.0. `dr_pipeline::view` holds the CPU reference and the WGSL, and the tests there are FR-DEV-3j's acceptance criteria. It is still fixed and still in the fused pass's tail, so a detail stage still sees rendered values; the next commits make it an operation and move it after the detail stage. It is skipped for a JPEG, as the base curve was, and absent from the camera-space tap. The base curve's database, its lookup and its twelve uniform slots go. `RawImage` and `DemosaicedImage` lose the field, and the GPU test that proved a curve reached the shader is replaced by one that renders the view transform against the CPU reference and shows two highlights above 1.0 still render apart. The JPEG-and-sensor test now asserts the two differ by exactly the view transform, where before an identity fixture curve had made them match.	2026-09-27 16:52:53 -04:00
dtourolle	1fdfb5990c	Describe the film's tables as 0.18.2 bakes them ... dr-film's README still described one 32³ lookup that took a negative through the print and the paper, with the sliders' values baked into it. Since 6b99f67 nothing a slider moves is baked: the curves are one row per development time the datasheet measures and push interpolates between them, a print is two lookups split at the paper's log exposure with the enlarger's exposure added between them, and exposure, push, print exposure and format reach the shader as uniforms. That is what lets a mask layer hold film settings of its own. The section now says so, and that the film's Exposure on the whole photograph is the one setting that rebakes, because the enlarger's filtration is solved against it.	2026-09-27 07:59:38 -04:00
dtourolle	6b99f67f47	Develop a mask layer's film on its own settings ... A layer offered the film's sliders and they moved nothing: its copy of the node was never given the stock, so it stayed inactive. Film now works in a layer the way the other adjustments do, as offsets to the photograph's settings, but blended as settings rather than as results, since a film is a rendering and cross-fading two developments is not what a region on a pushed film looks like. - dr-film bakes no slider. Exposure is a gain in the shader; push interpolates the stock's measured processes, one curve row each; the print is split at the paper's log exposure, so print exposure is an addition between two lookups and exact at any setting. The enlarger stays balanced at the photograph's exposure. - film_sim reads all four settings as uniforms, format one-hot over a grain count per format, so every uniform is linear in what it does. - Operation::blends_settings lets the composer average each overlapping layer's uniforms with the global ones by mask weight, the global setting taking whatever weight the layers leave, and run the fragment once. Three layers at full weight give the mean of their settings. - The stock picker is hidden on a layer. Only the photograph's exposure re-solves the print balance; push, print exposure and format need no rebake at all now.	2026-09-26 23:29:13 -04:00
dtourolleandClaude Opus 5	e14bc34a9e	Ask which frame this was taken on, because grain is enlargement ... A crystal is a fixed size in micrometres. How grainy a photograph looks is therefore not a property of the emulsion alone -- it is film size against output size, and the frame is the half a digital file cannot supply. This assumed 35 mm for everything. The same emulsion on 4x5 averages about 3,800 crystals into the pixel that holds 300 on 35 mm, so it renders roughly 3.5 times smoother at the same print; every large-format photograph was being rendered as grainy as a half-frame. `Format` now carries the real image widths -- the gate, not the nominal inches, since a "4x5" exposes about 121 mm -- and the film node asks for it. It is a genuinely fixed list, unlike the stocks, so it is a declared `enum` parameter and gets its control, its sidecar entry and its undo step for nothing. It is also the first enum in the develop chain, and it broke two tests by being one. A row has to compare equal to itself across two builds or `sync_rows` replaces it on every parameter event -- destroying the elements built from it, including whichever TouchArea holds the current gesture, so the format picker would have fought every slider drag in the panel. `ModelRc` compares by identity and the row built a fresh choices model each call. `no_choices` already shares one empty model for exactly this reason, and the build site already said "see no_choices for why the identity matters". The fix follows it: memoise the model per variant list. Curve rows solve the same problem the other way, writing values through the existing model, which is not needed here -- a variant list is fixed at compile time, so one model can serve forever. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 21:47:19 +02:00
dtourolleandClaude Opus 5	f14176de29	Give the projector lamp a name instead of a warning ... Every bake of a Vision3 stock logged: unknown illuminant "K75P", falling back to D55 K75P is a cinema xenon short-arc lamp, and Kodak 2383 and 2393 -- the projection print films those stocks print onto -- name it as the light their result is looked at under. It was never implemented, so it fell through to the unknown branch. The fallback was the right family: a xenon arc sits near 6000 K, close to daylight and nothing like the tungsten enlarger above it. So the pixels do not move. What changes is that D55 is now a documented choice rather than the consolation prize for an unrecognised string, with the approximation stated -- an arc has line structure a Planckian curve cannot express, and the residue of that is small here because the viewing step adapts the white point out either way. The test is the point of the commit. A profile naming a light nobody implemented should fail the suite, not whisper into a log that only gets read when somebody happens to be looking for something else -- which is how this was found. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 17:41:34 +02:00
dtourolleandClaude Opus 5	ff1a3e0e80	Print the black-and-white negatives instead of showing the scan ... Choosing Ilford HP5 Plus showed an inverted grey frame. So did Double-X. They are negatives, and upstream leaves `target_print` null on every monochrome stock, so nothing was ever printed and the scan was all there was. A colour negative at least announces itself -- the orange mask says plainly that you are looking at a negative. A monochrome one just looks broken. They print on Kodak 2302 now, which is a monochrome print film and is what such a negative is actually printed onto; Double-X onto 2302 is the standard cine chain. For the Ilford stocks it stands in for an Ilford paper, which nobody has measured, and is at least the right kind of material. The scan is still reachable through the Scanned/Printed toggle. It is a thing to choose now rather than the only thing on offer. `every_shipped_stock_bakes` did not catch this, and could not: it derives "should this be inverted?" from the stock's kind *and whether it names a paper*, so it looked at an inverted HP5, concluded that was right for an unprinted negative, and passed. The assertion was self-consistent and the situation was still wrong. The new test asserts the thing that actually matters -- a camera negative must name a paper, that paper must be a printing stock, and it must be the same kind of material, so a monochrome negative cannot end up on colour paper. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 17:35:25 +02:00
dtourolleandClaude Opus 5	ce6458547a	Develop longer, from the measurements rather than from a contrast slider ... Pushing was not a thing to simulate. It was measured data being thrown away: Double-X and 2302 each ship five characteristic curves, one per development time, and this shipped the 6.5-minute column and discarded four. All five now ship and interpolate. The axis is real. Double-X runs 4 to 12 minutes, and across it the average gradient goes 0.472 to 1.034 while Dmax goes 1.19 to 2.56. The control is in stops, because that is what a photographer means, and one stop is a factor of about 1.41 in time. That mapping is checked rather than assumed: against Double-X's own axis it lands within 2% of the 9-minute column for +1, and near 12 minutes for +2, which are the times the datasheet gives for exactly that. There is a test. **Pushing must not recover shadow detail, and this does not.** Across the whole measured range the speed point moves about a third of a stop while the gradient doubles; three stops under mid-grey, density goes from 0.008 to 0.035, which is still nothing. Developing longer multiplies what was already recorded and cannot record what never hit the film. A push built as added exposure or global contrast brightens those shadows instead and looks convincing until someone who shoots film sees it, so that property has a test of its own. Interpolated in *log* time, because development is multiplicative: 4 to 5 minutes is the same amount of push as 9 to 12, and interpolating linearly would bunch the control at one end. Clamped at both ends, because past the published range there is no data and extrapolating a contrast curve invents an emulsion nobody tested. A stock measured at one process ignores the control entirely rather than inventing a curve for it -- Portra 800's pushes are separate *measured* profiles, which is the honest way to offer those. Costs nothing per pixel and changes no shader. The curves are a per-stock table, so the interpolation happens on the CPU at bake time, where choosing a stock and moving its sliders already rebakes. The Vulkan shader is untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 17:35:25 +02:00
dtourolleandClaude Opus 5	e9b3598841	Add five Ilford stocks, and say plainly that they are constructed ... They were asked for and they are here, but not on the same footing as the Kodak profiles, and the files say so in their first line. What I had claimed, and had to withdraw: that Delta 100 is "quoted around 9" and HP5 "around 12". Ilford publish no such figures. The word granularity does not occur anywhere in their technical information -- grain is described as "fine" and "finest" and nothing more. That claim was in this crate's documentation as though it came from a datasheet; it is corrected there too. Two further traps found while looking: - Kodak colour negatives publish Print Grain Index, not RMS granularity. PGI is a perceptual scale from viewer surveys -- 25 is roughly the threshold of visibility, four units a just-noticeable difference -- and Kodak state it cannot be compared to RMS. So a Portra number cannot be dropped into the granularity field, and none has been. - RMS proper is published mostly for black-and-white, reversal and motion picture stocks. Every shipped stock therefore still carries the same default, which means grain does not yet tell one film from another. That is per-stock data, not code, and is now written down where somebody will find it. So the Ilford profiles are built rather than extracted, and each part rests on something different: speed published and exact -- ISO 400/27 for HP5 is a fact contrast ISO 6:1993's normal development, average gradient 0.62 spectral borrowed from Kodak Double-X, a *measured* panchromatic negative, shifted by the speed difference. Conventional panchromatic sensitisation is much alike across black-and-white films, and this is far better founded than reading pixels off a printed curve silver neutral, which is not an approximation: developed silver absorbs flat, and Double-X's measurement is flat granularity estimated, ordered by each film's known relative grain They render as a film of that speed and contrast. They are not a measurement of that emulsion, and the two stocks that share a speed differ only in the estimated part. `every_shipped_stock_bakes` is tightened to match, because a constructed profile fails in a way a measured one does not: the curve parses, bakes, and sits entirely off one end of its own exposure range, rendering every frame black or blown while passing a finiteness check. It now asserts mid-grey lands somewhere photographic and that the tone response runs the way the stock's kind says it should. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 10:08:51 +02:00
dtourolleandClaude Opus 5	4b2ee0ac50	Count the silver instead of adding noise ... An emulsion is a suspension of crystals. Light sensitises some; development turns a sensitised one opaque, all or nothing. So a patch of film's density is a *count* of developed grains, and a count of independent yes/no events has a variance whether or not anyone wanted texture: mean = D variance = D * (Dmax - u * D) / N That expression is the whole feature. It peaks in the middle of the density range and vanishes at both ends -- clear film has nothing developed to vary, black film has nothing left to develop -- so grain lives in the midtones as a consequence rather than as a "midtone bias" slider. I was wrong earlier that this needs the detail stage. Nothing in it reads a neighbouring pixel; the only reason to move it was that grain must be fixed in film space rather than screen space, and that solves itself: N is grains *per pixel*, so it scales with the film a pixel covers. Zoom out, each pixel averages more grains, less variance -- correct, with nothing super-sampled and nothing filtered. It stays in the fused pass. Grain goes on the density and *before* the dye, which is the physical order and not cosmetic. Perturbing the finished colour -- what an effect does -- tints highlights wrong, because that noise never passes through the dye. Crystal habit lives in `rms_granularity`, the number every datasheet publishes, now a profile field. It measures exactly what differs between a cubic emulsion and a tabular one: at equal speed, tabular crystals present more area per unit silver, so the film reads finer. Delta 100 is quoted near 9 where HP5 is near 12, and that gap *is* the habit. Adding a stock whose grain is its whole reputation is therefore editing one line, not writing a model. Three things this cost, all of them worth writing down: - The default granularity is a colour negative's, blue coarsest. Applied to Tri-X it put *colour* speckle on a black and white photograph. Monochrome stocks collapse it at parse, where every other per-layer table is already replicated from the one measured channel. - Helpers cannot read uniforms. The composer prefixes a uniform with its operation's id and rewrites references inside a fragment body only; helpers are shared and deduplicated, so a bare `gn0` names nothing. `film_lut` already took its size as an argument for this reason, and now says so. - The end-to-end test compares the shader against the CPU model, and grain is stochastic, so that comparison now runs with grain off. Which means a grain that never left the CPU would look exactly like a passing suite -- hence a second test that grain off is bit-identical, one grain per pixel moves it, and ten thousand move it less. Not here, deliberately: no grain slider. The parameters are physical and `rms_granularity` is the honest place to scale one from, but its range wants choosing rather than guessing. Nor a film format -- 35 mm is assumed, and medium format at the same stock is far less grainy per unit of picture. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 10:08:51 +02:00
dtourolleandClaude Opus 5	56978fdf35	Clear the clippy warnings that were failing CI before this branch ... Nothing here is film simulation. These are lints that fail master today, under the -D warnings CI runs with, mostly from a toolchain that learned new ones rather than from anybody's code -- `is_multiple_of` and the derivable `Default` did not exist as lints when this was written. They are fixed rather than allowed, and by hand rather than by trusting `cargo clippy --fix` wholesale: its automatic pass split a derive in two and left a stray blank line, which is the sort of thing that is correct and still wrong to commit. The four that needed a decision rather than a rewrite: - The distance transform's inner loop writes through its iterator now. `q` stays, because it is the position the parabola is evaluated at as well as the index it is written to -- the lint is about the write. - `to_source` and `to_proto` take `self` by value. Their receiver is `Copy`, so this is the same machine code and the honest signature. - The export path's return type is five levels deep and now has a name, plus a line saying why the `Option` wraps the `Result`: `None` is cancellation, which is not a failure and has no error to report. - A test fills a range instead of looping over one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 22:35:02 +02:00
dtourolleandClaude Opus 5	3b5952769b	Emit floats an f32 can hold, and drop the format! that formats nothing ... CI runs cargo fmt --check and clippy -D warnings, and this branch had never been through either. Both would have failed it. The bulk was the generated colour tables: eight significant figures where an f32 carries about 7.2, so the eighth is noise that rounds away at compile time and clippy's excessive_precision says so 109 times over. Fixed in the generator rather than only in the file, so it stays fixed -- and the file is trimmed in place rather than re-derived, because regenerating it needs a colour-science stack that has nothing to do with the defect. The format! in the composer is mine too, from extracting the rendering tail: the braces in it were escaped because the text used to live inside a larger template, and once extracted the escapes are noise and the call formats nothing. Also here, and clearly not mine: an unused import and a shadowed binding in dr-gpu, and an unused import in a test. They are pre-existing -- clippy has been failing on master before this branch existed, on lints like is_multiple_of that arrived with a toolchain rather than with anyone's code. Fixed because CI cannot go green around them, and called out because a merge commit is a bad place to quietly edit someone else's crate. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 22:28:14 +02:00
dtourolleandClaude Opus 5	6d18517d28	Ship every stock that exists, black and white included ... Three profiles was what the first cut needed to prove the model. This is the rest of the open data: 23 camera stocks and 9 papers, which is all of spektrafilm. Black and white was the gap, and it turned out not to be a gap in the data -- it was a gap in where I looked. Upstream's `main` has 28 colour profiles and nothing monochrome; `dev` has three more, and they are Tri-X, Double-X and the 2302 print film they go onto. So the answer to "do we have B&W" was yes all along, and it needed the dev branch rather than a fortnight digitising Ilford's datasheet graphs by eye. Those three are pinned to `dev` per stock; the colour stocks stay on the released branch. A monochrome profile is single-channel -- one emulsion, not three -- and spreading that one layer across all three is exact rather than an approximation: three layers with identical sensitivity and identical curves respond identically, which is what one layer does. The dye is the trap. The renderer *sums* the three layers' contributions, so replicating it unchanged renders every frame three times too dense -- neutrally, and therefore plausibly. A third each reconstructs the single emulsion, and two tests hold both halves: that the densities stay equal, and that they sum to one emulsion and not three. Double-X and 2302 ship five curves apiece, measured at five development times -- 4 to 12 minutes for Double-X. That is push and pull processing as measured data. The standard 6.5 minutes is what ships; the rest is in the upstream file waiting for a control to ask for it. Two stocks are `support: film` and are nevertheless what a negative is printed *onto*: the cine projection films 2383 and 2393, which the Vision3 stocks print to. Filtering the picker on support alone offered a projection stock as something to load in a camera, so it filters on stage, with a test saying so. The picker had to change shape twice over. Chips were right for three stocks and off the edge of a 280px column at twenty-four, and the column that replaced them was a thousand pixels standing between the photographer and every slider below. It is a disclosure now: one row carrying the answer, opened to change it, closed again on choosing. That is the opposite of the argument this panel used to take the lids off its sliders, and deliberately so -- an instrument you compare wants to be visible, and a list you consult once wants to be out of the way. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 20:30:11 +02:00
dtourolleandClaude Opus 5	4a2fcb6d22	Render a film stock on the GPU, and let it take over the rendering ... The stock model landed in dr-film with no way to see it. This is the pipeline node, the two texture bindings it reads, and the end-to-end test that proves the shader agrees with the model. The design point is that a film simulation is not an adjustment. Every other node changes a picture; this one makes it. A stock's characteristic curve does the camera profile's base curve's job -- from measurements rather than from a curve somebody drew -- so running both renders the scene twice: the camera's rendering, and then a film's rendering of that. It looks like neither, and it reads as a colour-management bug with no colour-management bug to find. So `Operation::renders` is new. A node declaring it takes camera RGB and hands back linear sRGB, and the composer emits neither the base curve nor the conversion out of camera space. Both halves move together, and the composer keeps them as one string precisely so that getting half of it right is impossible. The tables are not parameters, for the reason vignetting's coefficients are not: they are measurements. dr-pipeline declares the layout as a plain struct and keeps its no-dependency property; the two crates share no types on purpose. `EditGraph::set_film_tables` offers them to every node rather than to the one that wants them, because knowing which concrete type is which is what the graph is organised not to know. Bindings 4 and 5 follow the masks precedent: declared unconditionally so one bind group layout serves every generated shader, bound to 1x1 placeholders when no stock is loaded. Both are interpolated by hand with textureLoad -- this pipeline binds no sampler, and adding one for two lookups would cost a binding in every shader. Uploads are keyed on content so an unchanged stock does not push half a megabyte across the bus per frame. The end-to-end test earned its place immediately: it found the density lookup being filled z-fastest while a 3D texture upload wants x-fastest, so the red and blue axes were transposed. Green matched exactly, which is what that bug looks like -- a plausible photograph of the wrong colour, and one that every unit test on either side of the seam passes. dr-film now pins the layout in a test that needs no device, and states it where the field is declared. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 15:12:56 +02:00
dtourolleandClaude Opus 5	b6a95e1965	Simulate a film stock from its measurements, not from someone's grade ... FR-DEV-3f asks for look emulation and proposes HaldCLUT import to inherit the free film-simulation ecosystem. This takes the other road for the stocks where the measurements exist: run the physics. A stock here is its manufacturer's own datasheet -- spectral sensitivity, characteristic curves, dye densities. Light exposes three emulsion layers, the layers develop to densities, the densities are dyes that absorb, and what is left is what reaches the eye. A colour negative comes out orange and upside down because that is what a colour negative is; it becomes a photograph when a paper profile prints it, with the enlarger's filtration solved rather than dialled. What that buys over a LUT is that the parameters stay physical. Opening up a stop moves the picture along the film's real characteristic curve, shoulder and all, instead of scaling a number baked at one exposure. The data cost runs the other way too: a stock is 17 kB of published measurements where one HaldCLUT is 800 kB of one person's grade. It looks like it needs a spectral integration per pixel. It does not, and that is the whole design: - Exposure is a 3x3 matrix. The reconstructed scene spectrum is linear in the sRGB triple, so the integral collapses into nine numbers, exactly -- no approximation. - The characteristic curve is three 1D functions, sampled exactly. - Everything after that -- dye absorption, the print through the negative, the paper, the viewing illuminant, the adaptation -- takes exactly three numbers in, so it bakes into one 32^3 lookup. Per pixel: a matrix multiply, three curve taps, one fetch. Splitting the curve out of the 3D lookup rather than baking one LUT over exposure is measured, not assumed: the curve carries the sharp shape and the dye mixing is smooth, so folding them together would need three times the resolution for the same error. At 32^3 the worst error is 0.003 in linear sRGB, under one 8-bit code value, and a test says so. No wgpu dependency, deliberately, and the same isolation argument dr-lens makes: the model is plain f32 with a documented layout, so every property worth asserting is asserted on the CPU. Binding it to a texture is dr-gpu's job and is not done here yet. The expected values in tests/ came from a Python prototype running against a different colour-science stack. Agreement to three decimals is evidence about the model rather than about one implementation of it -- a transposed matrix or a mispasted observer row would pass every unit test and fail that one. Profiles are converted from spektrafilm by Andrea Volpato, CC BY-SA 4.0. The converter is in the tree and runnable, so what was changed from upstream is auditable rather than taken on trust; profiles/CHANGELOG.txt records it, including the one deliberate deviation -- Mallett & Yuksel's 1 kB basis instead of Hanatos's 4 MB table, which costs accuracy at the gamut edge and saves four megabytes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 14:44:54 +02:00